Security Architecture

Zero-Knowledge Architecture

Zero-knowledge means that CloudKeep servers store only encrypted ciphertext. Even in the event of a complete server compromise, an attacker gains nothing usable because:

• Your master password is never transmitted to the server. It is used exclusively in the browser to derive your encryption keys.
• Your private key is stored on the server in encrypted form. It can only be decrypted by your master password or recovery key, neither of which the server possesses.
• Secret values are encrypted before they leave your device and decrypted after they arrive on your device.

Encryption Details

CloudKeep uses industry-standard cryptographic primitives with no custom or novel algorithms:

• AES-256-GCM — symmetric encryption for secret values. AES-256-GCM provides both confidentiality and authenticity, detecting any tampering with the ciphertext.
• NaCl box (X25519 + XSalsa20-Poly1305) — asymmetric encryption used for sharing secrets between users. Each user has a Curve25519 key pair; shared secrets are encrypted with the recipient’s public key.
• PBKDF2-SHA512 — key derivation from your master password with 600,000 iterations. This makes brute-force attacks computationally expensive even with dedicated hardware.

Key Hierarchy

Understanding how keys relate to each other is essential to understanding the security model:

1. Master password — known only to you. Never stored anywhere.
2. Master key — derived from your master password using PBKDF2-SHA512 with a unique salt. This key exists only in browser memory during your session.
3. Private key (encrypted) — stored on the server encrypted with your master key. Decrypted in the browser when you enter your master password.
4. Public key — stored unencrypted on the server. Used by other users to encrypt secrets they share with you.
5. Per-secret encryption key — each secret is encrypted with a unique AES-256-GCM key. This key is itself encrypted with your private key and stored alongside the ciphertext.

Master Password
  └─ PBKDF2-SHA512 (600k iterations) ──▸ Master Key
       └─ Decrypts ──▸ Private Key (stored encrypted on server)
            └─ Decrypts ──▸ Per-Secret Keys
                 └─ AES-256-GCM ──▸ Decrypted Secret Value

Recovery Key (24-word mnemonic)
  └─ Alternative path to decrypt ──▸ Private Key

Data at Rest

All data stored on CloudKeep servers is encrypted at multiple layers:

• Application-level encryption — secret values are encrypted with AES-256-GCM before being sent to the server, as described above.
• Database-level encryption — the PostgreSQL database uses Transparent Data Encryption (TDE) for full-disk encryption of all stored data.
• Volume encryption — server disks use AES-256 full-disk encryption managed by the cloud provider.

Data in Transit

All communication between your browser/CLI and CloudKeep servers is protected by:

• TLS 1.3 — all HTTP connections require TLS. Older TLS versions (1.0, 1.1) are disabled. HTTP requests are automatically redirected to HTTPS.
• HSTS — HTTP Strict Transport Security headers are sent with a one-year max-age to prevent downgrade attacks.
• Certificate pinning — the CLI pins CloudKeep's TLS certificate to prevent man-in-the-middle attacks.

Session Security

• Sessions expire after 24 hours of inactivity or 7 days from creation, whichever comes first.
• The master key is held in browser memory only. It is never written to localStorage, sessionStorage, or cookies.
• Closing the browser tab clears the master key from memory. You must re-enter your master password to access secrets again.
• Two-factor authentication (TOTP) can be enabled for an additional layer of login security. See the Two-Factor Auth docs.

Audit Logging

CloudKeep maintains a detailed audit log of all security-relevant actions:

• Login attempts (successful and failed)
• Master password changes
• Recovery key regeneration
• API token creation and revocation
• Secret access, creation, modification, and deletion
• Vault membership changes
• Webhook configuration changes
• Export and import operations

Audit logs are available from Settings → Audit Log. Logs are retained for 90 days on the Pro plan and 1 year on the Enterprise plan. They are immutable and cannot be deleted by users.

Infrastructure Security

• Hosting — CloudKeep runs on isolated infrastructure with no shared tenancy. Application servers and databases are in private subnets with no direct internet access.
• Network segmentation — strict firewall rules limit traffic between components. Only the API gateway is exposed to the public internet.
• Automated patching — operating systems and dependencies are automatically updated within 24 hours of security patches being released.
• Intrusion detection — real-time monitoring and alerting on anomalous access patterns, failed authentication spikes, and configuration changes.
• Regular penetration testing — independent security firms conduct penetration tests quarterly. Findings are remediated within the severity-based SLA.
• Backups — encrypted database backups are taken every 6 hours and retained for 30 days. Backups are stored in a separate geographic region.

Responsible Disclosure

We take security vulnerabilities seriously and appreciate responsible disclosure from the security community. If you discover a vulnerability:

1. Email security@cloudkeep.io with a detailed description of the vulnerability, steps to reproduce, and any proof of concept.
2. Do not publicly disclose the vulnerability until we have confirmed and patched it.
3. We aim to acknowledge reports within 24 hours and provide a resolution timeline within 72 hours.
4. We offer a bug bounty for qualifying vulnerabilities. Critical issues affecting encryption or authentication are eligible for rewards up to $5,000.

We will never take legal action against researchers who follow responsible disclosure practices and act in good faith.

Next Steps

• Account Recovery — understand how recovery keys integrate with the key hierarchy.
• REST API — learn how authentication tokens work with the API.