Each file protected by Atakama is individually encrypted with its own unique AES 256-bit encryption key. Authenticated metadata and the need to approve file renames is vital to Atakama's security.
For example, a user has one document named Taxes.docx and a second document named FamilyPieRecipe.docx. Both files are encrypted but only Taxes.docx contains sensitive information that if stolen could be detrimental to the user. When accessing these files the user receives a MofNop request on the Atakama Mobile app running on their mobile device. The request identifies the specific file being accessed by the user, which is either “File Authorization for Taxes.docx” or "File Authorization for FamilyPieRecipe.docx". If an adversary was able to access the location of the two files and was able to freely change filenames, the user could be tricked into opening Taxes.docx when they intended to open FamilyPieRecipe. To ensure users always approve opening intended files only, Atakama requires a MofNop approval for the file rename.
Metadata, in this context, is the string of text identifying a given cryptographic object, such as a file. When using Atakama as a filesystem, that metadata is simply the path of the file within the Atakama folder. As described above, it’s important to know which file is actually being accessed (i.e., decrypted) by the user, which is why sending the file path along with the request to the mobile device is not sufficient:
- File paths on disk are not authenticated; someone without access to the data in Atakama could rename or move files.
- Atakama's security comes principally from the use of two or more devices, so users are unable to rely solely on the computer to "tell the truth" about the operation being performed.
For metadata to be useful therefore, it must be authenticated. Specifically, anyone should be able to verify the authenticity of the claimed metadata of a file, and the metadata should be modifiable only when the file is unlocked or following a MofNop. It is both acceptable and desirable for the user to be able to change the metadata in both of these scenarios because in both cases the user is able to access the file contents, which is precisely what Atakama is endeavoring to achieve with the authenticated metadata.
Authenticated metadata is implemented via cryptographic signatures. When Atakama encrypts a new file, the file receives a random asymmetric keypair. The private key is used to sign the initial metadata, and the signature can subsequently be verified against the public key, which is itself used in the decryption process. When renaming without access to cached keys, Atakama signs the new metadata for the file with a special key associated with the file’s storage location. This key is split among the user’s devices, meaning that the signature can only be completed with a MofNop.
Ultimately, the extra step of approving a file rename provides enormous security. Authenticated metadata is available and should be verified before approving the MofNop. If it’s not what the user expected, it's a red flag!