High-Level Security Model
This document outlines the comprehensive security framework governing Secure Legion, including threat assumptions, cryptographic primitives, data handling rules, and device protection layers. It defines how Secure Legion achieves trustless, serverless communication with provable zero metadata exposure.
Core Security Philosophy
Zero trust by design
No component (client, relay, or developer) is inherently trusted.
End-to-end sovereignty
Users own their cryptographic identity and control all message flow.
Serverless integrity
Messages are never stored or routed through central systems.
Defense-in-depth
Encryption, authentication, enclave storage, and revocation layers reinforce each other.
Human-level fail-safes
Duress PIN, session wipe, and optional decoy modes reduce coercion risk.
Threat Model
| Category | Adversary | Goal | Defense Mechanism |
|---|---|---|---|
| Passive Network Observer | ISP, carrier, compromised Wi-Fi | Traffic correlation, metadata analysis | Encrypted wake tokens via Tor/UnifiedPush; constant-rate packets; indistinguishable noise generation |
| Active Network Attacker | MITM machine/intercepting nation | Replay, downgrade, impersonation | Nonce-based replay protection, signature verification, ephemeral DH ratcheting |
| Compromised Relay / Push Disclosure | Hostile server or OS-level leak | Message inspection or metadata harvesting | Only opaque encrypted wake tokens; no sender/receiver identifiers; rotating relay endpoints |
| Device Theft / Law Enforcement | Physical access | Extract keys or pending messages | Hardware-key storage (StrongBox / Secure Enclave); memory-only data; screen lock |
| Malicious Insider / Developer | Rogue admin, compromised update | Supply-chain injection | Reproducible builds, public hashes, code signing, optional offline app sideload verification |
| Mass Surveillance / State-level Actor | Data correlation, timing analysis | Social-graph inference | Onion routing + randomized ping delays; multiple dummy traffic; random pacing |
| User Coercion / Compelled Disclosure | Forced unlock or PIN entry | Data exfiltration under duress | Duress PIN triggers dev wipe + signed network revocation |
Cryptographic Architecture
| Layer | Algorithm | Function |
|---|---|---|
| Identity Signing | Ed25519 | Long-term identity proof |
| Ephemeral Sessions | X25519 + ChaCha20-Poly1305 | Forward secrecy and transport confidentiality |
| Wake Tokens | Ed25519 + Argon2 + XChaCha20 | Authenticated ping/pongs |
| Queue Encryption | AES-256-GCM | Local message queue protection |
| Derivation | HKDF + Argon2id | Salted handle hashing and key stretching |
| Storage Encryption | Android Keystore / iOS Secure Enclave | Hardware-level protection |
Forward Secrecy
Session keys are rotated per message. Each Ping-Pong exchange derives new ephemeral keys, ensuring that even full compromise of a device cannot decrypt prior traffic.
Device Security Layer
4.1 Hardware Binding
Each device identity is bound to a non-exportable key within hardware security modules.
- •Android → StrongBox or TEE-backed Keystore
- •iOS → Secure Enclave
4.2 Authentication Layer
User presence requirements:
- •Biometric, PIN, or password-driven
- •Cold storage behavior: app runs in read-only wallet mode until user unlocks private keys
4.3 Duress & Wipe Mechanisms
Emergency protection:
- •Duress PIN or "decoy unlock" instantly destroys keys and session metadata
- •A signed revocation beacon prevents future deliveries to that identity
Transport Security Layer
5.1 Primary Channels
- •Tor sockets for persistent encrypted routes
- •WebSocket/MQTT fallback for real-time communication
- •UnifiedPush / AlarmManager for wake notifications only (no metadata)
5.2 Integrity Rules
- •All packets contain MAC and signature verification
- •Fixed packet sizes prevent size correlation
- •Message IDs and nonces ensure replay immunity
Data Lifecycle
| Stage | Stored | Encrypted | TTL |
|---|---|---|---|
| Message queued | Sender device | Yes (pubkey key) | ≤7 days |
| Wake token | Relay/transport | Yes (wake key) | ≤1 hour |
| Delivered message | Receiver memory only | Yes (session key) | Erased after view |
| Keys | Hardware secure element | Non-exportable | Persistent until wiped |
Revocation & Identity Management
- •Every identity can publish a revocation record signed by the identity key.
- •Peers verify revocation before delivery.
- •Compromised identities are effectively blacklisted network-wide.
Auditing & Verification
- •Open source cryptographic libraries and protocol spec.
- •Reproducible builds for binary transparency.
- •Checksum verification on installs.
- •Independent audit pipeline (planned for public release).
Compliance & Patent Domains
- •Patent class alignment: H04L 9/32 (secure communications) and G06F 21/62 (data integrity and authentication).
- •Fully compliant with GDPR, CCPA, and no-PII retention policies.
- •No user data stored outside local device scope.
Summary
Secure Legion's security model is layered and self-verifiable.
Cryptography protects content.
Hardware protects keys.
Protocol protects flow (Ping-Pong).
Human controls (duress, manual wake) protect intent.
Open design protects against hidden trust.
Together these realize the core principle:
No servers. No metadata. No compromises.