Ackaia One Security & Encryption Whitepaper#

Ackaia Corporation v1.00.00 April 27, 2026 1233 York Avenue, Apt. 301 New York, NY 10065 United States of America www.ackaia.com

Issued: April 27, 2026

Publisher: Ackaia Corporation, 1233 York Avenue, New York, NY 10065, United States

(“Ackaia”, “Ackaia Corp.”, “we”, “our”, “us”)

Product: Ackaia One (“the Platform”)

Revision History#

1. Executive Summary#

Ackaia One is a privacy-first suite of digital services designed to protect user data through client-side encryption, minimal content exposure, transparent security architecture, and responsible abuse-prevention systems. Ackaia One Storage uses end-to-end encryption for supported file-storage workflows. Files are encrypted in the user’s browser before being uploaded to Ackaia infrastructure. In normal operation, after encryption has completed, Ackaia stores encrypted file blobs and encrypted key material, but does not possess the cryptographic keys required to decrypt stored file contents. This model is commonly described as zero-knowledge storage. In the context of Ackaia One, zero-knowledge means that Ackaia does not ordinarily know, receive, or retain the plaintext file contents or the unencrypted file keys required to read stored user files. However, zero-knowledge does not mean that Ackaia collects no metadata. It also does not mean that Ackaia One is abuse-blind. Ackaia One may operate a Risk Assessment Engine before client-side encryption to generate and compare technical safety signals, such as cryptographic hashes or perceptual hashes, for the purpose of detecting known child sexual abuse material, severe abuse, malware, or other prohibited content. Ackaia One’s security model is therefore built around two principles:

• Lawful user content should be strongly protected from unnecessary access.

• Privacy features must not turn Ackaia One into infrastructure for exploitation, abuse, malware, fraud, or illegal content.

2. Goals of This Whitepaper#

This document explains how Ackaia One Storage is designed to protect user files and what the limits of that protection are. It is intended for:

• users evaluating Ackaia One’s privacy claims;

• professionals handling sensitive files;

• developers and security researchers reviewing Ackaia’s cryptographic design;

• legal, compliance, and privacy reviewers;

• organizations considering use of Ackaia One for confidential workflows.

This whitepaper explains:

• what Ackaia means by end-to-end encryption;

• what Ackaia means by zero-knowledge;

• how file keys, master keys, encrypted metadata, and encrypted chunks work;

• what Ackaia can and cannot access;

• what metadata remains visible;

• how public sharing works;

• how local browser key storage affects security;

• how the Risk Assessment Engine operates before encryption;

• what threats the system is designed to mitigate;

• what threats remain outside the system’s guarantees.

3. Design Philosophy#

Ackaia One is based on the belief that cloud services should not require users to expose their most sensitive files to the service provider whenever avoidable. Traditional cloud storage often gives the provider technical access to user content, even if internal policies restrict employee access. Ackaia One uses a different model: supported file contents are encrypted before storage, and the server stores only encrypted objects and operational metadata. The architecture follows four core principles. 3.1 Client-Side Protection File encryption occurs in the user’s browser or client environment before the encrypted file is uploaded. This reduces the need for Ackaia servers to handle plaintext file contents during ordinary storage operations. 3.2 Key Separation Ackaia One uses separate cryptographic keys for different purposes. The user’s master key is not used directly to encrypt every file. Instead, individual file keys are generated for file content, then wrapped or encrypted using higher-level key material. This limits the exposure created by any single key and makes sharing workflows more flexible. 3.3 Minimal Plaintext Exposure The storage system is designed so that file contents are not stored in plaintext by Ackaia. Where metadata can be encrypted, Ackaia may encrypt it. Where metadata is required for service operation, Ackaia documents its visibility. 3.4 Honest Safety Boundaries Ackaia One is privacy-first, not abuse-blind. Certain safety checks may occur before encryption. This is especially important for combating child sexual abuse material, malware, fraud, and severe abuse. Ackaia aims to disclose these boundaries clearly rather than hiding them behind vague privacy language.

4. Important Terms#

4.1 Plaintext Plaintext means data in readable, unencrypted form. 4.2 Ciphertext Ciphertext means encrypted data that should not be readable without the correct cryptographic key and parameters. 4.3 Master Key The master key is a high-entropy cryptographic key associated with the user’s encrypted storage vault. It is used to protect lower-level keys, such as file keys. 4.4 File Key A file key is a cryptographic key generated for a specific file. It is used to encrypt and decrypt that file’s content. 4.5 Key Wrapping Key wrapping means encrypting one key using another key. In Ackaia One, file keys may be wrapped by the master key or by share-specific key material. 4.6 End-to-End Encryption End-to-end encryption means that content is encrypted before it leaves the user’s client environment and remains encrypted while stored by Ackaia. 4.7 Zero-Knowledge Storage Zero-knowledge storage means that, under normal operation and after client-side encryption has completed, Ackaia does not possess the keys needed to decrypt stored encrypted file contents. 4.8 Metadata Metadata means information about files or usage that is not necessarily the file content itself. Examples include file size, upload time, object ID, folder relationship, sharing status, and transfer usage. 4.9 Risk Assessment Engine The Risk Assessment Engine is Ackaia’s safety system that may run before encryption to generate and compare technical safety signals, such as hashes or perceptual hashes, against trusted abuse-prevention databases.

5. Cryptographic Building Blocks#

Ackaia One uses standard browser cryptography through the Web Crypto API where supported. The Web Crypto API provides cryptographic primitives such as key generation, encryption, decryption, key derivation, and signing through SubtleCrypto. It is a low-level API, which means the surrounding protocol design must carefully handle key generation, IV uniqueness, metadata authentication, and error handling. 5.1 AES-GCM Ackaia One uses AES-GCM for authenticated encryption of file contents, metadata, and key material. AES-GCM provides both confidentiality and integrity. This means that modified ciphertext should fail decryption rather than silently producing corrupted plaintext. A critical requirement of AES-GCM is that an initialization vector, or IV, must not be reused with the same key. MDN’s Web Crypto documentation states that the IV must be unique for every encryption operation with a given key and notes that the AES-GCM specification recommends a 96-bit IV. 5.2 PBKDF2 Ackaia One may use PBKDF2-HMAC-SHA-256 to derive key-encryption material from a user passphrase, PIN, or vault secret where applicable. OWASP’s Password Storage Cheat Sheet recommends a work factor of 600,000 or more for PBKDF2-HMAC-SHA-256 when PBKDF2 is used in FIPS-compatible contexts. Ackaia may increase KDF parameters over time as hardware improves. 5.3 Randomness Ackaia One relies on cryptographically secure randomness provided by the browser environment, such as crypto.getRandomValues, for generating keys, salts, nonces, and IV base values. 5.4 Additional Authenticated Data Ackaia One may use Additional Authenticated Data, or AAD, with AES-GCM. AAD binds encrypted data to a specific context, such as protocol version, object type, chunk number, or file identifier. AAD is not secret, but it is authenticated. If the AAD does not match during decryption, decryption fails.

6. High-Level Architecture#

Ackaia One Storage has three major security zones. User Browser / Client

• Generates keys

• Encrypts files

• Decrypts files

• Stores local key material when enabled

• Runs pre-encryption Risk Assessment Engine where applicable

Ackaia Application Layer

• Authenticates users

• Stores metadata

• Enforces quotas

• Issues upload/download instructions

• Manages public links

• Applies abuse prevention and policy controls

Ackaia Storage Infrastructure

• Stores encrypted file blobs

• Stores encrypted key material

• Stores operational metadata

• Does not need plaintext file contents for ordinary storage

The key design choice is that file encryption and decryption happen in the client environment, while Ackaia infrastructure stores encrypted objects and coordinates access.

7. File Encryption Flow#

A typical file upload follows this conceptual flow.

• User selects a file.

• Risk Assessment Engine may evaluate the file before encryption.

• Browser generates a random file key.

• Browser encrypts file metadata, such as filename where supported.

• Browser splits the file into chunks.

• Browser encrypts each chunk with AES-GCM using the file key.

• Browser wraps the file key using the user’s master key.

• Browser uploads encrypted chunks and encrypted key material.

• Ackaia stores encrypted blobs and operational metadata.

At no point during ordinary encrypted storage does Ackaia need plaintext file contents after the file has been encrypted.

8. File Decryption Flow#

A typical file download follows this conceptual flow.

• User requests a file.

• Ackaia verifies account/session/link permissions.

• Ackaia provides encrypted file data and encrypted key material.

• Browser unwraps the file key using available key material.

• Browser downloads encrypted chunks.

• Browser decrypts chunks locally.

• Browser reconstructs the file for the user.

If the user does not have the required key material, Ackaia may be unable to recover the file.

9. Key Hierarchy#

Ackaia One uses a layered key hierarchy. Vault Passphrase / PIN / Local Unlock Secret ↓ Key-Encryption Key ↓ Encrypted Master Key ↓ Master Key ↓ Encrypted File Key ↓ File Key ↓ Encrypted File Content This model separates user authentication from file encryption and allows individual files to have independent keys. 9.1 Master Key The master key is high-entropy cryptographic material generated for the user’s encrypted storage vault. The master key is not meant to be known by Ackaia servers in plaintext. 9.2 File Keys Each file receives its own file key. Using per-file keys helps isolate files from each other and supports future features such as sharing, rotation, rewrapping, and selective revocation. 9.3 Wrapped Keys File keys are encrypted, or wrapped, before being stored by Ackaia. Ackaia may store encrypted file keys, non-secret IVs, salts, and other cryptographic parameters necessary for client-side decryption, but not the unencrypted file keys.

10. Chunk Encryption#

Large files are encrypted in chunks. Chunking allows the browser to upload and download large files without loading the entire file into memory. It also supports resumable or multipart upload workflows. Ackaia One uses a chunk IV construction designed to avoid reusing an IV with the same file key. Conceptually: Chunk IV = 64-bit random file nonce + 32-bit chunk number Each file receives a random base nonce. Each chunk uses a unique chunk number. Together, they form a 96-bit AES-GCM IV. This design is intended to satisfy the AES-GCM requirement that the IV be unique for each encryption operation under the same key. Reusing an IV with AES-GCM under the same key can seriously compromise security.

11. Metadata Encryption#

Ackaia One may encrypt selected metadata, such as filenames, before storing it. A typical encrypted filename payload may include: protocol version IV ciphertext authentication tag Ackaia may still need to store some metadata in visible or partially visible form to operate the service. For example, Ackaia may need to know whether an object is a file or folder, how much encrypted storage it uses, whether it is shared, and how it relates to other objects in a folder hierarchy. Metadata encryption is therefore selective, not absolute.

12. What Ackaia Cannot Normally See#

Under normal operation, after client-side encryption has completed, Ackaia is not expected to see:

• plaintext file contents

• plaintext file keys

• plaintext master key

• plaintext encrypted-storage contents

• decrypted file data during ordinary storage

If filename encryption is enabled for a given object, Ackaia is also not expected to see the plaintext filename after encryption. However, the exact protection depends on the active client version, feature support, migration state, and whether the user’s device or browser is uncompromised.

13. What Ackaia Can Still See#

Zero-knowledge storage does not mean that Ackaia sees nothing.

• Ackaia may still process:

• account identifier

• subscription plan

• billing state

• storage usage

• encrypted file size

• upload timestamp

• update timestamp

• download timestamp

• folder structure or parent-child relationships

• object type, such as file or folder

• MIME category or generalized media category

• sharing status

• public link status

• transfer usage

• IP addresses

• session and device information

• security logs

• risk signals generated before encryption

• blocked upload records

• abuse reports

• legal request records

This information is necessary for account management, billing, transfer limits, abuse prevention, public sharing, support, reliability, and legal compliance. Ackaia’s design goal is not “zero metadata.” The goal is to prevent ordinary server-side access to stored file contents while being transparent about the metadata that remains operationally visible.

14. Browser Key Storage#

For usability, Ackaia One may store local key material, wrapped keys, or unlock state in the user’s browser or device. This allows users to access their encrypted storage without entering a PIN or vault passphrase every time. This design improves user experience, but it creates an important security boundary: If the local browser, device, operating system, session, extension environment, or user account is compromised, local key material may be at risk. This is not a server-side zero-knowledge failure. It is a local endpoint risk. Ackaia may provide controls to clear local keys, revoke remembered devices, sign out of sessions, or require re-authentication. Users handling highly sensitive files should:

• keep their devices updated;

• avoid untrusted browser extensions;

• use strong device locks;

• avoid shared or public computers;

• sign out when appropriate;

• clear local access on compromised devices;

• understand that browser-side convenience affects local risk.

15. Public Sharing Model#

Ackaia One may allow users to share encrypted files or folders through public links. A public share link may include or rely on:

• object identifier

• server-side access permission

• URL fragment key material

• encrypted file key

• public download endpoint

• transfer limits

• link status

A common encrypted-sharing pattern is to place decryption key material in the URL fragment after #. For example: https://ackaia.one/share/object-id#decryption-key The URL fragment is normally not sent to the server in ordinary HTTP requests. This allows the browser to receive the key while Ackaia servers receive only the object identifier and operational request data. However, public sharing has limits:

• anyone with the full link and required key material may access the shared file;

• recipients can copy, download, screenshot, forward, or re-upload content;

• disabling the link can prevent future access through Ackaia, but cannot erase copies already obtained;

• if the full URL is pasted into third-party services, browser extensions, analytics tools, screenshots, or logs, the key may be exposed;

• shared links may still produce server-visible metadata such as IP address, timestamp, transfer usage, object ID, and link status.

Public sharing should therefore be used carefully.

16. Risk Assessment Engine#

Ackaia One may operate a Risk Assessment Engine before client-side encryption. This is one of the most important boundaries in the Ackaia One security model. The Risk Assessment Engine exists because encrypted storage should not be used to hide or distribute severe abuse, especially child sexual abuse material, malware, exploitation, fraud, or other prohibited content. 16.1 When It Runs The Risk Assessment Engine may run before the file is encrypted and uploaded. This means that, for applicable file types or workflows, the client or controlled processing step may inspect the file enough to generate safety signals before encryption occurs. 16.2 What It Generates The Risk Assessment Engine may generate:

• cryptographic hashes

• perceptual hashes

• media fingerprints

• file signatures

• similarity indicators

• known-content match signals

• risk scores

• blocked-upload records

• technical metadata

16.3 What It Compares Against Risk signals may be compared against:

• trusted CSAM hash databases

• child-safety systems

• anti-abuse databases

• malware indicators

• internal safety systems

• industry-recognized safety tools

• public or private abuse-prevention datasets

Microsoft describes PhotoDNA as technology that creates a unique digital signature, or hash, of an image to compare against known illegal images, and states that it is not facial recognition and cannot be used to recreate the original image. 16.4 Why This Does Not Contradict Zero-Knowledge Storage Ackaia’s zero-knowledge claim applies to stored encrypted content after client-side encryption has completed. The Risk Assessment Engine operates before encryption. It is a safety boundary in the upload pipeline, not a server-side ability to decrypt stored files. Ackaia’s position is: Ackaia One is zero-knowledge for stored encrypted file contents. Ackaia One is not abuse-blind before encryption. 16.5 What Happens on a Match If the Risk Assessment Engine detects a high-confidence match or severe risk signal, Ackaia may:

• block the upload;

• prevent storage;

• disable sharing;

• preserve technical records;

• restrict the account;

• report suspected illegal activity where required or appropriate;

• cooperate with lawful requests or child-protection processes.

16.6 Privacy Boundary The Risk Assessment Engine is not intended for advertising, behavioral profiling, commercial mining of file contents, or selling information about user files. Its purpose is safety, abuse prevention, legal compliance, child protection, and protection of the platform.

17. Threat Model#

Ackaia One is designed to mitigate several important threats. 17.1 Threat: Storage Infrastructure Compromise If encrypted storage infrastructure is accessed without authorization, attackers should not be able to read plaintext file contents without the required keys. Mitigation:

• client-side encryption

• per-file keys

• encrypted file blobs

• encrypted key material

• no ordinary server-side plaintext file contents

17.2 Threat: Unauthorized Internal Access Ackaia employees or internal systems should not be able to casually read stored encrypted file contents. Mitigation:

• zero-knowledge storage model

• encrypted file contents

• encrypted file keys

• access controls

• audit logs

• limited operational metadata

17.3 Threat: Public Link Leakage If a public link is shared with the wrong person, that person may access the file. Mitigation:

• link revocation

• server-side access checks

• transfer limits

• public-link disable controls

• user education

Limitation:

• If the recipient already downloaded or copied the file, Ackaia cannot revoke those copies.

17.4 Threat: Compromised User Device If the user’s device or browser is compromised, local key material may be exposed. Mitigation:

• local key clearing

• session revocation

• device hygiene guidance

• optional re-authentication controls

Limitation:

• No cloud encryption model can fully protect data once the trusted endpoint is compromised.

17.5 Threat: Weak Vault Secret If a user chooses a weak PIN or passphrase, an attacker with access to encrypted key material may attempt offline guessing. Mitigation:

• PBKDF2-HMAC-SHA-256

• high iteration count

• salted derivation

• future parameter upgrades

• strong passphrase guidance

Limitation:

• A weak human-chosen secret can still reduce security.

17.6 Threat: Malicious or Prohibited Uploads Attackers may attempt to use encrypted storage to hide illegal content or malware. Mitigation:

• Risk Assessment Engine before encryption

• hash matching

• public link enforcement

• abuse reports

• rate limits

• account enforcement

• legal reporting where appropriate

18. Out-of-Scope Threats#

No encryption system protects against every possible threat. The following are outside Ackaia One’s core zero-knowledge guarantee:

• malware on the user’s device;

• malicious browser extensions;

• phishing that steals credentials or keys;

• screen recording or screenshots by the user or recipient;

• users intentionally sharing files with others;

• recipients redistributing downloaded files;

• weak device passwords;

• compromised operating systems;

• compromised browser runtime;

• legal compulsion directed at the user;

• content before encryption, where processed by the Risk Assessment Engine;

• metadata that must remain visible for service operation;

• files exported, downloaded, or stored outside Ackaia One;

• user-provided support attachments containing sensitive data.

19. Security Guarantees#

Ackaia One is designed to provide the following guarantees under normal operation: Stored file contents are encrypted before being stored. Ackaia does not ordinarily possess plaintext file contents after encryption. Ackaia does not ordinarily possess plaintext file keys. Ackaia cannot normally decrypt stored encrypted files on behalf of the user. Tampering with AES-GCM ciphertext should cause decryption failure. File contents are encrypted with per-file keys. Large files are encrypted chunk-by-chunk with unique IVs per chunk. These guarantees assume: the browser cryptography implementation behaves correctly; the user’s device is not compromised; the client code has not been maliciously modified; the user protects credentials and local keys; the cryptographic protocol is implemented as documented; the user does not intentionally share key material.

20. Limitations and Non-Guarantees#

Ackaia One does not guarantee:

• zero metadata;

• protection from compromised devices;

• protection from malicious browser extensions;

• recovery if encryption keys are lost;

• revocation of files already downloaded by recipients;

• detection of all illegal content;

• absence of false positives in safety systems;

• suitability for every regulated or classified use case;

• permanent availability;

• compatibility with every browser or device;

• protection from user error;

• cryptographic protection for content before encryption.

Ackaia prefers to state these limitations clearly rather than imply impossible guarantees.

21. Data Recovery and Key Loss#

Because Ackaia One is designed around zero-knowledge storage, Ackaia may be unable to recover encrypted files if the user loses required key material. This may include loss of:

• vault passphrase

• PIN

• recovery material

• local browser key

• device key

• master key

• share key

Account recovery and file recovery are not the same. Ackaia may be able to help a user recover access to their Ackaia ID account, but that does not necessarily mean Ackaia can decrypt files stored under a lost encryption key. Users should keep recovery material secure and maintain backups where appropriate.

22. Source-Available Cryptographic Engine#

Ackaia may publish portions of the Ackaia One cryptographic engine as source-available software. The purpose is to allow users, developers, and researchers to inspect the cryptographic design and verify that Ackaia’s public claims match the client-side encryption implementation. Source-available does not necessarily mean open source. The code may be subject to restrictions on commercial use, redistribution, modification, or competitive deployment. The public repository may include:

• key generation logic

• metadata encryption logic

• file key wrapping logic

• chunk encryption logic

• sharing helpers

• protocol documentation

• test vectors

• security notes

The public repository may exclude:

• production backend code

• internal infrastructure

• billing systems

• abuse-detection secrets

• deployment details

• operational credentials

• private security controls

Security researchers should follow Ackaia’s Responsible Disclosure Policy when reporting vulnerabilities.

23. Cryptographic Versioning#

Ackaia One may evolve its cryptographic protocol over time. Protocol versioning allows Ackaia to:

• improve key derivation parameters;

• add stronger metadata authentication;

• migrate encryption formats;

• support new sharing models;

• improve browser compatibility;

• preserve compatibility with older encrypted files;

• deprecate weaker legacy formats.

Where possible, Ackaia may design new clients to decrypt older formats while encrypting new content using the latest protocol version. Users should keep their client updated to benefit from security improvements.

24. Operational Security#

Ackaia’s cryptographic model is only one part of the security system. 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

• billing controls

• vulnerability disclosure processes

Ackaia’s security posture may evolve as the product matures.

25. Incident Response#

If Ackaia identifies a security incident, the response may include:

• investigation;

• containment;

• mitigation;

• credential or session revocation;

• patching;

• user notification where appropriate or legally required;

• law-enforcement or regulator notification where required;

• public security advisories where appropriate;

• post-incident review.

Because Ackaia One stores encrypted files, the impact of a storage-layer incident may depend on whether encrypted blobs, encrypted key material, metadata, local key material, account credentials, or client code were affected.

26. User Security Recommendations#

Ackaia recommends that users:

• use a strong account password;

• enable multi-factor authentication when available;

• protect their email account;

• avoid shared or public computers;

• avoid untrusted browser extensions;

• keep browsers and operating systems updated;

• lock devices with strong authentication;

• treat public links as sensitive;

• revoke links that are no longer needed;

• keep recovery material secure;

• export backups for critical files where appropriate;

• report suspicious activity promptly.

For high-sensitivity workflows, users should consider dedicated devices, hardened browsers, limited extensions, stronger passphrases, and strict link-sharing practices.

27. Responsible Disclosure#

Ackaia welcomes responsible security review. Researchers should report suspected vulnerabilities to: security@ackaia.com Reports should include:

• description of the issue;

• affected component;

• reproduction steps;

• potential impact;

• proof of concept, if safe;

• suggested remediation, if available.

Researchers must not:

• access data that does not belong to them;

• disrupt the Service;

• perform denial-of-service testing;

• exfiltrate secrets;

• publicly disclose unresolved vulnerabilities before Ackaia has had a reasonable opportunity to investigate;

• use vulnerabilities for extortion, coercion, or unauthorized access.

28. Plain-English Summary#

Ackaia One encrypts supported files in your browser before uploading them. Ackaia stores encrypted files, encrypted keys, and metadata needed to run the service. After encryption, Ackaia normally cannot read your stored file contents because it does not have the required keys. Ackaia can still see some metadata, such as storage size, timestamps, account information, transfer usage, sharing status, and security logs. Ackaia may store local key material in your browser so you do not need to enter your PIN or passphrase constantly. This improves usability, but your device security matters. Public links are powerful. Anyone with the full link and required key material may access the shared file. Ackaia may run a Risk Assessment Engine before encryption to detect known CSAM, malware, or severe abuse. This does not mean Ackaia can decrypt your stored files later. It means Ackaia performs safety checks before encrypted storage. Ackaia One is privacy-first, not abuse-blind.

29. Final Security Statement#

Ackaia One is designed to reduce trust in the service provider. Instead of asking users to simply believe that Ackaia will not read their files, Ackaia One uses client-side encryption so that, under normal operation, Ackaia does not have the keys required to read stored encrypted file contents. At the same time, Ackaia recognizes that privacy infrastructure must not become abuse infrastructure. The Risk Assessment Engine, public-link controls, abuse reporting, and enforcement systems exist to protect children, victims, users, and the platform. The result is a security model with two commitments: Your lawful private files should remain private. Ackaia One must not be used as a shield for exploitation, abuse, or illegal harm. Ackaia will continue improving the cryptographic design, documenting its limitations, publishing source-available components where appropriate, and inviting responsible security review. End of Whitepaper