Zero-Knowledge Architecture

Security Whitepaper

A technical analysis of 1TimeLink's end-to-end encryption engine, zero-knowledge storage keys, and threat modeling protocols.

1. Executive Summary

1TimeLink is designed on a Zero-Knowledge Architecture. This means the database storing the links and the object storage retaining file binaries have zero technical capability to read or inspect the secrets exchanged.

Security is enforced by performing all cryptographic key generation, payload encryption, and payload decryption directly inside the user's browser (client-side) using the native Web Crypto API. The host server acts strictly as an ephemeral storage relay for ciphertext.

Trust Assumptions: While the storage backend is fully zero-knowledge, the client-side guarantees depend on the integrity of the frontend code served to the browser. The frontend is hosted as static pre-built assets on Cloudflare Pages, leveraging its SOC 2 Type II certified global CDN infrastructure. For organizations requiring full end-to-end supply-chain control, 1TimeLink provides a self-hosted option to bypass any reliance on external CDNs.

2. Client-Side Cryptographic Engine

Encryption and decryption processes occur entirely within the browser context using standard, cryptographically secure native Web APIs.

Algorithm Standards:

• Symmetric Cipher: AES-GCM (Advanced Encryption Standard in Galois/Counter Mode - AEAD)

• Key Length: 256 bits (derived client-side)

• Key Source: Web Crypto API's crypto.subtle.generateKey

• Initialization Vector (IV): 12-byte cryptographically secure random values (CS-PRNG) generated per-operation

For each shared link:

A unique 256-bit symmetric AES-GCM key is generated.
A unique 12-byte random IV is generated.
The text payload and file name are encoded into raw bytes and encrypted using AES-GCM.
The 12-byte IV is prepended to the ciphertext and base64Url-encoded.
If a file is uploaded, the binary stream is similarly encrypted in memory using AES-GCM.

3. Zero-Knowledge Key Transport via URL Hashes

To exchange the secret, the creator receives a unique URL structured as follows:

https://1timelink.com/v/<linkId>#<decryptionKeyBase64>

The decryption key is placed strictly in the URL Hash Fragment (the portion following the # character).

According to internet engineering standards (RFC 3986, Section 3.5), the hash fragment is processed exclusively by the browser user agent. It is never sent to the host server in HTTP request headers or query strings. Thus:

GET requests to /v/<linkId> only transmit the public ID.
Logs in reverse proxies, load balancers, and Spring web controllers contain no record of the decryption key.
If the database is leaked, the database records only contain the encrypted ciphertext and metadata, which are useless without the hash key.

4. Direct S3 Storage & Pre-signed URL Routing

To handle file uploads without exposing raw binaries to server memory or overloading application processes, 1TimeLink implements a direct-to-storage architecture:

Presigned Upload URLs: The backend generates an AWS S3/R2 presigned upload URL restricting the payload to a specific key, content type, and content length. These presigned URLs expire after 15 minutes and uploads are mapped to standard MIME types or application/octet-stream for safe isolation. The client uploads the encrypted file bytes directly to S3 via HTTP PUT.
Presigned Download URLs: When authorized, the backend generates a short-lived download URL (expiring after 15 minutes) allowing the browser to fetch the encrypted binary directly from S3.
Binaries Isolation: The host application never buffers, parses, or retains the file bytes in temporary local storage disks.

5. Data Erasure & Lifecycle Purging

1TimeLink enforces strict transient storage guidelines. The system is designed to ensure that secrets are deleted as soon as they are consumed or expire:

Purged Database Records: When a link is burned, expired, or opened, the database update query immediately nullifies the file metadata column and sets the content column to a static placeholder string ('deleted').
Asynchronous S3 Object Deletion: Upon consumption, the backend publishes a transactional file deletion event. An event listener executes the delete command on S3 asynchronously with built-in retry mechanics, decoupling deletion latency from HTTP request completion.
Automated Expiration Cleanup: A background cleanup service runs every 15 minutes to proactively scan the database for active links that have reached their expiration times. It updates their status to EXPIRED, overwriting the database text payload and triggering file deletions from storage.

6. High-Level Flow Diagram

The following sequence diagram visualizes the cryptographic boundaries and data lifecycle:

sequenceDiagram
    autonumber

    box lightgreen Trusted Zone (Client-Side)
        participant S as Sender (Browser)
        participant R as Recipient (Browser)
    end

    box khaki Edge Network
        participant Edge as Edge Compute Proxy
    end

    box lightcoral Zero-Knowledge Zone (Backend)
        participant API as Core API Server
        participant DB as Metadata Database
        participant S3 as Object Storage
    end

    box lightgrey External
        participant Hook as External Webhook
    end

    %% Link Creation
    Note over S: Generates AES-GCM key and encrypts payload
    S->>API: 1. POST Encrypted Metadata
    API->>DB: 2. Store Encrypted Metadata
    API-->>S: 3. Return Pre-Signed Upload URL and HMAC Signature
    S->>S3: 4. Upload Encrypted Binary (Direct PUT)

    %% Sharing
    S->>Edge: 5. Relay Notification Request + HMAC
    Edge->>Hook: 6. Verify HMAC and Forward Webhook
    S->>R: 7. Share Link (Key in URL Hash)

    %% Link Consumption
    R->>API: 8. GET Link Metadata
    API-->>R: 9. Return Ciphertext and Pre-Signed Download URL
    R->>S3: 10. Download Encrypted Binary (Direct GET)
    Note over R: Extract key from URL hash and decrypt payload

    %% Purge
    R->>API: 11. PATCH status=OPENED
    API->>DB: 12. Purge Metadata and Ciphertext
    API-->>S3: 13. Delete Encrypted Object (Async)

    %% Legend
    Note over  S,Hook: TRUST ZONES<br/>Green = Trusted browser where plaintext and encryption keys exist.<br/>Yellow = Edge proxy handling outbound third-party API calls.<br/>Red = Zero-Knowledge backend storing encrypted data only.<br/>Gray = External third-party services.

7. STRIDE Threat Modeling & Mitigation Analysis

1TimeLink's security design provides robust mitigations against attack vectors modeled using the STRIDE framework:

Spoofing Identity

Threat: Malicious Frontend Injection (Supply Chain Attack) or Compromised Client Devices.
Mitigation: Static frontend code is hosted on Cloudflare Pages using strict Content Security Policy (CSP) headers to block unauthorized scripts. Organizations requiring absolute supply chain control can self-host the client. Devices infected with malware or malicious extensions are out-of-scope for 1TimeLink's threat model.

Tampering with Data

Threat: Database Compromise, Unauthorized Injection, or Man-in-the-Middle (MitM).
Mitigation: HTTPS/TLS 1.3 is strictly enforced. Active database records only contain AES-GCM authenticated ciphertext. The decryption key is never stored in the database, meaning compromised database dumps or intercepted traffic yield zero plaintext, and payloads cannot be mathematically tampered with.

Repudiation

Threat: Sender denies creating or sharing a sensitive link.
Mitigation: As a Zero-Knowledge system designed for anonymous, ephemeral sharing, strict non-repudiation is intentionally sacrificed to preserve user privacy. 1TimeLink does not log IP addresses or personal identifiers with payloads. However, enterprise link creation can be gated by authenticated Slack session tokens.

Information Disclosure

Threat: Host Server Intrusion or Inactive Data Retention Leakage.
Mitigation: Decryption keys exist only inside the client-side browsers of the sender and recipient via URL hashes; an intruder controlling the web server environment cannot decrypt active secrets. Purge-on-burn database queries and S3 async lifecycle deletion guarantee that consumed or expired records are physically wiped from storage.

Denial of Service (DoS)

Threat: Brute-Force Link Enumeration or Bandwidth Exhaustion.
Mitigation: Rate limiting is enforced at the Cloudflare edge and reverse proxy layers to block rapid query probing. Direct-to-S3 uploads via presigned URLs offload heavy file transfer overhead entirely from the core API server, preventing bandwidth exhaustion attacks on the application layer.

Elevation of Privilege

Threat: Server-Side Request Forgery (SSRF) to probe internal VPC networks.
Mitigation: External webhooks (e.g., Slack messaging) are dispatched exclusively by isolated Cloudflare Edge Functions, mathematically protected by HMAC-SHA256 signatures generated by the backend. The core backend server processes no external URLs, preventing attackers from elevating privileges to access internal infrastructure.