Lakrion Dormant Architecture (LDA)

1. Problem Statement

1.1 The Always-Active Vulnerability

Modern secure messaging applications that support voice calls and other real-time features share a critical weakness: these subsystems are continuously active and reachable during normal operation, even when the user isn't using them.

When you install a messaging app with calling support, the following components are typically active at all times:

• - Network listeners waiting for incoming call signals
• - Media processing libraries loaded in memory
• - Codec implementations ready to process incoming data
• - WebRTC or equivalent stacks in addressable memory
• - Background services handling call setup

This creates a permanent attack surface that adversaries can exploit without any user interaction.

1.2 Zero-Click Exploits

Sophisticated attack tools exploit this always-active architecture. A zero-click exploit can:

1. Send a malformed call signal or media packet
2. Trigger a vulnerability in the always-loaded calling code
3. Achieve code execution without the user doing anything
4. Compromise the device silently

The user doesn't need to answer the call. The user doesn't need to click anything. The mere presence of the calling code in memory is enough.

1.3 Why "Disable" Doesn't Work

When users "disable" calling features in app settings, they typically only hide UI elements. The underlying code remains:

• - Linked to the application binary
• - Loaded into memory
• - Reachable through network interfaces
• - Exploitable through crafted inputs

A UI toggle is not a security boundary.

2. LDA Architecture

2.1 Core Principle

Code that is not loaded presents no target for exploitation.

LDA implements this principle through genuine architectural separation. Dormant subsystems are:

2.2 Component Separation

An LDA-compliant application consists of:

┌─────────────────────────────────────────────────────────────┐
│                    MAIN APPLICATION                         │
│                                                             │
│  • Text messaging (E2E encrypted)                          │
│  • Contact management                                       │
│  • Key exchange                                             │
│  • User interface                                           │
│  • Activation protocol handler                              │
│                                                             │
│  [Always active, minimal attack surface]                    │
└─────────────────────────────────────────────────────────────┘
                            │
                            │ Activation Interface
                            │ (only when mutually triggered)
                            ▼
┌─────────────────────────────────────────────────────────────┐
│                  DORMANT SUBSYSTEM                          │
│                                                             │
│  • Voice calling                                            │
│  • Media codecs                                             │
│  • WebRTC stack                                             │
│  • Real-time transport                                      │
│                                                             │
│  [Not loaded until mutual activation]                       │
└─────────────────────────────────────────────────────────────┘

2.3 State Machine

A dormant subsystem exists in one of four states:

                    ┌──────────────────┐
                    │                  │
                    │     DORMANT      │◄───────────────────┐
                    │                  │                    │
                    └────────┬─────────┘                    │
                             │                              │
              Mutual activation                             │
              protocol completes                            │
                             │                              │
                             ▼                              │
                    ┌──────────────────┐                    │
                    │                  │     Timeout or     │
                    │   ACTIVATING     │─────failure────────┤
                    │                  │                    │
                    └────────┬─────────┘                    │
                             │                              │
                    Activation                              │
                    successful                              │
                             │                              │
                             ▼                              │
                    ┌──────────────────┐                    │
                    │                  │                    │
                    │     ACTIVE       │     Timer expires, │
                    │                  │     user ends, or  │
                    │  [Time-limited]  │     error          │
                    │                  │                    │
                    └────────┬─────────┘                    │
                             │                              │
                             ▼                              │
                    ┌──────────────────┐                    │
                    │                  │                    │
                    │  DEACTIVATING    │────────────────────┘
                    │                  │
                    └──────────────────┘

Valid transitions:

• - DORMANT → ACTIVATING (mutual consent received)
• - ACTIVATING → ACTIVE (initialization complete)
• - ACTIVATING → DORMANT (timeout or failure)
• - ACTIVE → DEACTIVATING (session end, timer expiry, or user request)
• - DEACTIVATING → DORMANT (cleanup complete)

No direct transition from DORMANT to ACTIVE is permitted. The activation process cannot be bypassed.

3. Mutual Activation Protocol

3.1 Design Goal

Neither party can unilaterally cause code to load on the other party's device.

This mitigates attacks where an adversary sends a malformed message to trigger vulnerable code. In LDA, the dormant subsystem's code is not present to be triggered until both parties consent.

3.2 Protocol Flow

    Party A                                          Party B
       │                                                │
       │  1. Generate activation request                │
       │     • Session ID (random)                      │
       │     • Timestamp                                │
       │     • Expiration window                        │
       │     • Ephemeral public key                     │
       │     • Signature                                │
       │                                                │
       │  ─────────────────────────────────────────►    │
       │         Activation Request                     │
       │         (via E2E encrypted channel)            │
       │                                                │
       │                                   2. Display notification
       │                                      "Party A requests
       │                                       voice call"
       │                                                │
       │                                   3. User provides
       │                                      explicit consent
       │                                                │
       │                                   4. Generate acceptance
       │                                      • Session ID
       │                                      • Ephemeral public key
       │                                      • Timestamp
       │                                      • Signature
       │                                                │
       │    ◄─────────────────────────────────────────  │
       │         Activation Acceptance                  │
       │                                                │
       │  5. Both parties load dormant subsystem        │
       │                                                │
       ▼                                                ▼
  ┌─────────┐                                    ┌─────────┐
  │ ACTIVE  │◄──────── Session Keys ───────────►│ ACTIVE  │
  └─────────┘    (derived from ephemeral        └─────────┘
                       key exchange)

3.3 Cryptographic Elements

3.4 What Cannot Happen

• - ❌ Adversary sends crafted packet → subsystem loads
• - ❌ Adversary sends call signal → code executes
• - ❌ Adversary exploits codec → device compromised

Without mutual consent, there is no code to exploit.

3.5 Residual Attack Surface

LDA significantly reduces but does not eliminate all attack surface. The following components necessarily remain active during dormancy:

The activation handler is intentionally minimal — it only needs to validate signatures and display a consent prompt. It does not process media, run codecs, or handle complex protocols. This is a fundamentally smaller and simpler attack surface than a full calling stack.

4. Time-Bounded Operation

4.1 Mandatory Expiration

Once active, the subsystem operates under a strict timer:

• - Typical duration: 5-30 minutes (configurable)
• - Timer is non-bypassable: Implemented at system level, cannot be disabled via app interface
• - Grace period: 30-60 second warning before expiration
• - Automatic deactivation: Timer expiry forces return to DORMANT

4.2 Deactivation Process

When a session ends (timer, user action, or error):

1. Terminate session — End any active call
2. Erase keys — Secure deletion of all ephemeral cryptographic material
3. Close connections — Release all network sockets
4. Release permissions — Revoke microphone, camera access
5. Unload code — Remove subsystem from memory
6. Reset state — Return to DORMANT

4.3 Security Benefit

Even if an adversary discovers a vulnerability in the active subsystem:

• - They have a limited time window to exploit it
• - The exploit must achieve persistence before deactivation
• - Deactivation erases evidence and resets state

5. Generalized Dormancy

5.1 Beyond Voice Calls

While voice calling is the primary use case, LDA applies to any high-risk feature:

5.2 Dormant Feature Toggles

An LDA-compliant application can implement configurable dormancy for multiple features:

┌────────────────────────────────────────────────────────┐
│                    SETTINGS                            │
├────────────────────────────────────────────────────────┤
│                                                        │
│  Voice Calls          [Dormant ▼]                      │
│    • Dormant (LDA)                                     │
│    • Disabled                                          │
│    • Enabled (always loaded)                           │
│                                                        │
│  Link Previews             [Dormant ▼]                 │
│    • Dormant (LDA)                                     │
│    • Disabled                                          │
│    • Enabled                                           │
│                                                        │
│  File Previews             [Dormant ▼]                 │
│    • Dormant (LDA)                                     │
│    • Disabled                                          │
│    • Enabled                                           │
│                                                        │
└────────────────────────────────────────────────────────┘

"Dormant (LDA)" means the code is not loaded until explicitly activated with consent.

"Disabled" means the feature is unavailable but code may still be present.

"Enabled" means always available (traditional behavior, higher attack surface).

5.3 Per-Feature Activation

Different features may require different activation models:

6. Implementation Approaches

6.1 Process Isolation

The dormant subsystem runs as a separate OS process:

• - Spawned only upon activation
• - Separate address space from main app
• - Terminated upon deactivation
• - No process exists during dormancy

Best for: Desktop applications, high-security mobile deployments

6.2 Dynamic Loading

The dormant subsystem is a dynamically loaded library:

• - Loaded via dlopen() / LoadLibrary() only upon activation
• - Unloaded via dlclose() / FreeLibrary() upon deactivation
• - Not linked at compile time

Best for: Mobile applications, resource-constrained environments

6.3 Containerized

The dormant subsystem runs in an isolated container:

• - Container instantiated upon activation
• - Container destroyed upon deactivation
• - Strong isolation guarantees

Best for: Enterprise deployments, server-side components

6.4 Hardware-Backed

The dormant subsystem runs in a Trusted Execution Environment (TEE):

• - Code executes in secure enclave
• - Isolated from main OS
• - Hardware-enforced boundaries

Best for: Highest-security requirements

7. Security Properties

7.1 Attack Surface Comparison

CONVENTIONAL ARCHITECTURE:
┌──────────────────────────────────────────────────────────┐
│                    ATTACK SURFACE                        │
│                                                          │
│  [Messaging] [Calling] [Media] [Codecs] [WebRTC] [...]  │
│                                                          │
│  ████████████████████████████████████████████████████   │
│                 Always exposed                           │
└──────────────────────────────────────────────────────────┘

LDA ARCHITECTURE (DORMANT):
┌──────────────────────────────────────────────────────────┐
│                    ATTACK SURFACE                        │
│                                                          │
│  [Messaging]                                             │
│                                                          │
│  ████████                                                │
│  Only core exposed                                       │
└──────────────────────────────────────────────────────────┘

LDA ARCHITECTURE (ACTIVE - TIME LIMITED):
┌──────────────────────────────────────────────────────────┐
│                    ATTACK SURFACE                        │
│                                                          │
│  [Messaging] [Calling] [Media] [Codecs] [WebRTC]        │
│                                                          │
│  ████████████████████████████████████████████████████   │
│  Full surface, but only for 5-30 minutes                │
└──────────────────────────────────────────────────────────┘

7.2 Properties Achieved

7.3 Threat Model

LDA is designed to protect against:

• - ✅ Zero-click exploits (Pegasus-style)
• - ✅ Network-delivered code execution
• - ✅ Silent device compromise
• - ✅ Incoming call exploits
• - ✅ Media processing exploits
• - ✅ Push notification triggered attacks

LDA does not address:

• - ❌ Vulnerabilities in the main messaging application
• - ❌ Social engineering (tricking user into activating)
• - ❌ Physical access attacks
• - ❌ Exploitation during the active window (time-limited risk)

8. Comparison with Existing Systems

Note: Comparison reflects default architectures as of January 2026. Individual implementations may vary.

9. Future Extensions

9.1 Multi-Party Activation

Extend mutual consent to group calls:

• - Require consent from all participants, or
• - Require consent from threshold (e.g., 3 of 5)

9.2 Scheduled Activation Windows

Pre-arrange activation times:

• - Both parties agree in advance: "Call window: 14:00-14:30"
• - Subsystem auto-activates during window
• - Returns to dormant after

9.3 Renewable Sessions

For longer calls:

• - Periodic re-authentication required
• - Both parties confirm every N minutes
• - Failure to confirm = automatic deactivation

9.4 Integration with Hardware Security

• - Store activation credentials in secure element
• - Require biometric confirmation for activation
• - Hardware-backed key generation

10. Conclusion

The Lakrion Dormant Architecture (LDA) represents a fundamental shift in secure messaging architecture. Rather than treating high-risk features as always-available conveniences, LDA treats them as isolated subsystems that exist only when explicitly needed.

The core insight is simple: code that isn't loaded presents no target for exploitation.

By implementing genuine architectural separation, mutual consent activation, and time-bounded operation, LDA significantly mitigates the class of zero-click attacks that have compromised journalists, activists, and other high-risk individuals worldwide.

LDA is not a silver bullet — users must still make wise decisions about when to activate features, the main application must still be secure, and some minimal attack surface (such as the activation handler) necessarily remains. But for users facing sophisticated adversaries, LDA dramatically reduces the attack surface available for exploitation.

References

• - Beer, I., Groß, S. "A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution." Google Project Zero, 2021.
• - Marczak, B., et al. "The Great iPwn: Journalists Hacked with Suspected NSO Group iMessage 'Zero-Click' Exploit." Citizen Lab, 2020.
• - Signal Protocol Specifications. Open Whisper Systems / Signal Foundation.
• - Cohn-Gordon, K., et al. "A Formal Security Analysis of the Signal Messaging Protocol." IEEE European Symposium on Security and Privacy, 2017.

License

This specification is published under Creative Commons Attribution 4.0 International (CC BY 4.0).

You are free to implement LDA in your own applications with attribution to the original author.