What is authenticated metadata and why do users need to approve a file rename using Atakama?
Each file protected by Atakama is individually encrypted with its own unique encryption key. This practice is vital to the security of Atakama-encrypted files.
For example, there is one document named Taxes.docx and a second named FamilyPieRecipe.docx. Both of these 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 that on the Atakama Mobile app is described as either “File Authorization for Taxes.docx” or "File Authorization for FamilyPieRecipe.docx". If an adversary was able to access the location of these 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 for file renames.
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 decrypting — sending the file path along with the request to the mobile device is not sufficient for two reasons:
File paths on disk are not authenticated; someone without access to the data in Atakama could rename or move files.
Atakama’s security principally comes from the use of 2 or more devices, so users are unable to rely solely on the computer to “tell the truth” about the operation being performed.
In order 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 that metadata should be modifiable only when the file is unlocked or following a MofNop. It’s 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.