Unolock Threat Model

Overview and Scope

This document presents a comprehensive threat model for Unolock, focusing on the security architecture and controls that protect user data in the Unolock “Safe”. It is intended for external penetration testers and regulatory reviewers, providing a formal, technical description of Unolock’s security posture. We cover the assets and security goals, in-scope adversaries and their capabilities, cryptographic architecture (client-side encryption, key management, zero-knowledge design), assumptions and residual risks, out-of-scope threats, and a mapping of security controls to mitigations. The model highlights how Unolock’s zero-knowledge approach, client-side AES-256-GCM encryption, post-quantum secure communication, and stateless server design defend against threats such as malicious insiders, cloud infrastructure compromise, traffic interception/analysis, and device loss. Advanced features like encrypted session state management, dual-PIN plausible deniability, and perfect forward secrecy in key deletion are also detailed. This threat model is exhaustive and precise, matching the scrutiny expected in formal security audits.

Assets and Security Goals

Assets: The primary assets are the sensitive user data stored in Unolock “Safes” – including documents, files, password records, cryptocurrency keys/mnemonics, and any metadata associated with this content. The cryptographic keys that protect this data (e.g., client-derived encryption keys, wallet seed phrases, Safe master keys) are also critical assets. Additionally, user credentials and authentication factors (such as WebAuthn key pairs and PINs) are assets to protect. Unolock handles metadata (Safe configuration, file indices) in encrypted form, treating it as sensitive asset as well. User privacy is an asset: Unolock’s design ensures that no personally identifying information or link between user identity and Safe content is stored in plaintext. The system also maintains assets related to availability, such as encrypted backups of Safes (replicated across data centers for durability).

Security Goals: Unolock’s security goals align with principles of confidentiality, integrity, availability, and privacy:

• Confidentiality: Only the Safe’s owner (authorized user) can access and decrypt their data. All user content and encryption keys are kept secret from the server, implementing a strict zero-knowledge model. Even Unolock personnel or infrastructure cannot read user secrets in plaintext. Data is end-to-end encrypted: it is encrypted on the client before leaving the device, and remains encrypted at rest in the cloud (docs.unolock.com) (docs.unolock.com).

• Integrity: Ensure that data cannot be altered undetectably. Cryptographic protections (AES-256-GCM with authentication tags, digital signatures on code) guarantee that any tampering with stored data or application code is detected. The client verifies the integrity of Safe data and app updates; unauthorized modifications (e.g., by a malicious server or MITM) will fail integrity checks.

• Availability & Durability: Legitimate users should have reliable access to their Safes. Encrypted Safe data is replicated and backed by cloud durability guarantees (e.g. multi-data-center redundancy and optional cross-region replication for higher tiers). Even if a user’s device is lost or fails, the user can recover data from the encrypted cloud backups (provided they retain their credentials). There are no hidden dependencies on single devices – multiple WebAuthn keys and backup options support account recovery without compromising security. (Note: Denial-of-service resistance is considered separately and is not the primary focus of this model.)

• Privacy and Anonymity: Minimize metadata leakage and linkage to user identities. Unolock does not store personal identifiers alongside Safes, and even payment records are decoupled from Safe records. For example, paying via Stripe or Bitcoin for a subscription does not link a user’s identity or transaction to the content of any Safe. The goal is that an external observer or even Unolock itself cannot determine what a user is storing or even which user owns a given encrypted Safe. Regulatory requests for user data cannot be fulfilled beyond providing encrypted blobs, as Unolock has no capability to decrypt user Safes or metadata.

• Authenticity and Accountability: Ensure that only authorized users can access their Safe, and that actions (like Safe decryption or key usage) require proper authentication. Unolock uses strong multi-factor authentication (WebAuthn FIDO2 keys plus a PIN) to guarantee the user’s identity and intent for access. All API communications mutually verify client and server (using key pair authentication) to prevent impersonation. Although Unolock is zero-knowledge, it maintains logs of security-relevant events (e.g., key usage, access attempts) in a manner that does not betray content but can aid forensic analysis if needed (not detailed in this model).

• Compliance: The design meets or exceeds regulatory requirements for data protection (GDPR, HIPAA, etc.) by ensuring encrypted storage, user control of keys, and proper data deletion. For instance, strong encryption and user-controlled keys support GDPR’s notions of privacy by design (docs.unolock.com) (docs.unolock.com). Secure deletion processes (discussed later) ensure data is truly gone when a user deletes it, aiding compliance with “right to be forgotten” and similar mandates.

These goals collectively inform all security controls and threat mitigations in Unolock’s architecture.

Adversary Model (In-Scope Threats and Assumptions)

Unolock’s threat model considers a range of adversaries, from opportunistic attackers to nation-state level threats. We outline the in-scope adversaries, their capabilities, and the aspects of the system they target. For each, we summarize how Unolock’s design mitigates the threat (detailed controls are expanded in later sections).

• Network Eavesdropper (Passive Attacker): An adversary who can intercept network traffic between the user’s browser and Unolock’s cloud (e.g., someone on the same Wi-Fi, or a malicious ISP or state surveillance). This attacker’s goal is to capture sensitive data in transit or glean information from traffic analysis. Capabilities: packet sniffing, recording encrypted traffic for later decryption attempts, possible use of future quantum decryption. Mitigations: All client-server communications are end-to-end encrypted with strong symmetric cryptography (AES-256-GCM) inside a TLS tunnel. In fact, Unolock augments standard TLS with a post-quantum key exchange to future-proof against cryptanalysis. Every API call is protected by an AES-256-GCM encrypted session, ensuring confidentiality and integrity of data in transit. The post-quantum KEM (lattice-based) establishes ephemeral session keys that even a quantum-capable adversary cannot derive from intercepted traffic. The server’s public key is signed with a quantum-resistant Dilithium signature, verified by the client on connection, thwarting any attempt to impersonate the server in a Man-in-the-Middle (MITM) attack. Because session keys are ephemeral and unique per session, a passive attacker cannot correlate multiple sessions or decrypt any recorded traffic. Traffic analysis is further minimized by the fact that very little metadata is carried in plaintext: most sensitive identifiers (Safe IDs, file names, etc.) are either encrypted or tokenized. The zero-trust approach means the client does not trust any network element; everything is encrypted and verified each time. (We assume the attacker cannot break standard cryptographic primitives; see assumptions.)

• Active Network Attacker (MITM): An adversary who can actively interfere with the connection, e.g., by spoofing DNS or using a fraudulent certificate to impersonate the Unolock server, or altering/transmitting messages. Capabilities: full read/write on the communication channel. Mitigations: The same cryptographic measures above defeat active attackers: they cannot penetrate the end-to-end encryption or produce valid ciphertexts without the keys. The use of verifiable server public keys (Dilithium-signed) means a fake server cannot complete the handshake. Any modification of messages in transit will be detected (AES-GCM tags and signature checks will fail). Thus, active MITM cannot trick the client or server into accepting unauthentic data. Unolock also pins or otherwise trusts only its own service domain for WebAuthn (the FIDO2 credentials are bound to the real domain), so phishing sites or proxies can’t invoke the user’s authentication token (WebAuthn requests from a non-Unolock origin won’t have access to the user’s credential). This dramatically mitigates phishing and session hijacking at the protocol level.

• Malicious Server-Side Insider or Intruder: This threat covers a rogue Unolock employee with privileged access (e.g., to databases or cloud storage) or a hacker who compromised Unolock’s backend infrastructure or the underlying cloud platform (AWS). This adversary could attempt to exfiltrate user data from servers or storage. Capabilities: reading database entries and S3 buckets, accessing server memory, or even obtaining AWS Key Management Service (KMS) keys if the cloud control plane is breached. Mitigations: Unolock’s zero-knowledge architecture ensures that server-side data is always encrypted with keys that the server alone cannot use to decrypt. All sensitive content stored on Unolock servers (Safe data, file content, metadata) is encrypted with keys that remain under client control. For example, user files and records are encrypted client-side with AES-256-GCM before upload (docs.unolock.com). Even the associated metadata (folder structure, file names, Safe config) is stored in an encrypted form using a server-side metadata key that is itself kept encrypted and inaccessible unless a legitimate user session is in progress. A malicious insider dumping the database or storage would only obtain ciphertext. Multi-layer encryption is employed: data gets a client-side encryption and an additional server-side encryption (AWS S3 Server-Side Encryption) for defense-in-depth (docs.unolock.com) (docs.unolock.com). This means an insider would need both the user’s key and AWS’s key – the former they do not have, and the latter alone is insufficient to decrypt the data (docs.unolock.com) (docs.unolock.com). Unolock uses AWS KMS such that even infrastructure admins cannot directly extract raw key material for the server-side keys – KMS will only use them as intended (and KMS access is tightly controlled). Furthermore, the Stateless Server design (see below) means that sensitive keys needed to decrypt any data are not persistently stored on the server. They exist only in memory for the duration of an authorized session and are wiped afterward. A rogue admin cannot simply query a backend to get a decryption key – the key exists only transiently when a user is online and has authenticated. Additionally, because Unolock collects no plaintext user metadata or identity info, an insider cannot even correlate which user owns which Safe beyond an opaque ID, nor glean meaningful info from usage patterns. In summary, a malicious insider or cloud intruder is contained by multiple layers of encryption and the absence of accessible secrets: “No access to Safe data”, even under regulatory pressure – Unolock technically cannot decrypt or produce customer data in plaintext.

• Compromised Cloud Provider (AWS) or Control-Plane Attack: A sophisticated variant of the above is an attacker who compromises the cloud provider’s systems (e.g., an AWS employee abusing privileges or an attacker who can impersonate the account) and tries to access data (S3 objects, DynamoDB contents, KMS keys). Capabilities: reading stored data from S3 (including AWS-managed decryption of the S3 SSE layer), attempting to call KMS to decrypt keys, or monitoring intra-cloud traffic. Mitigations: The dual-layer encryption scheme is resilient against cloud compromise (docs.unolock.com). If an attacker obtains the S3 objects, those objects are still encrypted with the client-side key (after the SSE layer is removed) – AWS’s SSE alone cannot decrypt the content to plaintext (docs.unolock.com). If the attacker also manages to get the AWS KMS keys or use them (worst-case), they could remove the server-side encryption on certain items (like a wrapped key or encrypted metadata), but would then face the client-side encryption. For example, an attacker using AWS control plane could decrypt the “server-encrypted” half-seed stored in a Safe, but would only reveal the client-encrypted half (which is useless without the user PIN/key to decrypt). The Safe master key (CDMK) and other secrets remain encrypted with keys derived from user credentials that the cloud does not have. In effect, an AWS compromise reduces the security to a single-layer of client encryption — which is by design unbreakable without the user’s key. Also, Unolock minimizes secret values in persistent storage: metadata keys are not stored in plaintext (only wrapped forms exist), and the server master keys live in KMS. Thus an AWS insider would have to subvert KMS and have active cooperation of an unaware user to decrypt a vault, which is highly improbable. Traffic interception within cloud is mitigated by the fact that all API traffic is additionally encrypted at the application layer with post-quantum ephemeral keys, so even seeing inside the TLS terminators or VPC traffic yields nothing useful. This adversary is considered highly resourced, and the measures above (zero-knowledge encryption, layered keys, KMS security) are meant to meet even stringent regulatory concerns for cloud-hosted sensitive data.

• Rogue Client or External User Attack: This considers if an attacker (e.g., another user or an outsider) attempts to breach a Safe by guessing credentials or exploiting the client application. Capabilities: guessing or brute-forcing a user’s PIN, attempting to phish or reuse a stolen WebAuthn credential, injecting malicious scripts via browser exploits to bypass client protections. Mitigations: The authentication model requires something you have (FIDO2 security key or device) and something you know (the PIN). A rogue without the physical key cannot authenticate even if they somehow obtained the PIN. The WebAuthn credentials are bound to the legitimate domain and are not phishable by a different site. Rate-limiting and WebAuthn token protections mitigate online and offline brute force. Additionally, the client app is delivered as a Progressive Web App (PWA) with integrity checking – all code updates are hashed (SHA-256) and signed (ECDSA-521). An attacker cannot tamper with the client code or deliver a malicious update without detection, as the app will verify signatures before running code updates. This protects against supply-chain attacks at the software delivery level. Unolock also has extremely restrictive Content Security Policy (CSP) settings on the web client, preventing the loading of any scripts or resources that are not explicitly allowed. This thwarts a range of web attacks (XSS, code injection). In addition, a Runtime Security Monitoring subsystem runs within the client: it actively monitors for any DOM manipulation, unauthorized scripts, or suspicious behavior in real-time. This includes blocking external script inclusion, detecting overlay attacks or illicit event listeners (often used by malicious browser extensions), and probing for known malicious extensions. If a rogue tries to inject code (say via a compromised browser extension or a transient XSS vulnerability), the client’s zero-trust runtime will detect and neutralize it in many cases. These controls significantly raise the cost for an attacker to subvert the client environment. (We note that a fully compromised client device with admin malware is out-of-scope, as discussed later, but opportunistic script injections are addressed.)

• Device Thief (Lost/Stolen Device): A scenario where the adversary has physical possession of a user’s device (e.g., laptop or phone with an active Unolock session or installed PWA). The goal is to access the Safe contents or cryptographic keys from the device. Capabilities: device access, possibly offline forensic tools to read storage, or attempting to use stored credentials. Mitigations: Unolock is designed so that no private keys or unencrypted Safe data persist on the device’s storage. The client application operates largely in memory; it flushes any sensitive material on exit or when the Safe is closed. If the device is simply found in a logged-out state, the attacker has no credentials to open the Safe – the FIDO2 credential (AIDK) is stored securely (often in a secure enclave or the external security key itself), and the PIN would be needed even if the credential is present. Without the correct PIN (which the thief would have to guess) and the ability to satisfy the WebAuthn challenge (which typically requires user presence or biometric activation on the security key), the Safe remains locked. The Unolock PIN adds an additional barrier so that even if the hardware key is stolen with the device, the attacker cannot unlock the Safe without that knowledge factor. Importantly, no plaintext secrets are stored on the device: even the Safe’s encrypted content might not be cached locally, and if it is, it remains in AES-GCM encrypted form tied to keys the attacker doesn’t have. In higher tiers, users can maintain multiple keys – so if one device is lost, they can use another to revoke the lost device’s access quickly (remote key disable). Unolock’s Timelock feature allows a user who loses a device to remotely time-disable that device’s authentication capability, buying time to secure accounts (this is a feature where a user from another device can impose a temporary lockout on a lost device’s key). Ultimately, device theft alone is intended to yield nothing: “Private keys are never stored on user devices… No one, including Unolock, has access – only the user can decrypt”. Even if the thief somehow extracts local storage, they would find only encrypted blobs (e.g., encrypted keyrings) without the means to decrypt them.

• Coercion Attack (Duress Scenario): An adversary forces the user to unlock their Safe under threat (e.g., a kidnapper or corrupt official compelling the user to reveal secrets). This is a human-threat scenario rather than technical, but Unolock includes a countermeasure in scope. Capabilities: physical coercion of the user to obtain credentials or open the Safe. Mitigations: For users in high-risk situations, Unolock offers Dual-PIN Plausible Deniability in the Sovereign and HighRisk tiers. The user can configure a second PIN that either opens a decoy Safe (with innocuous data) or destroys the real Safe data, depending on tier. Under duress, the user can enter the Duress Decoy PIN (Sovereign tier), which unlocks a plausible safe containing harmless data, so the adversary believes they’ve obtained the secrets while the real data remains safely hidden and encrypted. In the most extreme HighRisk tier, entering the special duress PIN triggers immediate, irreversible destruction of the real Safe’s data. This renders the sensitive data inaccessible to everyone (including the user, after the fact), but protects against it being used by the coercing party. All data in both real and decoy safes is encrypted with the same robust algorithms, so an adversary cannot tell if the revealed Safe is the only one. The decoy mechanism is carefully implemented to ensure there are truly two distinct data sets within one Safe, indistinguishable without the correct PIN. This provides the user with a measure of control in an otherwise uncontrollable scenario, aligning with personal safety best practices. (Of course, coercion is a dangerous threat beyond pure technical scope; this feature mitigates it to an extent, but cannot eliminate the risk to the user’s person.)

• Targeted Malware on Client (Out-of-scope with mitigations): A potent adversary might compromise the user’s device with malware (keyloggers, screen scrapers, or memory dumpers) to capture secrets. We classify this as partially out-of-scope because no software can be completely secure if the OS is hostile; however, Unolock does include client-side hardening that offers some protection (detailed in Out-of-Scope section, with best-effort mitigations like runtime monitoring and the requirement of user presence for WebAuthn). Users are also given operational guidance to split secrets across devices (e.g., view mnemonic halves on separate devices) to mitigate the impact of any single compromised endpoint.

Other potential adversaries and scenarios (social engineering, denial-of-service, side-channel attacks, etc.) are discussed under assumptions or out-of-scope, as appropriate. The following sections will detail the cryptographic architecture that underpins the above mitigations and then map these controls explicitly to each threat.

Cryptographic Architecture and Key Management

Unolock’s architecture is fundamentally built around client-side cryptography and a stateless server design. This ensures that knowledge of the keys needed to decrypt user data resides solely with the user (client), not the server. We describe the key components of this design:

Client-Side Encryption & Zero-Knowledge Key Management

Client-Side AES-256-GCM Encryption: All data added to a Safe (files, textual records, or cryptocurrency seed phrases) is encrypted on the client device using AES-256-GCM before being uploaded or stored (docs.unolock.com). AES-256-GCM was chosen for its strong security (256-bit key) and built-in authentication; it provides confidentiality and also produces an authentication tag to ensure integrity of the ciphertext. As a result, the cloud never sees plaintext data, and any alteration of the encrypted data (e.g., by a malicious actor) would be detected upon decryption due to GCM’s authentication check (tampered ciphertext simply fails to decrypt with a verifiable error).

Client Data Master Key (CDMK): When a new Safe is created, the client generates a fresh symmetric master key (CDMK) used to encrypt all data in that Safe. The CDMK is the root of the Safe’s encryption; it derives or encrypts subordinate keys (e.g., file keys, or the keyring that manages file chunk keys). Importantly, the CDMK never leaves the client in plaintext form and is not even stored persistently on the client’s disk. Instead, it lives in memory during an active session, and for storage it is wrapped (encrypted) by other keys as described below. By not storing the master key at rest on the device, Unolock mitigates the risk of device forensic extraction – an attacker who steals the device and somehow bypasses device security still cannot find the master key sitting in storage.

WebAuthn AccessID Key (AIDK) and FIDO2 Integration: User authentication relies on a FIDO2 security device (which could be a platform authenticator or roaming key like YubiKey). Upon Safe creation, along with CDMK generation, the client creates an AccessID Key (AIDK) – a random 256-bit AES key – which is sealed inside the FIDO2 device’s secure element via the WebAuthn registration process. Essentially, the FIDO2 device generates or stores this AIDK such that it can only be retrieved (via WebAuthn assertion) when the user physically authenticates (e.g., touches the YubiKey or provides a biometric) and the correct origin (unolock.com) is requesting it. The AIDK serves as a key-encryption key: it is used to initialize a client-side keyring (AIDring) which will protect other secret material.

Key Wrapping and Storage: Once the Safe is created, the CDMK (Safe master key) is encrypted (wrapped) with a key derived from the AIDK (via the AIDK keyring) before being sent to the server. We denote this wrapped master key as W-CDMK. The server receives W-CDMK and stores it, but cannot decrypt it because the wrapping key (AIDK) never leaves the user’s device. Similarly, there is a server-side generated key per Safe (described later) that is double-wrapped by both server and client keys. The net effect is that all high-sensitivity keys in storage are encrypted under at least two independent roots – one tied to the user (AIDK) and one tied to the server’s KMS – ensuring neither side alone can decrypt critical secrets.

Stateless Server and Encrypted Session State: Unolock’s server is architected to be stateless with respect to sensitive key material. This means that after the Safe creation process, the server holds only encrypted blobs (like W-CDMK) in permanent storage. When a user later wants to open their Safe, a specific protocol runs (detailed below in sequence) whereby the server temporarily obtains the decrypted Safe key in memory, under the user’s orchestration, and discards it after use. The server does not keep long-term sessions where secret keys linger between requests. Instead, each API call from the client carries an encrypted session object that includes any needed keys (e.g., the Safe’s metadata key) in encrypted form. The server can decrypt this session object using its own server-side key only during the request and only after the user has authenticated and provided one half of the puzzle (the client re-wrap of certain keys). Once the request is served, the plaintext keys are wiped and only the encrypted session blob might be returned to the client for the next call. If the client disconnects or the session ends, the server retains nothing that could be used to decrypt user data in the future. This approach limits the window of exposure for sensitive keys and means an attacker who somehow reads server memory after a session ends would find no Safe keys present.

Safe Metadata Encryption: Not just user file data, but also Safe metadata (such as Safe names, record indices, and associations) are encrypted. The server uses a Safe-specific metadata key (SDK) to encrypt all metadata stored in the backend database. The SDK itself is managed similarly to the CDMK: it is generated by the server when the Safe is created, but is immediately encrypted (wrapped by a server master key, then by the client’s AIDK) such that the server cannot on its own retrieve it later. During login, after the user authenticates, the client helps unwrap the SDK: the server sends the double-encrypted SDK (DEnc-SDK) to the client; the client uses the AIDK to remove the outer layer and returns Enc-SDK to the server; the server then decrypts the inner layer with its master key to recover the actual SDK in memory. The SDK is then used server-side (within that session) to decrypt/query the Safe’s metadata (e.g., to list files) and is stored only in an ephemeral session object (StateObj) in memory. If the session ends, the SDK is lost and cannot be recovered without repeating the user-auth process. This design means that both client and server cooperation are required to access even the metadata, underscoring the zero-knowledge stance: the server is blind to Safe structure unless the user is actively logged in and authorizing access.

User Authentication & Safe Unlock Sequence: For a step-by-step walkthrough of Safe creation and subsequent unlock, see the Safe Authentication Sequence section in our Technical Security Overview.

Within that flow, at no point does the server see CDMK or AIDK in plaintext – those remain on the client side. The server does hold the SDK (Safe metadata key) in memory during an active session, but only after the user has authenticated and released AIDK to unwrap it. Both SDK and CDMK are stored encrypted at rest (each wrapped by AIDK, and SDK further wrapped by SMK). The “stateless” nature is evident: after logout, the server would have to repeat this handshake to get access again, and cannot on its own decrypt past data or metadata. This flow also inherently provides forward secrecy for stored data: if the server is compromised in the future, past sessions’ keys are not available; if the client’s device is compromised later, the attacker still needs the server’s cooperation (SMK) to decrypt any archived data.

Client Keyring and File Encryption: Once the Safe’s CDMK is loaded on the client, it serves as the root to encrypt user data. Unolock uses a client-side keyring mechanism to derive unique encryption keys for each file or data chunk. For example, large files are chunked (e.g., into 10 MB segments) and each chunk is encrypted with a distinct AES-256-GCM key from the keyring. The keyring ensures no single key is reused excessively, limiting the impact of any single key’s exposure and strengthening security against cryptanalysis. The keyring’s structure (often implemented as a hierarchical key derivation or a set of randomly generated keys protected by the master) means the CDMK can derive all necessary sub-keys but sub-keys alone cannot derive the master. Additionally, the keyring header (which may contain wrapped keys or metadata about keys) is itself obfuscated: it’s XOR-encrypted with random per-chunk keys that are stored server-side. This clever design means that an attacker who somehow stole all the encrypted files and even the client’s CDMK would still be unable to decrypt the file content without those random XOR pad keys from the server. It’s another layer of defense ensuring that the server has a role in reconstructing data (and if data was properly deleted server-side, even a leaked CDMK cannot decrypt what remains).

AWS S3 Server-Side Encryption (SSE): On top of client-side encryption, Unolock leverages AWS S3’s managed encryption for all stored blobs (docs.unolock.com) (docs.unolock.com). When the client uploads an already-encrypted file or key blob to S3 (using a time-limited presigned URL), AWS automatically applies SSE-AES256 encryption at rest. This is a separate AES-256 layer managed by AWS’s storage service. The result is dual-layer encryption for data at rest: the data is encrypted by Unolock (client) and again by AWS (server) (docs.unolock.com). The keys for these two layers are distinct and independently controlled (client’s key under user control, SSE key under AWS control or in KMS) (docs.unolock.com). This approach means that even if one layer were compromised, the data remains protected by the other (docs.unolock.com). For instance, if an attacker broke AES at the AWS layer (or obtained the AWS SSE key), they only reveal the still-encrypted client data which is indecipherable (docs.unolock.com). Conversely, if somehow the client encryption were weak (not the case with AES-256) or user’s key leaked, the SSE layer would provide a second hurdle (albeit a weaker one if the cloud is assumed trusted). Importantly, SSE is transparent to Unolock users – it does not affect the zero-knowledge model because AWS never sees the plaintext; it’s simply an extra barrier for an attacker who has gained access to the storage system. The use of SSE also assists with regulatory compliance, as it ticks the box for “encryption at rest” using validated cloud mechanisms (docs.unolock.com), while the client-side encryption ensures true privacy (docs.unolock.com).

Post-Quantum Secure Communication: While not about data at rest, it’s worth noting the cryptographic rigor in transit. Unolock has implemented a post-quantum key exchange and authentication for its client-server API channel. In practice, this means during the TLS handshake or as a layer within it, the server uses a lattice-based Key Encapsulation Mechanism (KEM) to establish a shared symmetric key, and signs the ephemeral public key with a Dilithium post-quantum signature. The client verifies the signature using the server’s long-term Dilithium public key (distributed or hard-coded securely). This replaces the traditional ECDHE/ECDSA handshake, ensuring that even an adversary recording all traffic today cannot decrypt it in the future, even if quantum computers become available. This forward-looking measure protects against “harvest-now, decrypt-later” threats. The result is an extremely hardened transport layer: every session has a unique, ephemeral key (unpredictable and quantum-secure) and the server’s identity is cryptographically verified, preventing MITM with forged certs. All API calls are then end-to-end encrypted within this channel using symmetric encryption (often double-encrypted: once by TLS/PQ layer, and again by the application’s own AES-256-GCM payload encryption). This reflects a zero-trust communications stance: the system assumes the network (even the cloud network) may be hostile and thus adds extra layers beyond standard TLS. As a benefit, it also aligns with compliance regimes that call for state-of-the-art encryption and future-proofing against quantum threats.

Advanced Security Features

Dual-PIN Plausible Deniability: As described in the adversary section, Unolock supports a dual-PIN mechanism where one PIN opens the real Safe and a second PIN opens a decoy Safe (or triggers destruction). Cryptographically, this is implemented by effectively having two sets of Safe encryption keys or key indexes under two different PIN-derived unlock codes. Both sets are stored encrypted and are indistinguishable without the correct PIN. Entering the decoy PIN will decrypt only the decoy Safe’s keys, leaving the real Safe’s keys inaccessible (and in the HighRisk case, actively deleting them). All data – real and decoy – is encrypted with AES-256 such that an attacker cannot tell which one is “sensitive” just by ciphertext. The irreversible destruction on the HighRisk tier is accomplished by secure deletion of the real Safe’s master key when the duress PIN is used. Once that key (and its server-wrapped copies) are wiped, even the ciphertext in storage becomes undecryptable. This feature doesn’t introduce cryptographic weaknesses since it essentially doubles the stored key info (one for each PIN) and associates them with different PIN hashes. It’s implemented carefully to avoid any subtle metadata leaks (for example, the server only sees an authentication token and cannot tell which PIN was used; the choice of Safe data set to present is decided client-side after deriving keys with the entered PIN). This ensures plausible deniability is maintained.

Multi-Key Support and Key Rotation: Unolock allows users to register multiple WebAuthn authenticators per Safe (e.g., multiple security keys or passkeys). Each key essentially gets its own AIDK (or shares the same AIDK stored in multiple authenticators). This provides resilience – losing one key does not lock the user out, and it also means an attacker needs all registered keys (and PIN) to fully compromise access. Keys can be revoked if lost (the Safe owner can delete a lost key from the Safe’s allowed list using another key). The system encourages a mix of key types (platform passkeys for convenience, and hardware keys for independence) to avoid ecosystem lock-in or single points of failure. Additionally, Unolock’s LockoutGuard and LegacyLink are features (in intermediate tiers) to help recover access in case all user keys/PINs are lost, without the service itself being able to decrypt anything. LockoutGuard involves configuring a time-delayed recovery mechanism that the user sets up (details beyond this document’s scope), but crucially it’s user-opt-in and maintains zero-knowledge (e.g., a user might entrust a recovery code to a third party.).

Secure Deletion and Forward Secrecy for Stored Data: Unolock provides strong guarantees when users delete data or entire Safes. If a user deletes a file from a Safe, the system not only deletes the encrypted file from storage but also deletes the associated encryption metadata/keys in the keyring. Because that metadata (e.g., the file’s symmetric key or the index in the keyring) is necessary to ever decrypt the file, deletion of it makes the remaining encrypted file bytes useless. This approach is akin to crypto-shredding: rendering data unrecoverable by destroying keys. Deletions are immediate and irreversible – no undelete – to ensure compliance with data sanitization requirements. When an entire Safe is deleted, Unolock securely erases all related keys (CDMK, SDK, etc.) and data such that even offline copies of ciphertext cannot be recovered. For example, the server-side archive key (KEK) concept: each archive (Safe or file) may have a unique key-encrypting-key that is deleted on removal, providing perfect forward secrecy for data at rest. If an attacker had historically copied some encrypted data, and later the user deletes that data on Unolock, the KEK deletion means even if the attacker somehow got the user’s master key later, they still couldn’t decrypt the deleted data. This is an advanced guarantee that a future compromise of keys does not retroactively compromise past deleted data – aligning with the idea of forward secrecy in the storage realm. These deletion guarantees help with regulatory compliance (e.g., GDPR data erasure) and ensure user control over data lifecycle.

Monitoring and Trusted Execution: Finally, Unolock’s threat model is complemented by client-side security monitoring (already touched on) and by leveraging secure execution environments when possible. The use of the WebAuthn API inherently taps into secure hardware (TPM, Secure Enclave, or dedicated security keys) for cryptographic operations, which means the private keys for authentication and often encryption never leave secure hardware. Additionally, when viewing files in the Unolock client, the application uses in-memory decryption only – it will decrypt files on the fly in RAM for viewing and never write the plaintext to disk or even to a persistent DOM storage. This protects against forensic recovery of sensitive file contents. Users are advised (and the app is designed) to flush memory and avoid any swapping; e.g., closing a file view will actively overwrite and free memory buffers. The app also has protections to disable copy/paste or screenshot for certain sensitive views to reduce accidental leakage (not explicitly covered above, but implied by “overlay detection” and such features). All these measures strengthen the overall cryptographic guarantees by ensuring the encryption isn’t undermined by side-channel leakage or user error.

In summary, Unolock’s cryptographic architecture ensures that: (a) Data confidentiality relies on keys that only the user possesses (zero-knowledge to server); (b) Multiple encryption layers and key-wrapping are used to defend against partial compromises (docs.unolock.com); (c) The server cannot access even metadata without user participation; (d) Sessions are ephemeral and cryptographically isolated (post-quantum and zero-trust); and (e) Additional features (plausible deniability, secure deletion, multi-key auth) address niche but important threat scenarios.

Assumptions and Residual Risks

No threat model is complete without stating the assumptions (conditions we assume to be true or in place) and acknowledging residual risks (threats that remain or cannot be fully mitigated without unacceptable trade-off). Below are the key assumptions and residual risks for Unolock:

Assumptions:

• Cryptographic Primitives Are Secure: We assume that AES-256-GCM, SHA-256, the lattice-based KEM, Dilithium signatures, and other cryptographic algorithms used have no feasible practical attacks in 2025. AES-256 is assumed quantum-resistant in the sense that while Grover’s algorithm can theoretically halve its effective key length, 128-bit security is still sufficiently strong. The post-quantum algorithms (KEM, Dilithium) are assumed secure against both classical and quantum adversaries as per current understanding. We also assume the random number generation on client devices and within the FIDO2 authenticators is cryptographically strong.

• User’s Device Integrity: We assume the user’s endpoint is not fully compromised by malware. While Unolock’s client has measures to detect tampering (CSP, runtime monitoring), a heavily infected system (rootkit, keylogger, screen capture malware) could undermine all client-side protections. The model assumes users follow basic security hygiene: they use a trustworthy device, up-to-date browser, and do not install untrusted software or extensions. If the user’s OS or browser is malicious, the confidentiality of data at the moment of usage can be lost (e.g., malware could capture the plaintext when the user views it). This is considered out-of-scope to prevent completely (as no userland application can overcome a hostile OS), though our design limiting exposures (split-key viewing, memory flushing) helps reduce the window.

• Physical Security of FIDO2 Keys and PINs: We assume users keep their security keys (or devices with passkeys) safe from unauthorized access, and keep their Unolock PIN secret. The WebAuthn credentials are typically protected by user presence/biometric requirements on the device itself, but if an attacker steals a security key and somehow knows the PIN, they could impersonate the user. We rely on users not to write down the PIN insecurely or choose an easily guessable PIN. (The system may enforce some PIN complexity or attempt limits – e.g., FIDO2 itself often throttles repeated incorrect PIN attempts, and Unolock’s server rate-limits as well.)

• Server-Side Integrity: We assume the Unolock server code, when not under attack by an insider, functions correctly as designed. That is, the protocols for key wrapping, session handling, deletion, etc., are implemented correctly and do not contain backdoors or critical bugs. Code reviews and audits are assumed to be done to validate this. We also assume the underlying cloud platform (AWS) provides its advertised security (e.g., KMS does not suddenly leak keys; S3’s SSE is properly implemented; AWS infrastructure vulnerabilities, if any, remain hypothetical or get patched). In case of an AWS-level breach, our design still holds confidentiality, but we assume AWS is not maliciously sabotaging cryptographic operations.

• No Malicious Collusion with Third Parties: We assume that Unolock, as a company, will not secretly collude with governments or other entities to weaken the encryption. The threat model acknowledges regulatory reviewers might consider lawful access demands; Unolock’s stance (zero-knowledge) is that it cannot comply with any request to hand over plaintext because it literally does not possess the means. We assume regulators accept the implementation of strong encryption in good faith (since weakening it is out-of-scope and counter to our security goals).

• Users Manage Backups/Recovery Properly: If users opt to use backup features like LegacyLink or print out recovery keys, we assume they handle those securely (e.g., store physical papers in safes, not share recovery links unwisely). The security of those mechanisms is as good as the user’s protection of them. Similarly, multi-key redundancy assumes users will register backup keys and keep them safe.

• Browser/Framework Security: The Unolock web application is assumed to be delivered over secure channels (HTTPS) and loaded in modern browsers that enforce CSP and other security features we rely on. We assume the absence of unknown browser vulnerabilities that could allow an attacker to bypass our sandbox (though we mitigate many via runtime checks). The PWA signature mechanism assumes the user initially trusts the application (perhaps delivered from a secure site) and thereafter the signature checks hold; we assume no one can steal the signing key used for the PWA or that such a compromise would be quickly detected.

Residual Risks:

• Client-Side Compromise during Active Session: If despite our assumptions, an attacker manages to run malware on the user’s device during an active session, they could potentially snatch secrets as the user uses them. For instance, a Trojan could read the screen or keylogger could capture the user’s PIN. WebAuthn prevents credential phishing, but it does not prevent an active keylogger from reading what the user enters. Our mitigations (monitoring, alerts) may catch some browser-based malware but not a fully privileged OS malware. Residual risk is that a sophisticated attacker who has already compromised the user’s machine can obtain whatever the user legitimately can in that session (data in use). This is a general risk in any end-to-end encryption system: when endpoints are compromised, encryption doesn’t help. Unolock minimizes the impact (encouraging splitting secrets across devices, as with mnemonic halves, so one device’s compromise doesn’t yield everything), but cannot eliminate this risk. Users dealing with high stakes may need to operate only in very secure environments (e.g., a clean, dedicated device) to truly counter nation-state malware threats.

• User Behavioral Risks: Despite technical measures, users might make mistakes that result in exposure. For example, a user might choose to view both halves of a split key on the same compromised device (defeating the purpose of splitting). Or they might reuse the same password or PIN elsewhere that gets leaked. Or they could fall for a phishing email that leads them to reveal their PIN or install a fake “Unolock” app. We mitigate many of these (phishing domain can’t replicate WebAuthn, and an offline attacker with just PIN still needs the FIDO key), but some social engineering vectors remain. For instance, an attacker could trick a user into thinking they need to register the attacker’s device as a WebAuthn key (unlikely, but users have been tricked into worse). Education and security warnings are part of the approach, but user complacency is a residual risk.

• Quantum Computing (Long-term): Unolock has taken steps to be quantum-resistant in communications, but the stored data’s encryption (AES-256) could theoretically be weakened by a future quantum computer (to ~128-bit security). 128-bit security is still extremely robust, but looking ahead decades, if a full cryptographically relevant quantum computer arises, AES-256 might require an upgrade (to AES-256 doubled or a quantum-safe symmetric). The risk is currently negligible, and our design can be migrated to new ciphers if ever needed (e.g., by re-encrypting data with a new master key derived from a post-quantum algorithm – an operation that could be done client-side with a software update). We assume any such development would be gradual and accompanied by new standards, giving time to react. Similarly, if lattice or Dilithium schemes are later found flawed, we would rotate to new post-quantum algorithms as needed. In summary, no immediate risk, but in the very long term crypto agility is needed (we already designed for that by not hard-coding algorithms too rigidly).

• Insider Threat beyond Cryptography: While no Unolock insider can decrypt user data, a malicious insider could still cause harm in other ways (a residual risk in any service). For example, they could sabotage code (though code signing and reviews mitigate this), or they could attempt denial-of-service (deleting data or refusing service). Unolock has internal controls (like multiple approvals for code changes, monitoring of admin actions) which are beyond the scope of this document. But an insider could, say, attempt to quietly alter the client and server code to log user keys if they got their malicious code past reviews and signature checks and somehow got access to the production environment. This is highly unlikely and would be swiftly noticed, but it’s a theoretical risk in the absence of formal verification of all code. We consider it very low likelihood due to organizational controls and the fact that any such attempt would break the client’s security guarantees that users or open-source auditors could detect (since the threat model is public, any code asking for user secrets or deviating from the protocol would be suspect).

• Denial of Service (DoS): An attacker might not be able to read data, but they could aim to destroy or block it. For instance, a malicious actor could try to flood the service with traffic. Unolock has rate-limiting and DDoS protections at an infrastructure level (AWS Shield, etc.). We assume high availability architecture reduces DoS risk, and backup snapshots (encrypted) could be restored if an internal attacker deleted infrastructure data. So DoS is a concern but more on the availability side, which is handled by standard scalability and backup practices.

• Total Key Loss: If a user loses all their authentication factors and credentials (e.g., loses their FIDO keys and forgets their PIN, and did not set up any recovery mechanism), their Safe becomes irrecoverable. This is not so much a vulnerability as a consequence of the zero-knowledge design – it’s a trade-off. Unolock cannot magically restore access because doing so would imply some kind of escrow of keys, which they deliberately avoid. This residual “risk” is actually by design: the user carries the responsibility to maintain access to their factors or set up the optional LockoutGuard (if available) for emergency recovery. Regulatory reviewers will note this as a self-custody property (similar to losing a private key to a crypto wallet – the service cannot help if it’s truly zero-knowledge). Users should register multiple keys and use provided backup features to mitigate the chance of permanent lockout. From a threat perspective, an attacker cannot exploit this, except as denial-of-service by somehow ensuring a user loses access (which is beyond a typical attacker’s capability unless they physically steal all keys and ensure the user has no backup).

• Metadata Analysis: While we encrypt metadata on the server, some minimal info might be observable by an attacker. For example, an attacker might not see file names or contents, but could see sizes of encrypted blobs or timing/frequency of user access. Traffic analysis might reveal when a user accesses their Safe and roughly how much data is transferred (though padded or chunked transfers could mitigate size leakage). The residual risk is that a sophisticated adversary might infer patterns (e.g., “user X uploaded a ~10MB file at time Y”). The use of constant-size chunks for files to reduce this leakage (10MB chunking means file sizes are not directly evident beyond the nearest 10MB, and everything else is just ciphertext lengths). Still, some side information is inherent in any system (e.g., which IP address is accessing the service). We consider this low impact (does not reveal actual secrets) and acceptable in exchange for performance. In a future iteration, mix networks or proxy routing could be introduced if needed to further hide usage patterns, but that’s outside our current scope.

In conclusion, the residual risks that remain are either fundamental to endpoint security or chosen trade-offs to maintain a strong security posture (e.g., risk of user losing keys). These are deemed acceptable in the context of Unolock’s goals, and we address them via user guidance and optional features where possible. The system is designed so that there is no single point of catastrophic failure: most failures require both a user mistake and a technical breach, or are mitigated by layered controls (defense-in-depth).

Out-of-Scope Threats

We explicitly list threats that are out-of-scope for the Unolock threat model – typically because they are beyond what the application or service can reasonably control, or they would require sacrificing core principles to address. Out-of-scope means these are not directly mitigated by Unolock (or only partially mitigated as noted), and often require user awareness or external safeguards:

• Compromised User Endpoint (Malware/Rootkits): As mentioned, if the user’s device is thoroughly compromised (e.g., by a keylogger, screen capture malware, or OS-level trojan), Unolock cannot guarantee the secrecy of data while it’s being used on that device. We do include client-side defenses (CSP, runtime checks) that raise the bar for browser-based malware or malicious extensions, but a kernel-level keylogger or a sophisticated APT implant is out-of-scope. Users in high-risk environments should assume their device must be clean; using hardware like Qubes OS or dedicated offline devices for viewing could be advisable. Unolock’s zero-knowledge server-side stance cannot counter an attacker who observes the plaintext directly on the user’s screen or steals the user’s unlocked device.

• Physical Threats to User Safety (beyond dual-PIN): While we have the dual-PIN plausible deniability feature for duress, no technology can cover all scenarios of coercion or threats to life. If an adversary is willing to use violence, the user’s personal safety comes first. The duress PIN mechanism is provided, but its correct use is up to the user and it carries its own risk (e.g., accidentally using the duress PIN in a non-duress scenario would delete data in HighRisk tier). Extreme scenarios like torture are obviously out-of-scope; no cryptographic system can withstand an adversary with unlimited physical control over the user. Unolock at least provides a tool for plausible deniability, but cannot guarantee safety in extreme cases.

• Social Engineering (Phishing, etc.) to Obtain User Credentials: We consider direct phishing for the user’s Unolock PIN or tricking them into revealing secrets out-of-scope for the system to fully prevent. That said, Unolock’s design greatly limits the damage of phishing: an attacker would need to phish both the PIN and somehow the WebAuthn token (which is not phishable via a fake website due to origin binding). This usually means the attacker would have to phish the user into registering the attacker’s device as a key (which requires user consent and physical auth on their device) – a complex con. Nonetheless, standard phishing (asking the user to read off their 24-word seed, for example) is possible if the user is not educated – no technical measure stops a user from willingly exporting and giving away their keys. Unolock’s stance is to encourage good practice (the app doesn’t encourage full mnemonic exposure except in split halves and warns about phishing in its UI). Ultimately, user vigilance is needed; pure social attacks are out-of-scope of a technical solution.

• Compelled Backdoor or Key Escrow: If a government or regulator tried to force Unolock to implement a backdoor (key escrow or exceptional access mechanism), it would violate the very design of Unolock. The threat model explicitly excludes any backdoor, and any such demand would make the system untrustworthy. Unolock’s policy is to be zero-knowledge; thus it cannot comply with secret demands to provide plaintext. This is a legal/organizational threat which we treat as out-of-scope in the technical model. (From a regulatory perspective, this might be documented as “Unolock has no technical means to comply with wiretap or data disclosure orders on encrypted content.”)

• Attacks on Underlying Infrastructure Availability: Broad denial-of-service attacks, such as a DDoS on Unolock servers or on the DNS, are out-of-scope in this threat model. They do not give access to data, only can disrupt service. Unolock uses standard cloud measures to mitigate DDoS (AWS scaling, WAF, etc.), but these do not affect data security and are handled operationally. Similarly, catastrophic events (natural disasters affecting data centers) are handled by backups and multi-region support, which we have covered as availability measures but not as “threats” per se.

• Side-Channel Attacks on Encryption Implementation: Highly sophisticated attacks like timing analysis, electromagnetic monitoring of the user’s device while it’s encrypting data, or differential fault analysis on the cryptographic implementations are out-of-scope. We assume the cryptographic libraries (WebCrypto, etc.) are implemented in a sufficiently secure manner against standard side-channels in software. Hardware side-channel (like someone having physical sensors near the user’s hardware) is beyond our scope. In extremely high threat profiles, users might mitigate by using devices known to be side-channel resistant, but Unolock itself does not specifically address, say, TEMPEST attacks.

• User Collusion or Malicious Use: If someone uses Unolock for malicious purposes (like storing illicit content) and an adversary (law enforcement) tries to attack the system to get that content, the system’s stance is still zero-knowledge – we cannot help. But dealing with such scenarios (like handling of abuse, user misbehavior) is out-of-scope from a threat model perspective (it’s more of an acceptable use / policy issue). Likewise, if multiple users share a Safe and one turns malicious (insider threat at user level), that enters user access policy territory – Unolock does support read-only keys, admin keys, etc., to limit what a malicious authorized user could do, but if you give someone admin access to your Safe, cryptography won’t stop them from reading data. Key management features (like the ability to have read-only keys, or to disable a key remotely) help mitigate an authorized insider threat among collaborators, but ultimately trusting another user is outside the pure technical scope.

• Future Unknown Attacks: We cannot foresee every possible novel attack. For example, if a breakthrough in mathematics significantly weakens AES or some unforeseen vulnerability in FIDO2 is discovered, those would be out-of-scope until known and mitigated. The threat model is a living document and will be updated as new classes of attacks become relevant (e.g., if one day client browsers support enclaves or some new defense, we’d incorporate that, or if a weakness in our chosen KEM is found, we’d replace it). At present, we consider our choices conservative and strong.

Summarily, out-of-scope threats are those requiring user-side total security, user behavior beyond system control, or forcing the service to act against its design. Unolock’s model seeks to eliminate as many avenues of attack as possible while acknowledging it cannot solve all security problems (especially those at the human or hardware level).

Security Controls Mapping to Threats

The following table summarizes how Unolock’s security controls map to the threats discussed, providing a quick reference of mitigations for each threat scenario:

Table Legend: Each threat from the adversary model is listed with key security controls that mitigate it. Citations refer to design details in Unolock documentation supporting the stated control. Collectively, these mappings show that for every considered attack vector, Unolock has one or multiple layers of defense (“defense in depth”).

Conclusion

In this threat model, we have outlined how Unolock’s architecture upholds strong security and privacy guarantees even against determined adversaries. The assets (user data and keys) are protected by comprehensive cryptographic measures aligning with the security goals of confidentiality, integrity, availability, and privacy. We detailed an adversary model ranging from network attackers to malicious insiders and device thieves, and showed how Unolock’s design – particularly its zero-knowledge client-side encryption, post-quantum secure communication, and stateless key management – mitigates each threat. We described the cryptographic architecture in depth, including multi-layer encryption (client-side AES-256-GCM and AWS SSE) (docs.unolock.com), key wrapping with WebAuthn (AIDK/CDMK), encrypted metadata with client-controlled access, and special features like plausible deniability (dual PIN) and secure deletion with forward secrecy. We stated important assumptions (e.g., secure endpoints, uncompromised cryptography) and acknowledged residual risks (like device malware during use and user operational errors), as well as clearly marking out-of-scope threats (such as fully compromised user devices and physical coercion extremes). Finally, we presented a mapping of controls to threats, illustrating how Unolock’s security measures provide layered protection.

From a regulatory and audit standpoint, Unolock demonstrates compliance with stringent security standards: encryption of data in transit and at rest, strong customer authentication, privacy by design (no access to user data by the service), and robust data governance (the user has sole control to access or destroy their data). The use of modern cryptography (including post-quantum algorithms) shows a forward-looking approach to emerging threats. The stateless, zero-knowledge architecture means that even if compelled, Unolock cannot violate user confidentiality – an important consideration for jurisdictions with data access demands, which positions Unolock as an end-to-end encrypted service provider.

Penetration testers reviewing Unolock should focus on the client side (ensuring no weaknesses in the implementation of these controls, e.g., CSP bypass, side-channel leakage) and the integration points (such as the WebAuthn implementation, to ensure no downgrade attacks). They should also verify the proper destruction of keys on deletion and that no plaintext ever touches persistent storage or logs. This threat model can guide such tests by highlighting the intended security properties that must hold (e.g., “keys and plaintext never exist on Unolock servers” is a claim that can be validated by code review and testing memory dumps).

In conclusion, Unolock’s threat model showcases a high-assurance design. By combining a zero-trust, zero-knowledge philosophy with strong cryptographic mechanisms and thoughtful features for usability and recovery, Unolock achieves a security level suitable for protecting highly sensitive data (like cryptocurrency secrets and personal records) even under concerted attack. This document can serve as a basis for external audit, demonstrating that security has been considered at every level of the system and that controls map systematically to threats.