Comms Security Briefing

SecureCall security design, threat model, and cryptographic architecture · Last updated February 2026

Core Security Principles

SecureCall is designed around four foundational security principles that govern every architectural and implementation decision across the platform.

1. End-to-End Encryption — Only the two call participants can decrypt voice data. The signaling server, network intermediaries, and even the SecureCall team have zero access to call content. All encryption is performed on-device using a native Rust cryptographic engine.
2. Metadata Minimization — Collect and store as little metadata as possible. The signaling server knows only the minimum information required to route a call: two anonymous IDs and a timestamp. No phone numbers, names, or contact lists are ever transmitted.
3. Zero-Retention — No call content, audio recordings, or session logs are stored on servers. Ephemeral key material is generated per-session and destroyed immediately after the call ends. The server retains no history of past calls.
4. Verifiable Transparency — All source code is publicly auditable under a source-available license. Users, researchers, and security professionals can inspect exactly what the app does, how encryption is implemented, and verify that no backdoors exist.

Attacker Classes and Protections

SecureCall is engineered to defend against the following attacker classes. Each row identifies the adversary, their capabilities, and the specific countermeasures deployed.

What We Cannot Protect Against

No security system is absolute. The following attack vectors fall outside SecureCall's protection boundary:

• Compromised operating system — A device with root-level access or a compromised OS kernel can intercept any application data before encryption occurs.
• Hardware implants or baseband attacks — Physical hardware modifications or baseband processor exploits operate below the application layer and are undetectable by software.
• Shoulder surfing / physical eavesdropping — Someone physically present can listen to the audio output from the speaker or headset.
• Bugs in third-party code — Vulnerabilities in the Android OS, hardware drivers, or system libraries are outside SecureCall's control.

Architectural Overview

The SecureCall system is composed of two primary components: the Android client application and the signaling server. All cryptographic operations occur exclusively within the client's native Rust engine, accessed via JNI. The server acts solely as a message relay with zero access to plaintext data.

┌─────────────────────────────────────────────┐
│                 Android App                  │
│  ┌─────────┐  ┌──────────┐  ┌────────────┐ │
│  │   UI    │  │ Security │  │   Audio    │ │
│  │  (MD3)  │  │ Monitor  │  │  Pipeline  │ │
│  └────┬────┘  └────┬─────┘  └─────┬──────┘ │
│       │            │              │          │
│  ┌────┴────────────┴──────────────┴───────┐ │
│  │         Call Manager / Session         │ │
│  └────────────────┬──────────────────────┘ │
│                   │ JNI                     │
│  ┌────────────────┴──────────────────────┐ │
│  │      Rust Crypto Engine (native)      │ │
│  │  XChaCha20-Poly1305 | X25519 | HKDF  │ │
│  └───────────────────────────────────────┘ │
└────────────────────┬────────────────────────┘
                     │ WSS / WebRTC
┌────────────────────┴────────────────────────┐
│           Signaling Server (Node.js)         │
│  ┌──────────┐  ┌──────────┐  ┌───────────┐ │
│  │ Session  │  │   PKD    │  │   Rate    │ │
│  │ Router   │  │ (Keys)   │  │  Limiter  │ │
│  └──────────┘  └──────────┘  └───────────┘ │
└──────────────────────────────────────────────┘

The architecture enforces a strict separation of concerns: the UI layer handles user interaction, the Security Monitor performs real-time threat detection, and the Audio Pipeline manages capture, encoding, and playback. All three converge at the Call Manager, which coordinates session state and delegates cryptographic operations to the Rust engine via JNI.

Tier-Based Security Matrix

SecureCall offers three subscription tiers, each with escalating security enforcement. The table below details how each tier responds to specific threat conditions detected at runtime.

Six Layers of Active Defense

SecureCall employs a multi-layered defense system to detect and prevent unauthorized recording of encrypted calls. These protections operate simultaneously during active calls.

1. FLAG_SECURE — The Android system-level flag is applied to all call-related activities and fragments. This prevents the OS from including SecureCall in screenshots, screen recordings, recent apps thumbnails, and screen sharing sessions. On Pro tier it is enabled by default; on Premium it is always enforced and cannot be disabled.
2. Audio Focus Lock — SecureCall requests exclusive audio focus (AUDIOFOCUS_GAIN) during calls, preventing other applications from simultaneously accessing the microphone input. Any app attempting to record while a call is active will receive silence or be denied access.
3. Screen Recording Detection — On Android 14 (API 34) and above, SecureCall registers screen capture callbacks for system-level detection. On older versions, a background process monitor scans for known screen recording applications running concurrently. Detection triggers a response based on the user's tier.
4. Microphone Monitoring — An AudioRecordingCallback is registered to detect when any other application gains access to the microphone hardware. If a second app begins recording during a call, the user is immediately alerted and tier-appropriate countermeasures activate.
5. Accessibility Service Detection — Spyware commonly abuses Android accessibility services to capture screen content and keystrokes. SecureCall monitors active accessibility services and cross-references them against known spyware signatures. Suspicious services trigger alerts on Pro and call termination on Premium.
6. Call Recording App Scan — A database of 20+ known call recording applications is checked at call start. If any are installed and running, the user is warned. The database is periodically updated to include newly discovered recording apps.

Cryptographic Key Handling

Proper key lifecycle management is critical to maintaining forward secrecy and preventing post-compromise key extraction. SecureCall implements the following key handling practices:

• ByteArray storage — All key material is stored in mutable ByteArray objects (not immutable String types) to allow explicit overwriting. Java/Kotlin strings are interned and cannot be reliably cleared from memory.
• Rust Zeroizing wrapper — The native Rust crypto engine wraps all sensitive key material in Zeroizing<> types from the zeroize crate. When these wrappers go out of scope, the underlying memory is overwritten with zeros before deallocation.
• Immediate post-use destruction — Session keys, ephemeral Diffie-Hellman values, and derived encryption keys are zeroed from memory immediately after the call session ends. No key material persists beyond its active use window.
• No logging or transmission — Key material is never written to log files, crash reports, analytics events, or transmitted to any server. The signaling server never sees private keys or derived session keys.

Related Documentation

For deeper technical information on specific security topics, consult the following resources:

• Architecture Overview — Detailed system architecture, module responsibilities, and data flow diagrams.
• Security Audit Report — Independent audit findings, vulnerability classifications, remediation status, and cryptographic implementation review.
• Full Security Design Document — Complete security design specification (German-language) covering all implementation details.
• Security Disclosure Policy — Instructions for responsibly reporting vulnerabilities.