Your CipherDrive™ vault is the encrypted-storage security boundary associated with your files. It uses a layered key hierarchy so that a password or PIN is not simply used as the direct encryption key for every file.
The CipherDrive whitepaper describes the hierarchy conceptually as:
Vault passphrase / PIN / local unlock secret
↓
Key-encryption key
↓
Encrypted master key
↓
Master key
↓
Encrypted file key
↓
File key
↓
Encrypted file content
Depending on the active client and feature, a passphrase, PIN, device key, local unlock secret, or recovery mechanism may be involved in unlocking the cryptographic hierarchy.
A human-chosen secret is not necessarily used directly as a file-encryption key. Where applicable, CipherDrive may derive stronger key-encryption material from it using a password-based key derivation function.
The key-encryption key is used to protect higher-value key material, such as the encrypted master key. This creates separation between the human unlock secret and the random keys used deeper in the system.
The master key is high-entropy cryptographic material associated with the encrypted vault. It is not intended to be known by Ackaia servers in plaintext.
The master key is not used directly to encrypt every file. Instead, it protects or wraps lower-level file keys.
Each file receives its own random file key. That file key encrypts the file contents and can also participate in related object-specific cryptographic operations.
Per-file keys reduce the need to reuse one encryption key across unrelated content and make sharing and future key-management operations more flexible.
A wrapped key is a key stored in encrypted form. Ackaia may store encrypted file keys and non-secret cryptographic parameters needed for client-side decryption without storing the plaintext file keys themselves.
Account authentication remains separate from file encryption.
Files can have independent keys.
The master key does not need to encrypt all file bytes directly.
File keys can be wrapped or rewrapped for different access models.
Loss or exposure can be contained more cleanly than with one reused key.
Ackaia ID proves account identity and authorization. It does not automatically give Ackaia the plaintext master key or file keys.
This is why account recovery may succeed while encrypted-file recovery still fails if required cryptographic material is permanently lost.