What Can Ackaia Not See in CipherDrive?

Under normal operation, after client-side encryption has completed, CipherDrive™ is designed so that Ackaia is not expected to see several important classes of plaintext cryptographic data.

Ackaia is not expected to see

Why Ackaia cannot normally read the file

The file is encrypted by your client using a per-file key. That key is itself wrapped before being stored. The higher-level master key is not intended to be available to Ackaia servers in plaintext.

As a result, possession of the encrypted file blob and encrypted key material does not, by itself, provide the plaintext key needed to decrypt the object.

Important assumptions

These guarantees depend on the security model operating as intended. They assume, among other things, that:

Pre-encryption checks are a separate boundary

CipherDrive may perform disclosed safety checks before encryption. A technical signal generated before encryption should not be confused with Ackaia retaining a general key capable of decrypting the encrypted file later.

Metadata may still be visible

Not seeing the plaintext file does not mean Ackaia has no information about the object. Operational metadata such as size, timestamps, object identifiers, folder relationships, sharing status, transfer usage, IP addresses, and security events can remain visible.

If Ackaia does not possess the required user-controlled cryptographic material, it may be technically unable to provide plaintext CipherDrive content. Where legally required and technically available, Ackaia may instead be able to provide responsive account information or metadata.

Important: “Ackaia cannot normally decrypt this stored file” is a technical statement about key custody. It is not a claim that the service has no metadata, no security controls, or no legal obligations.