Comms Security Briefing

SecureCall security design, threat model, and cryptographic architecture · Last updated April 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 — Application media frames are encrypted on-device using the Rust cryptographic engine. A P-256 Android Keystore identity signs registration and both per-call X25519 transcripts. Call plaintext is not sent to signaling.
2. Metadata Minimization — Collect and store as little metadata as possible. Call routing uses two anonymous IDs and a timestamp. Optional contact discovery sends deterministic SHA-256 hashes of normalized phone numbers; raw names, raw numbers, and full contact lists stay on the device. Hashing does not guarantee anonymity.
3. Content Retention Boundary — The signaling service is not designed to store call content or audio recordings. Per-call key material is discarded after the call. Limited routing, delivery, entitlement, security, and operational records are handled as described in the privacy policy.
4. Verifiable Transparency — The client source code and current audit status are publicly inspectable under the StealthX Source-Available License. Researchers can review the implementation, reproduce supported tests, and report discrepancies. Source availability is not itself proof that no defect or backdoor exists. Copying, building, running, distributing, rebranding, hosting, or using SecureCall requires prior written permission from Vendetta Labs.

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 the Android client application and the signaling service. Application-frame cryptography is performed by the client's native Rust engine through JNI. Registration and call-key transcripts are authenticated by a per-install Android Keystore identity; the signaling service is not designed to receive call plaintext.

┌─────────────────────────────────────────────┐
│                 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 limits the exposure of per-call material. SecureCall implements the following key handling practices, but does not claim Double Ratchet or post-compromise security:

• 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.

Cross-Product Security Comparison

SecureChat, the messaging product of the StealthX Platform, shares the same cryptographic foundation as SecureCall but adapts the security model for asynchronous messaging and decentralized relay infrastructure.

Both products target OWASP MASVS Level 2 compliance. External security audit by Trail of Bits is recommended before public release of either product.

SecureChat Security Design → | Relay Architecture →