KMS ARCHITECTURE

User-owned key custody,
for protected collaboration.

Only the user holds the keys to encrypted data. KKDoc combines advanced data protection with Passkey for simple and effortless.

Compare plansOpen product
WHY THIS DESIGN

Security starts with encryption standards.

Per-user DEK

Users hold their own AES‑256 CMK, protected by Passkey or recovery.

File‑chunk‑level encryption

Documents split into encrypted chunks, each secured with a unique IV.

Full‑chain collaboration protection

Content, edit history, and snapshots — all equally encrypted.

KEY FLOW

How the KMS fits into editing.

01

Unlock on the client

The owner unlocks the file key with a passkey.

02

Add the key to KMS

The app writes the 256-bit key to the KMS with a verified token.

03

KMS cache read

Key exchange and encryption/decryption — in‑memory only, never persisted.

04

Expire and reconnect safely

If the key expires, the editor asks the owner to unlock again.

TRUST BOUNDARIES

The design stays small on purpose.

The KMS is a local process with a narrow API, explicit token checks, and encrypted persistence around it.

Local-only attack surface

The raw key service is not public and rejects non-local requests.

Token-scoped access

Access is bound to verified collaboration tokens, not broad service secrets.

Encrypted state stays encrypted

Locked files clear plaintext and keep all payloads encrypted.