Skip to main content

Encryption Model

The Document Vault uses AES-256-GCM for symmetric encryption with TEE-based key management. All cryptographic operations execute inside a Trusted Execution Environment (TEE), ensuring that encryption keys and plaintext data never exist in accessible memory.

Encryption Algorithm: AES-256-GCM​

AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode) is the encryption algorithm used for all documents in the vault. It is an authenticated encryption scheme, meaning it provides both confidentiality and integrity in a single operation.

Why AES-256-GCM?​

  • 256-bit key size: Provides strong protection against brute-force attacks, including resilience against quantum computing threats.
  • Galois/Counter Mode (GCM): Combines encryption with authentication. This produces an authentication tag alongside the ciphertext.
  • Authenticated encryption: The authentication tag detects any modification to the ciphertext. If an attacker alters even a single bit of the encrypted file, decryption will fail and the tampering will be detected.

Initialization Vector (IV)​

Each document receives a unique, randomly generated IV at encryption time. The IV is stored alongside the on-chain metadata and is required for decryption. The IV does not need to be secret -- its purpose is to ensure that encrypting the same document twice produces different ciphertext.

Key Derivation​

The encryption key for each document is derived from the user's wallet-derived secret and a per-document salt. This ensures that each document has a unique encryption key, and that only the document owner can derive the key needed for decryption.

Per-Document Salt​

Each document receives its own randomly generated salt at upload time. The salt is stored in the on-chain metadata alongside the IPFS CID. Using a unique salt per document means that even if the same user uploads the same file twice, the derived encryption key will be different, producing different ciphertext.

The salt is public information. Its security contribution comes from preventing pre-computation attacks. An attacker who knows the salt still cannot derive the key without the wallet-derived secret.

Wallet-Derived Secret​

The input keying material is derived from the user's wallet:

  1. The user signs a deterministic message with their wallet's private key.
  2. The signature is processed inside the TEE to produce a stable secret.
  3. This secret serves as the basis for deriving encryption keys for the user's documents.

The wallet-derived secret never leaves the TEE. It is computed on each request and discarded after the cryptographic operation completes.

TEE-Based Key Management​

All key derivation and encryption/decryption operations occur inside the TEE. This provides the following guarantees:

Key Isolation​

  • The encryption key exists only in TEE memory during the encryption or decryption operation.
  • The key is derived on demand from the wallet-derived secret and per-document salt.
  • After the operation completes, the key is zeroed out of TEE memory.
  • No key is ever written to disk, transmitted over the network, or logged.

Memory Protection​

  • TEE memory is hardware-encrypted and inaccessible to the host operating system, hypervisor, or server operator.
  • Even if the physical server is compromised, the TEE's memory contents remain protected.

Attestation​

  • The TEE attestor produces a remote attestation proof that its code and environment have not been tampered with.
  • Clients can verify this attestation before submitting documents for encryption.

Encryption Workflow Summary​

1. User authenticates with wallet signature
2. TEE derives wallet secret from signature
3. TEE generates random salt for the document
4. TEE generates random IV for the document
5. TEE derives AES-256 encryption key from wallet secret + salt
6. TEE encrypts document with AES-256-GCM using the key and IV
7. Ciphertext uploaded to IPFS
8. Metadata (CID, salt, IV, document type, timestamp) recorded on-chain
9. Key, wallet secret, plaintext zeroed from TEE memory

Decryption Workflow Summary​

1. User authenticates with wallet signature
2. TEE derives wallet secret from signature
3. TEE reads encryption parameters (salt, IV) from on-chain metadata
4. TEE fetches ciphertext from IPFS
5. TEE re-derives AES-256 encryption key from wallet secret + salt
6. TEE decrypts document with AES-256-GCM, verifying authentication tag
7. Plaintext delivered to user over TLS
8. Key, wallet secret, plaintext zeroed from TEE memory

Security Considerations​

  • No key escrow: There is no backup of encryption keys. If a user loses access to their wallet, their documents become permanently inaccessible. This is a deliberate design choice prioritizing security over convenience.
  • Per-document keys: Each document has a unique key derived from a unique salt, so compromising one document's key does not compromise others.