Security & Trust

Key security and trust concepts that define how the platform protects data, verifies integrity, and enforces access — without exposing internal implementation details.

Attack Surface

The total set of points where an unauthorized party could attempt to interact with the system. The platform's zero-knowledge architecture minimizes the attack surface by ensuring the server never has access to sensitive content or key material in plaintext — so even a fully compromised server cannot read document contents or reconstruct encryption keys. The server does retain operational metadata (statuses, timestamps, tokens, and wrapped keys), which defines the residual attack surface.

Analogy: The fewer windows and doors a building has, the fewer entry points a burglar has — sensitive content and keys are locked away, even if the building itself is entered.

Attestation

A cryptographic proof that a piece of software is running in a genuine, unmodified state inside a trusted execution environment. The platform uses attestation to gate the secure enclave's access to platform keys — the key management service only releases keys to an enclave instance that can prove its code has not been tampered with.

Analogy: A notary stamp on a document proving it was signed in a genuine, unmodified state — but for software running on a server.

Authentication

The process of verifying that a user or device is who they claim to be. The platform uses token-based authentication so that identity can be proven without transmitting passwords or personal details to the server.

During login, an Oblivious Pseudorandom Function (OPRF) derives a blind index from the email without the server ever seeing it — even the authentication handshake is zero-knowledge.

Analogy: A key card that proves you are who you claim to be without the front desk calling your manager — the card itself is the proof.

Authorization

The process of determining what an authenticated entity is permitted to do. Authorization is enforced cryptographically — if a client doesn't hold the right keys, access is simply impossible regardless of server-side policy.

Analogy: Even with a valid ID, you cannot enter the server room without the right clearance — no server policy can grant access the client's keys don't allow.

Defense in Depth

A security strategy that layers multiple independent protections so that the failure of any single layer does not compromise the system. The platform applies this principle across encryption, hardware isolation, access control, and audit logging — each layer operates independently.

Analogy: A medieval castle with a moat, a wall, a portcullis, and guards — each layer independent of the others, so defeating one doesn't automatically compromise the rest.

Encrypted Audit Log

A tamper-evident record of security-relevant events that is itself encrypted and cryptographically chained. Each entry is encrypted with a unique key inside the secure enclave and linked to all prior entries via an HMAC chain — any modification, insertion, or reordering is detectable on the next verified read.

Currently emitted events include authentication outcomes (login success and failure, registration, session revocation) and administrative platform key migration. Audit logs provide accountability and forensic capability without exposing sensitive details to anyone who shouldn't see them.

Analogy: A tamper-sealed ledger that records every action but is locked so only authorized parties can read it — everyone can see that an entry exists, but not what it says.

Fail-Closed

A design principle where, if a security check encounters an error or ambiguity, the system denies access by default rather than allowing it. The platform uses fail-closed behavior throughout its access control and encryption layers to prevent accidental data exposure.

Analogy: A door that locks when the power goes out, not unlocks — the safe default is always denial.

Hardware-Isolated Enclave

A secure, hardware-protected execution environment that isolates sensitive operations — key management, document processing, and audit log encryption — from the rest of the system, including the operating system and platform administrators. Under the trusted execution environment threat model, even an operator with root access to the host cannot extract keys or plaintext from the enclave without a valid attestation identity.

Analogy: A safe inside a vault — even someone with root access to the vault cannot open the inner safe without the enclave's specific key.

Integrity Verification

The process of confirming that data has not been altered, corrupted, or tampered with since it was created or last validated. The platform uses cryptographic techniques to chain records together so that any modification — even a single bit — is immediately detectable.

Analogy: A checksum on a downloaded file — if a single byte changes, the checksum fails, proving tampering occurred.

Least Privilege

A security principle where every component, user, or process is granted only the minimum access needed to perform its function — nothing more. Keys are scoped narrowly, and the server itself operates with zero privilege over sensitive user data.

Analogy: A cashier who can process transactions but cannot open the safe or change prices — each role has exactly the permissions it needs, nothing more.

Secure Key Destruction

The process of permanently and irrecoverably erasing cryptographic keys when they are no longer needed. Proper key destruction ensures that even if old ciphertext is retained, it can never be decrypted — providing a hard guarantee of data deletion.

Analogy: Shredding the only copy of a combination — even if the safe survives, it can never be opened again.

Tamper Evidence

A property of a system or data structure that makes any unauthorized modification detectable. Audit logs and data records are designed to be tamper-evident — if any entry is altered or removed, the cryptographic chain breaks and the tampering is flagged.

Analogy: A wax seal on an envelope — breaking it to read the letter is obvious and irreversible, so the recipient knows immediately if it was opened.

Zero-Knowledge Boundary

The architectural dividing line between components that can see plaintext — your device and the secure enclave — and components that cannot. Everything beyond this boundary operates exclusively on ciphertext, tokens, and cryptographic proofs. This boundary is enforced both in software design and through hardware isolation.