Technical Security Overview

Last Updated: November 2, 2025.

UnoLock: Technical Security Overview

Introduction

UnoLock is a zero-knowledge, post-quantum secure data vault built on the principle of Data Self-Governance as a Service (DSGaaS). It is architected to provide complete user control and anonymity, ensuring that sensitive data is protected from all threats, including those from compromised servers or physical device theft. Security is the primary concern of each design choice at every stage. Security in-depth helps ensure that no single design or implementation error can cause exposure of user data. The choice of being a web app has its pluses and minuses but was chosen for its isolated sandboxed environment to help stop data exfiltration and enhance data accessibility. The security model relies on the server to enforce access controls, so Internet access is a requirement for the client. One significate less typical security requirement affecting the overall architecture was to protect the user from having their data used against them.

Three-Party Consent Model

UnoLock’s security posture is anchored by two core design principles: no single points of failure and defenses that do not rely on perfect user behavior. Every subsystem is layered so that compromising a Safe would require deliberate, coordinated effort across multiple independent barriers. Security is the default state, not something that depends on operational habit or procedural best-case scenarios.

At the center of this approach is the Three-Party Consent Model. Access to any Safe demands active, authenticated participation from three distinct entities before any sensitive action is permitted:

The Owner: Authenticates through UnoLock’s keylogger-resistant PIN system, ensuring explicit user intent.
The Device: Verified via phishing-resistant FIDO2/WebAuthn, using a hardware-bound credential unique to each device.
The Server API: Authenticated through a post-quantum cryptographic key exchange (ML-KEM-1024/Kyber) that augments standard TLS.

This triple-consent mechanism removes single points of compromise; even if one element were controlled, the other two independent verifications block unauthorized access. The additional ML-KEM-1024 handshake establishes a post-quantum secure session key between client and server, keeping traffic encrypted end-to-end and resilient against man-in-the-middle or infrastructure-level threats.

Implementation note: The post-quantum handshake is implemented with the @noble/post-quantum library. Today there are no third-party audited JavaScript implementations of ML-KEM-1024 that meet our deployment constraints, so this dependency provides a minimal, purpose-built codebase we can reason about and monitor. The library never encrypts user payloads; it simply establishes an additional post-quantum session key layered above industry-standard TLS, leaving all data encryption to the well-vetted primitives described later in this document.

All cryptographic operations, including encryption and decryption of user data and keys, occur exclusively on the client-side within the browser's security sandbox. The server is completely stateless and has a zero-knowledge design for user-generated content: titles, notes, files, and cryptographic material live only inside a single CDMK-encrypted S3 object per Space that the server cannot decrypt. The DynamoDB records the API maintains are limited to Safe configuration metadata (device bindings, state handles, upload manifests) needed to coordinate sessions, and even this data can only be decrypted transiently inside an authenticated API flow. The server never sees user-entered plaintext.

This document provides a detailed technical breakdown of the cryptographic protocols, security features, and operational security measures that underpin the UnoLock platform. It is intended for security researchers, auditors, and developers seeking a deep understanding of the system's architecture.

Most cryptographic operations are performed using the AWS Encryption SDK, which applies envelope encryption with AES-256-GCM and a data key wrapping model.

Core Architectural Principles

Server-Side Architecture: Stateless and Zero-Knowledge

The Server-side API is serverless multi-region and stores all metadata in a regionally replicated fully managed datastore. This reduces the attack surface area and helps mitigate DDOS attacks.

Stateless Design: The server is completely stateless between API calls. It does not cache or store any unencrypted user data or cryptographic keys in memory or on disk. All necessary session information is passed from the client in an encrypted state object within each API request.
Server Master Key: The API server has a keyring it uses for cryptographic functions. The keyring is initialized by retrieving the a wrapped key from cloud storage, the Server Master Key (SMK), and having it unwrapped by a KMS. on initialization.
Server Metadata Encryption: All serverside Safe metadata is encrypted using a unique Safe Database Key generated by the server for each Safe and or with the servers SMKring. The server does not store the SDK in plaintext. On the SDKs generation it is wrapped by the SMKring and immediately sent to the client to be wrapped by the client-side AccessID Key (AIDK) initialized keyring AIDKring. Only this client-wrapped version of the server wrapped SDK is persisted in the server's database linked to the AccessID. The client never sees the clear text SDK.
Zero-Knowledge Access Control: For the server to access a user's Safe metadata (e.g., to retrieve a list of archives), it needs the SDK. During authentication the server retrieves the double wrapped SDK from its database and sends it to the client who unwraps it using its AIDKring and returns it to the server. The server unwraps the received SDK and adds it to the SMKring envelope encrypted, AES-256-GCM, state object (StateObj) returned to the client. The client can not decrypt the StateObj. Later when the server recieves an API call from a client it receieves the encrypted StateObj as part of the request. The server decrypts the StateObj containing the clear text SDK with SMKring and uses the SDK to decrypt the Safes metadata retrived from the servers database. On API return all keys and data are whiped from memory. This ensures that the server can never access user metadata from outside a particular authenticated API request from the client. Also if a bad actor had a copy of the server database data and a compromised client, they would have nothing because the client never sees the SDK.

Client-Side Cryptography and Key Hierarchy

The application's security is built on a robust key hierarchy. Master keys are never used to encrypt data directly. Instead, they are used to initialize a client-side keyring (specifically, the RawAesKeyringWebCrypto from the AWS Encryption SDK). This keyring then performs all subsequent cryptographic operations, such as wrapping other keys and encrypting data.

Safe Accesses: A Safe is accessed through an AccessID represented to users as a FIDO2 hardward key / Passkey or as LockoutGuard/LifeSafe recovery methods. A Safe can have multiple AccessID associated with it. Each AccessID has a unique AccessID Key (AIDK) which is a client side securely generated random cryptographic key used to initialize the client-side keyring during authentication. The AIDKring is NOT used to perform operations on client data. The AIDK is stored either in a WebAuthn supported device or derived from a provided LockoutGuard/LifeSafe recovery code only after lockout detection timer triggers. The AIDKring is used during authentication to decrypt the servers SMKring wrapped SDK used by the server to access metadata from its database. The AIDKring is also used by the client to unwrap the Client Data Master Key (CDMK) received from the server post authentication. Additionaly these operations act as an additional method for the client to authenticate the server.
Client Data Master Key: During initial Safe creation, the client generates a secure random 32 byte Client Data Master Key (CDMK). This key is used to encrypt and decrypt all user data (Records and files). It is wrapped by the clients AccessID AIDKring and sent to the server to be stored. The CDMK is not persisted on the client and therefor can not extracted by an attacker with device access. The server also never sees the clear text CDMK so it can not be extracted by an attacker with access to the server or its databases. Post authentication with an AccessID the API server returns the AIDKring wrapped CDMK. The client unwraps the CDMK with the AIDKring and then reinitializes the client keyring with the CDMK. Immediately after the keyring is re-seeded, the raw CDMK buffer is zeroized and released so only the CDMKring retains key material in memory. Derived passphrase hashes, base64-decoded key material, and the buffers relayed to the service worker are likewise copied into scratch arrays and wiped in finally blocks once WebCrypto CryptoKey handles (imported as non-extractable) are created. The CDMKring is now used for the majority of client data cryptografic operations. The CDMK is held in memory only via the CDMKring and never stored persistently. The client has an inactivity timer that will cause page reload triggering the wiping of all cryptographic material.
FIDO2 / WebAuthn Flow:
During device registration, a random AIDK 32 byte key is generated and stored on the FIDO2 authenticator as the user.id byte array during registration. The user.id field is removed when performing WebAuthn operations with the server.
Lockout Guard / Life Safe:
Lockout Guard and Life Safe are optional backup AssessIDs that are normaly disabled. Registering multiple Webauthn keys is the prefered and recommended way to mitigate webauthn key loss. If configured, Lockout Guard and Life Safe can be used to recover Safe access in the event of Webauthn/passkey vendor lockout or loss. While they are disabled they do not represent a security risk. They become enabled by a user controled Safe inactivity timer. In this instance, the AIDK is derived from a code generated from a clientside generated random passphrase and ID. No user input is ever used to generate crytpographic material. When a backup AccessID is used to recove a Safe, the user is forced to register a new Webauthn backed AccessID and all other access methods are deleted including LockoutGuard and LifeSafe. LockoutGuard and LifeSafe AccessIDs are single use and can not be used as an alternative vulnerable access method similar to username / password.

Secure Client-Server Communication

The client-server API interaction is facilitated via JSON Callbacks, which drive the server's state machine. The session state information (StateObj) is encrypted by the server and passed back and forth in these Callbacks, existing only in memory on the client.

Session Encryption: ML-KEM-1024 (Kyber) @noble/post-quantum: Kyber is a key encapsulation mechanism (KEM) designed to be resistant to cryptanalytic attacks with future powerful quantum computers. It is used to establish a shared secret between the client and the API server. An AES-256-GCM session key is derived form the generated shared secret. The session key is used for session encryption of API request Callbacks over TLS between the client and server APIs until the session times out or the page reloads. The session key is not persisted anywhere. The client uses the API Servers Public key during shared secret establishment which provieds an additional layer of server authentication. All API request content is encrypted from within the client all the way into the AWS Lambda implementing the server API where it is decrypted and processed. The return path is the same. This protects all API requests from MITM attacks including from state actors and cloud providers.
Replay Protection:
To provide definitive protection against Request and Response replays.
The StateObj contains an exp (expiration) timestamp and a region identifier.
The client generates a secure random Nonce (nanoid) and a current timestamp in seconds which are included in the encrypted Request callback sent to the server over TLS.
Upon receiving a request, the server performs a three-way check:
It decrypts the Request and StateObj and checks that the Request and StateObj have not expired. The Request timestamp shall not be older that 60 seconds. The session encryption prevents a MITM from generating a valid Request or Response.
It verifies the StateObj region is correct.
It uses a conditional write to a regional DynamoDB table (with TTL enabled) to ensure the Request Nonce has not been used before. The item's TTL in DynamoDB is set to the timestamp from the Request plus 60 second.
The server processes the Request and Responds.
The server includes the Request Nonce in the Reply.
The client decrypts the Response.
The client verifies the Response Nonce matches the Nonce sent in the Request

This process cryptographically binds each Response to its originating Request and ensures verifiable replay prevention in a stateless multiregion environment.

Client side API Service Layer: The client application uses a two-tiered service architecture. A high-level ApiService provides a clean API for components, while a low-level AuthzService manages the secure CallBackDTO protocol and cryptographic state.

Authentication and Access Flow Summary

Get SafeAccess Master Key and accessID:
WebAuthn: The AIDK is retrieved from the FIDO2 device and the client keyring is initalized with it. The server performs WebAuthn authentication.
Recovery / Backup Flow: For account recovery (e.g., Lockout Guard, Legacy Link), the user provides a Recovery Passphrase and an Access ID encoded as a "code", from which the AIDK is derived.
- The lockout guard Safe inactivity lockout detection timer must have triggered fist.
The client-side keyring is initialized with the AIDK.
The AIDKring unwraps the double wrapped Safe Database Key(SDK) received form the server.
The server unwraps the SDK using its SMKring and puts it in the encrypted StateObj.
The SDK is used by the server to decrypt Safe metadata for API requests.
The server performs final authorization (PIN checks, etc.) and returns the clients AIDKring wrapped Client Data Master Key(CDMK).
The AIDKring unwraps the CDMK.
The client's keyring is re-initialized with the CDMK.
The client can now request signed URLs from the server to access encrypted data in AWS S3, which it decrypts locally using the CDMK.

Data Encryption and Storage

Detailed Encryption Flow (Cloud File Upload)

The following is a step-by-step breakdown of the end-to-end encryption process for a cloud file upload. A similar process is used for encrypting files for local storage, which omits the signed URLs and multipart upload steps, but adds a download component.

Initiation (Client UI):
A user selects a file for upload. The FileService creates a ReadableStream from the file and an Archive object to store its metadata.
The stream is piped through a transformer that breaks the file into 10MB chunks.
Hand-off to Service Worker (Client UI -> Service Worker):
For each chunk, the FileService sends a message to the LocksafeStreams Service Worker via a secure BroadcastChannel.
The first chunk is sent with an INIT command and the Archive metadata. Subsequent chunks are sent with a PART command.
First Chunk Encryption (Service Worker):
The Service Worker receives the INIT message.
It performs the first layer of encryption on the chunk using the AWS Encryption SDK and the user's Client Data Master Key. This produces a standard AWS-encrypted message containing a header with a wrapped data key.
It then performs the second layer of encryption: a new, cryptographically secure random Key Encrypting Key (KEK) is generated per Archive file. This KEK is applied via an XOR operation to the wrapped data key in the header.
The KEK is temporarily stored in memory, associated with the transaction.
Multipart Upload Initiation (Service Worker -> API -> S3):
The Service Worker calculates the Content-MD5 hash of the double-encrypted first chunk.
It calls the UnoLock API to initiate a multipart upload. The API returns a unique uploadId and a pre-signed S3 URL for the first part.
The Service Worker PUTs the double-encrypted chunk to the pre-signed URL.
Subsequent Chunk Processing (Service Worker -> API -> S3):
For each subsequent PART message, the Service Worker repeats the process:
- It encrypts the chunk with the AWS SDK.
- It applies the same KEK from step 3 to the header's wrapped data keys.
- It calculates the MD5 hash, gets a new pre-signed URL for the next part from the API, and PUTs the chunk to S3.
Finalization (Client UI -> Service Worker -> API):
Once all chunks are processed, the FileService sends a COMPLETED message.
The Service Worker encrypts the Archive metadata object, which now includes the KEK, using the Client Data Master Key.
It calls the UnoLock API to complete the multipart upload, providing the uploadId, the list of all part ETags, and the encrypted metadata blob.
The API instructs S3 to assemble the parts into a single object and stores the encrypted metadata in its database.

KEK for Perfect Forward Secrecy for Stored Data and Authorization

*To ensure robust forward secrecy and enable fine-grained server-side control over encrypted files, a secondary encryption layer is applied to the AWS Encryption SDK message format. This is achieved with a Key Encrypting Key (KEK) in a process that functions as a symmetric stream cipher.

First, the client's AWS Encryption SDK keyring (the CDMKring) performs the standard operation of wrapping the file's unique data key (EDK) and embedding it in the message header.
Separately, the client generates a Key Encrypting Key (KEK). For this to be secure, the KEK is a cryptographically secure random byte array whose length is identical to the EDK it will encrypt.
This KEK is then used in a byte-wise XOR operation against the wrapped data key in the header. The header structure version is verified to garantee proper operation. This step super-encrypts the EDK, creating a two-factor key requirement. The encrypted file is now undecryptable without possessing both the KEK and the original CDMKring used for the initial wrapping.
The XOR operation is symmetric; applying the same KEK a second time reverses the encryption, revealing the original wrapped EDK from step 1.
The KEK is never stored in plaintext. To secure it, it is encrypted by the CDMKring and stored separately from the file as server-side metadata. This ensures the KEK is protected by the same master key but remains a distinct entity.
This design gives the server cryptographic control over file access. By managing access to the encrypted KEK, the server enforces authorization. More critically, if the server deletes the encrypted KEK, the secondary encryption on the file's header becomes irreversible. This achieves cryptographic erasure, rendering the file permanently undecryptable and providing forward secrecy even if an attacker later compromises the user's CDMK.

Decryption Process: To decrypt a file, the KEK must be securely retrieved and decrypted: - The client authenticates using WebAuthn, provides the correct UnoLock PIN, and is authorized to access the file. - The encrypted KEK is retrieved from the archive metadata and decrypted using the CDMKring. - This KEK is then XORed against the same positions in the message header to revert the wrapped data keys to their original form. - Once restored, the AWS Encryption SDK proceeds with normal decryption using the unwrapped data key.

Security Properties: - Revocability: Removing the KEK or metadata destroys decryptability. - Resilience: The XOR operation is stateless and symmetric. The file is never decryptable unless both the CDMK and KEK are present. - Immutability: The encryption process does not alter the ciphertext body—only the headers.

This design allows UnoLock to support secure remote delete, tamper-resistant metadata control, and plausible deniability through the permanent cryptographic unlinking of keys and content.

Data Storage Options: Cloud and Local

UnoLock provides two primary options for storing user-encrypted files ("archives"):

Cloud Storage (Default): Encrypted files are streamed to regionally replicated AWS S3 buckets. This provides high availability, data durability, and enables access from any of the user's authorized devices.
Local Storage: Users can opt to encrypt files that are then saved directly to their local device (e.g., for storage on a USB drive or personal NAS). This option provides complete physical control over the encrypted data.

Use as an External Key Manager

The local storage feature allows UnoLock to function as a powerful and secure key management system for a user's entire ecosystem of encrypted files. A user can encrypt a file with UnoLock, store the resulting encrypted file anywhere they choose, and use an UnoLock "Note" to securely store the context, description, or even the physical location of that file.

This solves a critical problem in traditional file encryption: the management of keys and metadata. The decryption of any UnoLock-encrypted file—whether stored in the cloud or locally—is always tied to the metadata "archive" stored on the UnoLock server. This metadata contains the file's unique Key Encrypting Key (KEK).

If a locally stored file is ever lost or stolen, the user can perform a secure remote delete by simply deleting the corresponding archive entry within the UnoLock application. This action permanently deletes the KEK from the server, rendering the stolen copy of the file cryptographically unreadable and secure forever.

Advanced Features

Granular Access Control with "Spaces"

A single Safe can be partitioned into multiple independent Spaces, each acting as a distinct, encrypted container for files, notes, and crypto wallets. This allows for powerful data segregation and granular access control.

Per-Key Permissions: Access to each Space is controlled on a per-key (i.e., per-device) basis. A Safe administrator can grant a specific device Read-Only or Read-Write access to one or more Spaces, while all other Spaces remain invisible and inaccessible to that device.
Geographic Data Residency: Each Space can be assigned to a specific geographic storage region (e.g., EU, US) to comply with data residency laws, or it can be configured for multi-region replication for enhanced durability.

Plausible Deniability and Duress Features

UnoLock provides a dual-PIN system to protect users under duress. A user can configure a secondary Safeword PIN which, when entered, triggers a different outcome than the primary PIN.

Duress Decoy (LockSafe Tier): Entering the Safeword PIN reveals a pre-configured "decoy" Space containing non-sensitive data, keeping the user's primary data hidden and secure.
Secure Wipe (LifeSafe Tier): For maximum protection, entering the Safeword PIN can be configured to trigger the irreversible cryptographic destruction of the primary data by securely deleting the relevant KEKs from the server.

Integrated Crypto Wallet

UnoLock includes a non-custodial cryptocurrency wallet feature that allows users to create and manage wallets for Bitcoin and Ethereum.

Secure Mnemonic Handling: When a new wallet is created, a 24-word BIP39 mnemonic phrase is generated on the client. Before being stored, this phrase is split into two 12-word halves. Each half is then individually encrypted using a special authentication-bound encryption method (authnEncryptData). This method links the encryption to a fresh FIDO2/WebAuthn authentication ceremony, meaning that decrypting the mnemonic halves requires the user to re-authenticate with their device. This provides an extra layer of security for the wallet's master key. Decryption of the mnemonic is restricted to AccessIDs granted the 'Admin" role. ReadOnly AccessIDs can not access the mnemonic.
Standard-Based Key Derivation: Wallets are generated using industry-standard BIP39 mnemonic phrases. The application correctly implements various hierarchical deterministic (HD) derivation paths, such as BIP84 for Bitcoin SegWit addresses, BIP44 for legacy addresses (e.g., Dogecoin), and CIP-1852 for Cardano, ensuring compatibility with other standard wallets.
Client-Side Key Management: All wallet operations that require private keys are performed on the client-side. The mnemonic phrase is only ever reconstructed in memory within the user's browser session after they have been fully authenticated.
Secure Balance Inquiry: To check wallet balances, the client sends the public wallet address to the server via the secure, end-to-end encrypted Callback mechanism. The server then queries the respective blockchain and returns the balance.

EyesOnly End-to-End Encrypted Messaging

UnoLock includes a secure messaging feature called "EyesOnly" that provides post-quantum, end-to-end encrypted communication between users. The entire cryptographic process happens on the client, ensuring that the server cannot read message content.

The system uses a hybrid encryption scheme that combines the strengths of both asymmetric and symmetric cryptography:

Key Encapsulation (KEM): To send a message, the sender uses the recipient's public key and the ML-KEM-1024 (Kyber) @noble/post-quantum, algorithm to generate a shared secret and a ciphertext (the "encapsulation"). This process is quantum-resistant.
Key Derivation (HKDF): The shared secret from the KEM is used as input to an HKDF (HMAC-based Key Derivation Function) with SHA-256 to derive a strong, symmetric AES-256-GCM key.
Bulk Encryption: This derived AES key is then used to encrypt the message header and any file attachments.
Digital Signature: The message header is digitally signed using the sender's private ML-DSA-65 (Dilithium) key to provide authenticity and integrity, preventing tampering.

The final sealed message, which is sent to the server, contains the KEM ciphertext, the encrypted header, and the encrypted attachments. Only the intended recipient, using their private ML-KEM key, can reverse the process to derive the same AES key and decrypt the message.

Unolock PIN System

The UnoLock PIN system ensures the PIN code never exists in plaintext on the client. Instead of typing, the user clicks on a server‑generated keypad image delivered the secure API channel.

Randomized 4×4 Grid: On each PIN attempt, the server renders a randomized 4×4 grid of hex characters (0–9, A–F).
Positions Shuffle: The character positions shuffle every attempt.
Click Coordinates Only: The client sends only the (X,Y) click coordinates back to the server—never the actual digits.

Because the mapping from coordinates to characters is known only server‑side and each keypad is unique, hardware or software keyloggers cannot recover your PIN.

Client Environment Security

In-Browser Security

Running in the context of a web browser, UnoLock leverages an additional security layer for data protection. Web browsers operate in a sandboxed environment, significantly limiting web applications from accessing the file system or performing potentially harmful operations, thereby reducing the impact of any security breaches. This isolation, combined with the regular security updates provided by modern browsers, enhances the overall security posture.

Furthermore, UnoLock employs strict Content Security Policies (CSPs), which restrict network connections to only trusted domains, thereby mitigating the risk of data exfiltration. The use of HTTPS for data transmission ensures that all data exchanges are encrypted, providing an added layer of security during data transfer.

In-Memory Data Handling and Secure Streaming

Encrypted files can be viewed directly within the client application without being decrypted and written to local storage. This is achieved through a high-performance streaming architecture powered by the custom Service Worker.

When a user views a file, the application fetches the encrypted data from cloud storage in chunks. These chunks are streamed directly to the Service Worker, which decrypts them on-the-fly and passes the decrypted data back to the browser for immediate rendering. This process happens entirely in memory and supports HTTP range requests, allowing for efficient seeking through very large files, such as videos up to 100 GB (10,000 chunks of 10MB).

This approach ensures that the full decrypted file never persists on the client's device, significantly reducing the risk of unauthorized access. The application supports in-browser viewing for a wide range of file types, including:

Video: video/*
Audio: audio/*
Images: image/*
Documents: pdf, docx
Text & Code: text/*, json, xml, html, yaml

Runtime Environment Hardening

UnoLock employs an active Security Monitor Service that runs from the moment the application starts. This service hardens the browser environment and actively monitors for common client-side attacks. This provides a defense-in-depth strategy against threats that could compromise the application's integrity, such as malicious browser extensions or DOM-based attacks.

Key monitoring and hardening features include:

API Hardening: Critical browser APIs like localStorage, sessionStorage, indexedDB, and WebSocket are immediately replaced with inert, locked-down versions. This prevents unauthorized scripts from exfiltrating data or opening malicious connections. The service then continuously monitors these APIs to detect and revert any attempts at tampering.
DOM Monitoring: A MutationObserver actively watches the entire document for unauthorized changes. It inspects any new \<script> or \<iframe> elements to ensure they comply with the application's strict Content Security Policy (CSP) and removes any that are not on the allowlist.
Malicious Extension Probing: The service proactively probes for the presence of known malicious or high-risk browser extensions by checking for their unique resource URLs. If a banned extension is detected, the user is immediately alerted.
Clickjacking and Overlay Detection: The monitor periodically scans the DOM for invisible, full-screen elements that are characteristic of clickjacking attacks, flagging any suspicious overlays.
Event Listener Auditing: The global addEventListener function is overridden to audit the creation of new listeners. This helps detect suspicious activity, such as an extension adding an excessive number of keydown or input listeners in an attempt to log user input.

Infrastructure and Operational Security

Serverless Architecture

The entire backend infrastructure is serverless, built on services like AWS Lambda and API Gateway. This design eliminates traditional servers and network management, which significantly reduces the attack surface area and mitigates entire classes of vulnerabilities, including many forms of DDoS attacks.

Secure Build and Deployment Pipeline

UnoLock employs a stateless, multi-account build system automated with AWS CodePipeline and AWS CodeBuild.

Isolation: A multi-account strategy is used to segregate build, test, and production environments, minimizing the blast radius in case of a security incident.
Dependency Vetting: All build dependencies are managed through AWS CodeArtifact, a private, curated repository. This ensures that only approved and secure libraries are used, protecting against supply-chain attacks.
Change Control: All changes to the codebase require review and approval from multiple personnel before being merged into production, ensuring code quality and integrity.

TechSologic Administrative Access Security

All administrative access to the AWS infrastructure is managed through AWS IAM Identity Center.

Phishing‑Resistant MFA
Every console or API session requires a FIDO2/WebAuthn hardware key (e.g., YubiKey) to authenticate.
No Long‑Term Credentials
Human users never have IAM passwords or permanent access keys. All sessions are issued as temporary credentials via SSO after a successful MFA challenge.
Least‑Privilege Access
Roles and permissions follow the principle of least privilege. Each admin only has exactly the rights they need—no more.
Just‑In‑Time Team
A minimal, dedicated operations team (2–3 people) maintains Unolock. Fewer admins reduce insider‑risk and simplify access reviews.
Serverless Infrastructure
With no persistent servers or networks to manage, the attack surface is dramatically reduced—there’s nothing to “compromise” in the traditional sense.
Continuous Monitoring & Logging
All IAM actions are logged in CloudTrail, forwarded to a centralized SIEM, and retained for 90 days. Alerts trigger on anomalous API calls (e.g., root‑account usage, console‑login outside business hours).

Additional Notes

Device Trust: Users should only use devices they would trust for online banking.
Threat Model: An attacker would need to compromise the device OS, the FIDO/WebAuthn authenticator, and the user's Safe PIN to gain access.
Anonymity and Privacy: UnoLock is designed to be an anonymous service. We do not collect any personally identifiable information. Payments via Stripe or Bitcoin are processed in a way that they cannot be linked back to a specific user's Safe. Server logs are minimal, used only for debugging, and are purged every three days.
Data Storage: No user data is stored in the web browser aside from the cached client application and the server’s public key.

Safe Authentication Sequence

Mermaid sequenceDiagram autonumber participant FIDO2 as "FIDO2 Device" participant Client participant Lambda participant DB as "DynamoDB" participant PS as "SSM" participant KMS as "AWS KMS"

%% Lambda cold‑start – unseal server master key‑ring
Lambda->>PS: fetch wrapped Server Master Key
PS-->>Lambda: ciphertext
Lambda->>KMS: decrypt ciphertext
KMS-->>Lambda: Server Master Key (SMK)
Lambda->>Lambda: initialize server keyring

Note over Client,Lambda: Quantum safe API key negotiation
Lambda->>Lambda: create stateObj

Note over Client,Lambda: Subsequent API calls carry SMK‑ring encrypted StateObj
Note over Client,Lambda: Create New Safe

%% Safe creation (first‑time)
Lambda->>Client: initiate WebAuthn Registration
Client->>Client: generate AccessID key (AIDK)
Client->>FIDO2: WebAuthn register → AIDK
FIDO2-->>Client: AccessID Key
Client->>Client: init key‑ring(AIDK)
Lambda->>Lambda: generate Safe DynamoDB Key (SDK)
Lambda->>Lambda: wrap SDK with SMK‑ring → Enc‑SDK
Lambda->>Lambda: store Enc‑SDK in StateObj

Lambda-->>Client: Enc‑SDK + StateObj
Client->>Client: wrap Enc‑SDK with AIDK‑ring → DEnc‑SDK
Client->>Lambda: store DEnc‑SDK
Lambda->>Lambda: decrypt/verify StateObj
Lambda->>Lambda: encrypt DynamoDB data with SDK
Lambda->>DB: put { DEnc‑SDK } (encrypted)

Client->>Client: generate CDMK
Client->>Client: wrap CDMK with AIDK‑ring → W‑CDMK
Client->>Lambda: upload W‑CDMK
Lambda->>Lambda: decrypt/verify StateObj
Lambda->>Lambda: encrypt DynamoDB data with SDK
Lambda->>DB: put { W‑CDMK } (encrypted)
Client->>Client: re‑init key‑ring(CDMK)

%% Authentication / session bootstrap
Note over Client,Lambda: Login (subsequent)
Note over Client,Lambda: Quantum safe API key negotiation
Lambda->>Lambda: create stateObj

Note over Client,Lambda: Subsequent API calls carry SMK‑ring encrypted StateObj
Lambda->>Client: initiate WebAuthn Authentication
Client->>FIDO2: WebAuthn assertion
FIDO2-->>Client: AIDK
Client->>Client: init key‑ring(AIDK)
Client-->>Lambda: auth request + assertion
Lambda->>Lambda: validate WebAuthn
Lambda->>DB: fetch DEnc‑SDK
DB-->>Lambda: DEnc‑SDK
Lambda-->>Client: DEnc‑SDK
Client->>Client: unwrap DEnc‑SDK → Enc‑SDK
Client-->>Lambda: Enc‑SDK
Lambda->>Lambda: decrypt Enc‑SDK → SDK
Lambda->>Lambda: store SDK in StateObj

Lambda-->>Client: StateObj
Client->>Lambda: request W‑CDMK
Lambda->>Lambda: decrypt/verify StateObj
Lambda->>DB: get W‑CDMK
DB-->>Lambda: W‑CDMK
Lambda->>Lambda: decrypt W‑CDMK with SDK from StateObj
Lambda-->>Client: W‑CDMK
Client->>Client: unwrap W‑CDMK with AIDK‑ring → CDMK
Client->>Client: re‑init key‑ring(CDMK)

Note over Client: Client can now perform cryptographic functions on data