Security Practices

1. Architecture Overview

EternaKeys uses a zero-knowledge architecture: vault content is encrypted on your device before transmission. The server stores only ciphertext and operational metadata necessary for the service to function.

2. Encryption Standards

Vault content is encrypted with AES-256-GCM using keys derived from your passphrase via Argon2id. Your passphrase never leaves your device.

• Algorithm: AES-256-GCM with random 96-bit nonces
• Key Derivation: Argon2id with per-user random salt (16+ bytes)
• Key Hierarchy: Passphrase → Argon2id KDF output → domain-separated encryption, search, and integrity keys
• Integrity: AES-GCM provides authenticated encryption; the Additional Data (AAD) binds each item’s ciphertext to its salt, schema version, content type, item type, and a per-item identifier

3. Metadata Disclosure

Operational metadata — including item types, sizes, timestamps, and account information — is stored to enable service functionality. Vault content itself remains encrypted.

Specifically, the following operational metadata is stored in plaintext to enable service functionality:

• Item types and categories
• Item sizes (bytes)
• Creation and modification timestamps
• Account information (email, subscription status)
• Designated recipient records (name, email, relationship)
• Audit log entries (event types, IP addresses, user agents)

4. Authentication Security

• Passkey-first authentication: Standard user accounts authenticate exclusively via FIDO2/WebAuthn passkeys (hardware keys or platform authenticators). No password is stored for standard accounts.
• Administrative accounts: Admin accounts use password-based login (Argon2id hashed) with mandatory TOTP second factor and one-time recovery codes.
• Sessions: JWT HS256 access tokens (15-minute TTL) + HttpOnly refresh cookies (7-day TTL, SameSite=Strict)
• Rate limiting: Per-IP rate limits on all authentication endpoints

5. Application Security

• Content Security Policy: Strict CSP with per-request nonces; no unsafe-inline for scripts
• Cross-site request forgery: SameSite cookie policy, an Origin check on the cookie-authenticated refresh and sign-out endpoints, and bearer Authorization headers on other API requests
• Input Validation: Request inputs are validated server-side; many structured request bodies use Zod schemas
• Authorization: Every resource access verified by server-side ownership checks (userId, vaultId)
• Upload Pipeline: Client encrypts → uploads ciphertext → server stores opaque blob

6. Honest Limitations

No security system can guarantee absolute protection. EternaKeys is designed to minimize risk through client-side encryption, but device compromise, credential loss, or implementation limitations remain relevant factors.

• Client-device compromise (malware, malicious extensions) could expose decrypted content or key material while the vault is unlocked.
• We cannot recover encrypted vault data if you lose your vault passphrase. This is a deliberate design choice, not a limitation. Account access depends on your registered passkeys — if all passkeys are lost and no backup exists, account login cannot be restored.
• Operational metadata (listed above) is accessible to EternaKeys operators and could be exposed in a server breach.
• Browser-based cryptography inherits the trust model of the browser and its extensions.
• Your vault passphrase is typed into a page whose code EternaKeys serves to your browser. The vault is encrypted on your device, but the code that does it comes from us, so a compromised or malicious deployment could serve code that captures your passphrase. Content-security controls limit injection by third parties; they cannot constrain the operator or its deployment pipeline, and a way for you to check the code you are served is not yet available.
• A release package is sealed to the designated recipient's published access key, but it has no owner signature. The package alone does not prove who authored its contents; a compromised operator with database write access could substitute a package. The recipient's key is also fetched from our server when the owner confirms it (trust on fetch): the owner's one-tap confirmation guards against binding the wrong person, not against a compromised server substituting a key.

7. Authorized Access Trigger Security

The AAT (Authorized Access Trigger) workflow for authorized access includes multiple security layers:

1. Requestor email verification before processing
2. Vault-owner notification when a request is made, again at approval with the exact date each part opens (sent before any release code), and 24 hours before each part opens
3. Staged release after approval: Directives at 72 hours, Financial Assets at 7 days, Digital Life at 10 days, Physical Assets at 14 days. The owner can stop every part not yet opened, and each opening is checked by the database clock after every other check has passed
4. Explicit administrative decision; the current product does not upload or validate legal documents
5. Cryptographically random, single-use, time-limited verified release code
6. Full audit trail of all AAT actions

8. Incident Response

In the event of a security incident affecting user data, EternaKeys will:

• Investigate and contain the incident within 24 hours of detection
• Notify affected users within 72 hours as required by GDPR
• Publish a post-incident report with root cause analysis
• Implement corrective measures and update the risk register

9. Contact

To report a security vulnerability, please email security@eternakeys.com. We take all reports seriously and will respond within 48 hours.