System Architecture Brief

Technical architecture overview of the SecureCall platform · Last updated April 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.

Application-frame cryptography executes inside the Rust native library. The signaling service coordinates call setup and is not designed to receive call plaintext. Voice media uses direct WebRTC when available and otherwise may traverse a TURN relay. A P-256 Android Keystore identity signs registration and both X25519 call transcripts before media starts.

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  │ │ Per-call│ │   │
│  │  │ Poly1305 │ │  ECDH   │ │ SHA256 │ │   key   │ │   │
│  │  └──────────┘ └─────────┘ └────────┘ └─────────┘ │   │
│  └───────────────────────────────────────────────┘   │
└──────────────────────────┬───────────────────────────────┘
                          │ WSS (Signaling)
                          │ WebRTC (Media — P2P/TURN)
┌──────────────────────────┴───────────────────────────────┐
│               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 (stealthx.tech)
├── 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
• TLS protects each client-to-server hop; the server processes SDP offers/answers, ICE candidates and signed key-exchange data
• Call content is not sent through this signaling channel; signaling metadata is visible to the service
• 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 a direct peer-to-peer path is unavailable
• 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: