CipherDrive™ uses several security layers together. Encryption is the most visible layer, but it is not the only one.
For supported file-storage workflows, CipherDrive encrypts file contents in your browser or client before ordinary encrypted storage.
A typical upload uses:
a random per-file encryption key;
AES-GCM authenticated encryption;
chunked encryption for large files;
wrapped file keys;
a higher-level vault key hierarchy;
client-side decryption when you retrieve the file.
Under normal operation, after encryption is complete, Ackaia stores encrypted file blobs and encrypted key material but does not ordinarily possess the plaintext file keys required to read the stored content.
CipherDrive does not use one single key directly for every file. Individual files receive separate file keys, which are then protected by higher-level key material.
This helps isolate files from each other and supports safer sharing, rewrapping, and future key-management operations.
CipherDrive uses AES-GCM where documented. AES-GCM protects both confidentiality and integrity.
This means an attacker should not be able to modify encrypted content without the client detecting that the ciphertext no longer authenticates correctly.
CipherDrive relies on Ackaia ID for account authentication and can use account, session, entitlement, and security checks before allowing product access.
Ackaia may use controls such as:
session validation and revocation;
security challenges;
suspicious-activity detection;
authentication logs;
device and browser signals;
rate limits;
additional authentication controls where available.
Ackaia's broader security program can include:
least-privilege access;
role-based or policy-based access controls;
environment separation;
audit logging;
monitoring and alerting;
secure change management;
vulnerability management;
incident response;
backup and recovery controls;
provider and dependency risk management.
These controls protect the service around the encrypted-storage model rather than replacing it.
Sharing adds another security boundary. CipherDrive can use server-side link status, access checks, transfer controls, revocation, and abuse-prevention mechanisms while the recipient's browser handles decryption.
A link can be disabled without requiring Ackaia to decrypt the underlying file.
CipherDrive may run a Risk Assessment Engine before encryption for severe abuse, child-safety protection, malware detection, fraud prevention, and other prohibited content.
This is a disclosed pre-encryption boundary. It does not create a general server-side key for later decryption of stored files.
Client-side encryption means your browser, device, operating system, local key material, and active session matter.
If the trusted endpoint is compromised, an attacker may be able to access plaintext while you are using the service or steal local cryptographic material.
CipherDrive reduces trust in the storage provider, but it cannot remove the need to trust your own endpoint.