eCall Security Architecture Proposal¶

Zero-Trust E2EE — Military-grade security for calls¶

Version: 1.0 Date: April 16, 2026 Author: Security Engineering Team Classification: CONFIDENTIAL — Internal Use Only

1. Executive Summary¶

eCall currently implements End-to-End Encryption (E2EE) for voice and video calls, utilizing AES-256-GCM (audio) and P-256 ECDH via the Secure Enclave (key exchange). However, after a comprehensive security review (STRIDE + OWASP), we discovered 2 Critical vulnerabilities and 4 High vulnerabilities that require immediate remediation, alongside the realization that the current Key Transparency (KT) architecture is insufficient against scenarios where the Provider is compromised or acting maliciously.

Proposal: Deploy the "5-Layer Zero-Trust Shield" architecture — a security model equivalent to Signal, surpassing WhatsApp, and integrating the benefits of Apple iMessage Contact Key Verification, within a 10-week timeframe.

2. Problem: Why upgrade?¶

2.1. Vulnerabilities in the current system¶

2.2. Unmitigated Attack Scenarios¶

3. Proposed Solution: "5-Layer Zero-Trust Shield"¶

3.1. Architecture Overview¶

╔═══════════════════════════════════════════════════════════════════╗
║                 eCall Zero-Trust Security Shield                  ║
║                                                                   ║
║  ┌─────────────────────────────────────────────────────────────┐  ║
║  │ Layer 5: OUT-OF-BAND VERIFICATION                          │  ║
║  │ QR Code / Safety Number — Human verifies human             │  ║
║  │ → Mitigates ALL scenarios (even compromised Provider)      │  ║
║  └─────────────────────────────────────────────────────────────┘  ║
║  ┌─────────────────────────────────────────────────────────────┐  ║
║  │ Layer 4: PUBLIC TRANSPARENCY MONITOR                       │  ║
║  │ GitHub + Public API — Publicly auditable                   │  ║
║  │ → Mitigates Split-View, early detection of Key Leaks       │  ║
║  └─────────────────────────────────────────────────────────────┘  ║
║  ┌─────────────────────────────────────────────────────────────┐  ║
║  │ Layer 3: THIRD-PARTY AUDITOR                               │  ║
║  │ Independent service cross-checks every 5 minutes           │  ║
║  │ → Mitigates Split-View via neutral third-party             │  ║
║  └─────────────────────────────────────────────────────────────┘  ║
║  ┌─────────────────────────────────────────────────────────────┐  ║
║  │ Layer 2: CONSISTENCY PROOF                                 │  ║
║  │ App remembers old Root, detects rewrite/rollback           │  ║
║  │ → Mitigates Split-View + Rollback Attack                   │  ║
║  └─────────────────────────────────────────────────────────────┘  ║
║  ┌─────────────────────────────────────────────────────────────┐  ║
║  │ Layer 1: INCLUSION PROOF (Implemented)                     │  ║
║  │ Ed25519 Signature + Merkle Proof                           │  ║
║  │ → Mitigates basic Fake Key attacks                         │  ║
║  └─────────────────────────────────────────────────────────────┘  ║
╚═══════════════════════════════════════════════════════════════════╝

3.2. Layer Details¶

Layer 1: Inclusion Proof ✅ (Existing)¶

• Mechanism: When App A requests B's public key, the KT Server returns the key with a Merkle proof proving its inclusion in the tree. The App verifies the Ed25519 signature on the checkpoint.
• Status: Implemented in KTVerifier.swift. Stabilizing test suite.

Layer 2: Consistency Proof 🆕¶

• Mechanism: App stores the last (TreeSize, RootHash) in Keychain. On subsequent queries, the Server must include a Consistency Proof — proving the new Root is a valid extension of the old Root.
• Mitigates:
• Split-View: If Server creates different trees for users, consistency proof fails.
• Rollback: If Server reverts to an older tree, TreeSize decreases → App detects immediately.
• Effort: ~2 weeks (iOS + Server API)

Layer 3: Third-Party Auditor 🆕¶

• Mechanism: An independent service (Cloudflare Worker / AWS Lambda) pings the KT Server every 5 minutes and records the checkpoint. iOS App cross-checks checkpoints from the Auditor.
• Mitigates: Split-View — If Server sends a different Root to the App vs Auditor → immediate detection.
• Effort: ~1 week (Cloudflare Worker + iOS integration)

Layer 4: Public Transparency Monitor 🆕¶

• Mechanism: All checkpoints are published to a public GitHub repo or Public API. Anyone (journalists, researchers, community) can verify.
• Value: Builds brand trust — proves eCall "walks the talk" on security.
• Effort: ~1 week (CI/CD automation)

Layer 5: Out-of-Band Verification (QR / Safety Number) 🆕¶

• Mechanism: Each user pair has a unique "Safety Number" (10 groups × 5 digits = 50 digits). Users compare this number in person or scan a QR code. Mismatch indicates Provider tampering.
• Mitigates: ALL scenarios — even if Provider controls server + auditor + malicious update. Validation is human-to-human.
• Effort: ~2 weeks (UI/UX + crypto logic)

3.3. Defense Matrix¶

Conclusion: A minimum of 5 layers is required to defend against ALL scenarios, including intentional Provider tampering.

4. Competitor Comparison¶

Highlight: Post-upgrade, eCall will be the only calling app featuring a Public Transparency Monitor + Secure Enclave + Third-party Auditor combination — surpassing Signal (no Auditor) and WhatsApp (no Secure Enclave).

5. Implementation Roadmap¶

Phase 0: Critical Security Fixes — Week 1¶

Absolute Priority — Fix vulnerabilities currently in production

Phase 1: Consistency Proof — Week 2-3¶

Phase 2: Safety Number & QR Verification — Week 4-5¶

Phase 3: Third-Party Auditor — Week 6¶

Phase 4: Public Transparency Monitor — Week 7¶

Phase 5: Server Hardening — Week 8-9¶

Phase 6: Stabilization & Third-party Audit — Week 10¶

6. Cost Estimation¶

ROI: Very low cost (primarily dev time) with massive brand value — eCall can claim "security surpassing WhatsApp" with concrete technical proof.

7. Risks & Mitigations¶

8. Conclusion¶

Why approve this proposal?¶

1. Absolute Security: 5 overlapping layers — attackers must breach all 5 layers simultaneously to eavesdrop. Even if the Provider is coerced, Layer 5 (human-to-human verification) will detect it.
2. Low Cost: ~10 weeks dev time + <$15K external cost. No complex infrastructure required.
3. Competitive Advantage: eCall will be the only calling app in the market with a Public Transparency Monitor — anyone can verify eCall is not cheating. Strong selling point for B2B/Gov clients.
4. Legal Compliance: Meets GDPR (data encryption), HIPAA (healthcare call encryption), and military security standards (Zero-Knowledge architecture).

Approval: