Security Whitepaper

3.1 Client-Side Encryption with AES-256-GCM

Keeplas encrypts every vault item using AES-256-GCM (Galois/Counter Mode), an authenticated encryption algorithm that provides both confidentiality and integrity. Each item is encrypted with a unique, randomly generated 256-bit key and a 96-bit initialization vector (IV).

Algorithm:  AES-256-GCM
Key Size:   256 bits (32 bytes)
IV Size:    96 bits (12 bytes), randomly generated per encryption
Tag Size:   128 bits (16 bytes)
Output:     IV || Ciphertext || Authentication Tag

The authentication tag ensures that any tampering with the ciphertext is detected during decryption. The IV is prepended to the ciphertext so it is available for decryption without additional storage. Where keys must be shared -- per-recipient data encryption keys (DEKs) and Shamir recovery shards -- the wrapping layer combines AES-256-GCM with ML-KEM-768 (NIST FIPS 203), a post-quantum key-encapsulation mechanism, so harvested ciphertext stays protected even against future quantum adversaries.

3.2 Key Derivation: Argon2id

The user's 24-word recovery phrase is transformed into a Root Key using Argon2id, a memory-hard key derivation function. The Root Key then wraps the AES-256 master key that encrypts the vault; the user never types the master key directly.

Primary KDF:  Argon2id (recommended)
  Memory:     64 MiB
  Iterations: 3
  Parallelism: 4
  Output:     256-bit master key

Fallback KDF: PBKDF2-HMAC-SHA256
  Iterations: 600,000
  Salt:       128-bit, randomly generated per account
  Output:     256-bit master key

Argon2id is used because its memory-hard design resists GPU and ASIC-based brute-force attacks. The salt is unique per user and stored alongside the encrypted vault (it is not secret). The recovery phrase itself is generated on-device during onboarding and is never transmitted to Keeplas.

3.3 No Plaintext Leaves the Client

The recovery phrase and the keys derived from it are never transmitted to Keeplas servers. Authentication is fully passwordless -- email one-time codes (always required as a step-up) and optional WhatsApp OTP, passkeys (WebAuthn), or TOTP authenticator apps -- and is cryptographically independent from vault decryption. The server verifies identity without ever learning the secret used to decrypt the vault.

4.1 Key Hierarchy

When a user creates their account, the following key hierarchy is established on the client. The 24-word recovery phrase derives a Root Key via Argon2id, the Root Key wraps the AES-256 master key, and the master key protects individual vault item keys.

Master Password
  |
  +--[Argon2id / PBKDF2]--> Master Key (256-bit)
  |                            |
  |                            +--[HKDF-Expand "enc"]--> Encryption Key
  |                            +--[HKDF-Expand "auth"]--> Authentication Key
  |
  (never transmitted)

The master key is used to wrap (encrypt) individual vault item keys. Login identity is verified separately through passwordless authentication (email and WhatsApp one-time codes, passkeys, or TOTP), which is cryptographically independent from the keys that decrypt the vault.

4.2 Key Wrapping for Vault Items

Each vault item (document, credential, note) has its own randomly generated 256-bit item key. This item key is used to encrypt the item's contents via AES-256-GCM. The item key itself is then wrapped (encrypted) using the user's master key. When an item is shared with a recipient, its data encryption key is re-wrapped for that recipient using ML-KEM-768 combined with AES-256-GCM, keeping the share post-quantum secure.

Vault Item:
  item_key = random(256 bits)
  encrypted_content = AES-256-GCM(item_key, plaintext)
  wrapped_item_key  = AES-256-GCM(encryption_key, item_key)

Stored on server: wrapped_item_key + encrypted_content

This two-tier approach allows individual items to be re-encrypted without re-deriving the master key, and enables selective sharing and key rotation at the item level.

4.3 Key Rotation Strategy

When a user rotates their keys, a new master key is generated and all wrapped item keys are re-encrypted with it; the new master key is then re-wrapped under the Root Key derived from the recovery phrase. The underlying item keys and encrypted content remain unchanged, making rotation efficient even for vaults with thousands of items. Keeplas recommends key rotation at least once per year or immediately after a suspected compromise.

5.1 Shamir Secret Sharing (SSS)

To prevent permanent lockout if a user loses their 24-word recovery phrase, Keeplas implements a Social Recovery Protocol based on Shamir's Secret Sharing scheme. The master key is split into 5 shards such that any t shards (the threshold) are sufficient to reconstruct it, but fewer than t shards reveal nothing. Each shard is wrapped for its holder using ML-KEM-768 combined with AES-256-GCM, so the distributed shares remain post-quantum secure.

Shamir Secret Sharing Parameters:
  Secret:     Recovery Key (used to decrypt a backup of the Encryption Key)
  Shares (n): Configurable (default: 5)
  Threshold (t): Configurable (default: 3)
  Field:      GF(2^256)

Property: Any (t-1) shares reveal zero information about the secret.

5.2 Threshold Configuration

Users choose their own threshold across the 5 shards. The default is 2-of-5: five trusted contacts each hold one shard, and any two of them can cooperate to initiate recovery. The user can adjust this threshold at any time, generating a new set of shards.

5.3 Recovery Flow

The recovery process follows these steps:

1. Setup: The user splits their master key into 5 shards and distributes them to trusted guardians, each shard wrapped with ML-KEM-768 over secure, end-to-end encrypted channels.
2. Initiation: When recovery is needed, the user (or their designated heir) creates a recovery request through Keeplas.
3. Guardian Approval: Each guardian is notified and must independently submit their shard. Shards are transmitted over encrypted channels and are never stored together on the server.
4. Reconstruction: Once the threshold of shards has been submitted, the master key is reconstructed on a contact's device -- never on Keeplas servers.
5. Re-keying: The user generates a fresh 24-word recovery phrase and master key, re-wraps all vault item keys, and re-distributes new shards. The old shards are invalidated.

6.1 Automated Monitoring

Keeplas monitors user activity signals such as app logins, vault interactions, and explicit check-in confirmations. These signals are recorded as timestamps only -- no content or behavioral metadata is stored. The system tracks presence, not actions.

6.2 Configurable Intervals

Users configure their own check-in frequency -- weekly, monthly, or quarterly. If no activity signal is detected within the interval, the system enters an alert phase. Users can also set a grace period, which adds additional time before any action is taken. Travel Mode can pause Life Check entirely while a user is away.

6.3 Trigger Conditions & Notification Chain

When an inactivity threshold is reached, the following chain is executed:

1. User Alert: Keeplas sends escalating notifications to the user over WhatsApp and email (web push coming soon) asking them to confirm they are active.
2. Grace Period: If there is no response through the full check-in window (around 15 days with reminders), the system moves to the next stage.
3. Emergency Contact Notification: Designated trusted contacts are asked to confirm the user is unreachable, using the threshold and window the user set.
4. Delivery Execution: After a 72-hour grace period, if the user remains unresponsive and the configured conditions are met, the configured delivery rules are triggered (see Section 7).

7.1 Conditional Document Release

Users can specify which vault items should be released to which beneficiaries under each rule. Item keys for designated items are pre-wrapped with the beneficiary's public key so the server can deliver the ciphertext without ever decrypting it.

7.2 Time-Based and Event-Based Triggers

Triggers can be time-based (e.g., "after 180 days of inactivity"), event-based (e.g., "after Life Check alert is confirmed by 2 emergency contacts"), or combined. Multiple triggers can be chained with AND/OR logic to create sophisticated release conditions.

7.3 Verification Mechanisms

Before a delivery rule executes, the system performs multi-factor verification: the trigger condition must be met, the configured waiting period must have elapsed, and (optionally) a quorum of emergency contacts must confirm the situation. This multi-layered verification prevents accidental or premature release of sensitive data.

8.1 Data at Rest & Data in Transit

All data stored on Keeplas servers is already client-side encrypted. As an additional layer, server-side storage volumes use AES-256 full-disk encryption. All data in transit is protected by TLS 1.3 with forward secrecy. Certificate pinning is enforced in our native mobile applications to prevent MITM attacks.

8.2 Server Architecture (Minimal Trust)

The server is designed as a "dumb storage" layer. It receives encrypted blobs, stores them, and returns them on authenticated request. It never performs decryption, key derivation, or plaintext processing. Authentication tokens are short-lived and scoped. Backend services follow a zero-trust networking model with mutual TLS between internal services.

8.3 Logging & Audit Trail

Keeplas maintains a hash-chained audit log for security-relevant events (login attempts, key rotation, delivery-rule changes): every entry is immutable and tamper-evident, with each entry hashing the previous one. Logs contain event type, timestamp, source IP (hashed after 30 days), and action result. Vault contents, encryption keys, and recovery phrases are architecturally excluded from all logging pipelines.

9.1 GDPR Compliance

Keeplas is designed with GDPR compliance as a baseline. Users retain full ownership and control over their data. Because vault contents are end-to-end encrypted, Keeplas acts as a data processor with no ability to access the processed data. Users can export their full vault at any time, and account deletion permanently removes all stored ciphertext and associated metadata.

9.2 SOC 2 (Planned)

Keeplas is working toward SOC 2 Type II certification for the Trust Service Criteria of Security, Availability, and Confidentiality. Our infrastructure and operational processes are being aligned with these requirements, with an initial audit targeted for Q4 2026.

9.3 Third-Party Audits (Planned)

We are committed to regular, independent security audits of our cryptographic implementations, client applications, and server infrastructure. Audit results will be published in summary form on our security page. Our first comprehensive third-party penetration test and cryptographic review is scheduled for H2 2026.