Article 4: Understanding the Memory Forensics Threat Model

4.1 The Vulnerability Window

Encryption protects data at rest. However, to perform its function, LockRoot must decrypt the vault into RAM while the application is unlocked. During this window, the master password, the derived AES-256 key, and the plaintext entries (usernames, URLs, passwords) reside in the application’s memory space.

If an attacker gains root privileges (e.g., via a compromised device, jailbreak, or physical extraction of the RAM), they can use tools like ptrace or core dumps to scrape the application’s memory and extract the secrets.

4.2 Defeating the Garbage Collector

In managed languages (Kotlin, Swift, C#), memory management is handled abstractly. When a string falls out of scope, the memory is not immediately zeroed; it is marked for eventual cleanup by the Garbage Collector (GC). This creates an unpredictable window where secrets remain in RAM.

LockRoot mitigates this by aggressively converting user input into mutable byte arrays or Data objects as early in the execution flow as possible.

  • Android: The UI explicitly extracts the password into a CharArray. When derivation completes, Arrays.fill(bytes, '\u0000') is executed, guarded by a volatile sink to prevent JIT compiler stripping.
  • iOS: The password is converted to Data, and sodium_memzero is called within a defer block.
  • Windows: CryptographicOperations.ZeroMemory() is executed on ReadOnlySpan<char>.

4.3 The Limits of Software Defenses

While these explicit zeroing techniques significantly raise the bar against memory forensics, they are not a panacea. The operating system may page RAM to a physical swap file on the disk. Furthermore, UI frameworks (like SwiftUI or Android Compose) often internally allocate immutable strings during rendering that the developer cannot access or manually zero.

LockRoot’s architecture acknowledges this reality: it guarantees memory erasure for the cryptographic keys and the raw password buffers, but assumes that a fully compromised, rooted host operating system represents an unrecoverable breach of the trust boundary.