CipherDrive™ separates cryptographic work, application logic, and storage infrastructure into different security zones. This architecture is designed so that ordinary encrypted storage does not require Ackaia's servers to possess plaintext file contents.
The client is responsible for security-sensitive operations such as:
generating cryptographic keys;
deriving key-encryption material where applicable;
encrypting files;
decrypting files;
encrypting selected metadata;
wrapping and unwrapping keys;
storing local key material when enabled;
running applicable pre-encryption risk checks.
This is the zone in which plaintext file content normally exists during ordinary encryption and decryption.
The application layer coordinates the service. It may:
authenticate users;
authorize account, session, and link access;
store operational metadata;
enforce storage and transfer quotas;
issue upload and download instructions;
manage public links;
apply policy and abuse-prevention controls;
coordinate product and entitlement state.
This layer does not need to become the ordinary plaintext file-processing environment for encrypted storage.
The storage layer stores:
encrypted file blobs;
encrypted key material;
operational metadata;
replication and reliability information needed to operate storage.
Possessing those encrypted blobs does not ordinarily provide the plaintext keys required to read them.
The architecture uses a layered hierarchy in which vault unlock material can protect a key-encryption key, which protects the master key, which in turn protects per-file keys.
Files are then encrypted with their own file keys instead of directly reusing the master key for every object.
CipherDrive uses AES-GCM for file contents, metadata, and key material where documented. AES-GCM provides confidentiality and authentication of ciphertext.
CipherDrive may also use Additional Authenticated Data to bind ciphertext to contextual information such as protocol version, object type, chunk number, or file identifier.
Large files can be split into chunks. Each chunk is encrypted with a unique IV under the file key. This allows the client to process large files incrementally rather than keeping an entire file in memory.
The architecture still depends on:
correct browser cryptography;
correct client implementation;
a non-compromised endpoint;
strong protection of local keys and vault secrets;
correct IV and protocol handling.
Cryptography is only one part of CipherDrive security. Ackaia may also use access controls, audit logs, rate limits, session security, secure transport, storage isolation, least-privilege internal access, monitoring, incident response, abuse detection, public-link controls, and vulnerability-disclosure processes.