System Architecture Brief

Technical architecture overview of the SecureCall platform · Last updated February 2026

Core Components

SecureCall is built from three tightly integrated components, each responsible for a distinct layer of the platform. The Android client handles all user-facing operations, the Rust crypto engine provides native-speed cryptographic primitives via JNI, and the Node.js signaling server coordinates call setup without ever touching media or plaintext content.

All cryptographic operations execute inside the Rust native library — no Java crypto APIs are used. The signaling server relays encrypted messages but cannot decrypt any content. Voice media flows peer-to-peer via WebRTC and never passes through the signaling server.

System Diagram

The following diagram illustrates how the three components interact. The Android client contains four subsystems (UI, Audio Pipeline, Security Monitor, Network Manager) that communicate with the Rust crypto engine via JNI. The signaling server handles WebSocket-based call coordination and key exchange.

┌──────────────────────────────────────────────────────────┐
│                    Android Client                         │
│                                                          │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │
│  │    UI    │ │  Audio   │ │ Security │ │  Network   │ │
│  │  (MD3)  │ │ Pipeline │ │ Monitor  │ │  Manager   │ │
│  │         │ │          │ │          │ │            │ │
│  │ - Call  │ │ - Opus   │ │ - Screen │ │ - WebRTC   │ │
│  │ - Dial  │ │ - 48kHz  │ │ - Mic    │ │ - WebSocket│ │
│  │ - Cont. │ │ - AEC    │ │ - SpyApp │ │ - ICE/TURN │ │
│  │ - Sett. │ │ - AGC    │ │ - Focus  │ │ - DTLS     │ │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘ └─────┬──────┘ │
│       └─────────────┴────────────┴───────────┘         │
│                          │ JNI                            │
│  ┌───────────────────────┴───────────────────────┐   │
│  │            Rust Crypto Engine (Native .so)          │   │
│  │  ┌──────────┐ ┌─────────┐ ┌────────┐ ┌─────────┐ │   │
│  │  │ XChaCha20│ │  X25519 │ │  HKDF  │ │ Double  │ │   │
│  │  │ Poly1305 │ │  ECDH   │ │ SHA256 │ │ Ratchet │ │   │
│  │  └──────────┘ └─────────┘ └────────┘ └─────────┘ │   │
│  └───────────────────────────────────────────────┘   │
└──────────────────────────┬───────────────────────────────┘
                          │ WSS (Signaling)
                          │ WebRTC (Media — P2P)
┌──────────────────────────┴───────────────────────────────┐
│               Signaling Server (Node.js)                  │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐  │
│  │ Session  │ │ Call     │ │   PKD    │ │   Rate     │  │
│  │ Registry │ │ Router   │ │ (Keys)   │ │  Limiter   │  │
│  └──────────┘ └──────────┘ └──────────┘ └────────────┘  │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐  │
│  │ Heartbeat│ │ Presence │ │   FCM    │ │  Validator │  │
│  │ Manager  │ │ Tracker  │ │ (Push)   │ │ (Input)    │  │
│  └──────────┘ └──────────┘ └──────────┘ └────────────┘  │
└──────────────────────────────────────────────────────────┘

Repository Layout

SecureCall is organized as a monorepo containing the Android client, Rust crypto engine, Node.js backend, documentation, website, and deployment infrastructure. The primary development directory is client_android/.

stealth/
├── client_android/          # Android app (Kotlin/Java)
│   └── app/src/main/java/com/securecall/app/
│       ├── CallActivity.java       # Main call screen
│       ├── MainActivity.java       # Entry point
│       ├── security/               # Security monitoring
│       │   ├── AudioFocusManager.kt
│       │   ├── ScreenRecordingDetector.kt
│       │   ├── MicrophoneMonitor.kt
│       │   ├── AccessibilityDetector.kt
│       │   ├── CallRecordingDetector.kt
│       │   ├── SecureCallMonitor.kt
│       │   └── SecurityEnforcer.kt
│       ├── config/                 # Tier-based feature flags
│       └── ui/                     # UI fragments
│
├── core_crypto/             # Rust crypto engine
│   └── src/
│       ├── lib.rs                  # Public API
│       ├── aead/                   # XChaCha20-Poly1305
│       ├── identity/               # Key pairs
│       ├── session/                # Session state
│       ├── hkdf/                   # Key derivation
│       └── ffi/                    # JNI bridge
│
├── backend/signaling/       # Node.js signaling server
│   └── src/
│       ├── server.js               # Main entry
│       ├── call_routing.js         # Call routing logic
│       ├── sessions.js             # Session management
│       ├── pkd.js                  # Public Key Directory
│       ├── rateLimit.js            # Rate limiting
│       └── validator.js            # Input validation
│
├── website/                 # Landing page (neabouli.github.io/stealth)
├── docs/                    # Documentation
├── deploy/                  # Docker deployment
├── deployment/              # PM2 bare-metal deployment
├── marketing/               # Play Store listings
└── tools/                   # Build & test scripts

Communication Pathways

SecureCall uses three distinct communication pathways depending on the phase of a call. Understanding these data flows is essential for evaluating the security posture of the system.

Signaling (Call Setup)

Client A  →  WSS  →  Signaling Server  →  WSS  →  Client B

• Encrypted WebSocket connection (TLS) between each client and the signaling server
• Server relays encrypted signaling messages (SDP offers/answers, ICE candidates, key exchange data)
• Server cannot read message content — it acts as an opaque relay
• Call setup typically completes in 1–2 seconds on stable connections

Media (Voice)

Client A  →  WebRTC (P2P, DTLS-SRTP)  →  Client B

• Direct peer-to-peer connection established via ICE negotiation
• Server is not in the media path — voice data flows directly between devices
• Each voice frame is individually encrypted using XChaCha20-Poly1305
• Audio encoded with Opus codec at 48kHz with acoustic echo cancellation (AEC) and automatic gain control (AGC)

TURN Relay (When P2P Fails)

Client A  →  TURN Server  →  Client B

• Used when direct P2P is blocked by restrictive NAT or corporate firewalls (~10–15% of connections)
• TURN server relays encrypted packets but cannot decrypt voice content
• Time-limited TURN credentials are generated by the signaling server during call setup
• Metered.ca TURN service is used with TCP transport on port 443 for maximum compatibility

Product Flavors

SecureCall ships in three product tiers, each compiled as a separate build flavor with distinct package names, feature flags, and capabilities. Feature gating is controlled via BuildConfig fields set in build.gradle and accessed at runtime through the FeatureProvider interface.

Build Command

The free debug variant is the primary development and testing target:

# From the client_android/ directory
./gradlew assembleFreeDebug

# APK output location
app/build/outputs/apk/free/debug/app-free-debug.apk

Server Endpoints

All server URLs are hardcoded in build.gradle for both debug and release configurations: