In Atakama, each protected file is individually encrypted with its own unique encryption key. This practice is vital to the security of your Atakama-encrypted files.
For example, say that you have one document named SensitiveClient.docx for your most important client and a file named OtherClient.docx for another client. You want to minimize the risk of data exposure for the sensitive client, so of course you only open that document when it’s actually necessary to do so. When you need to access OtherClient.docx, you double click on the file in the Atakama Folder and receive a request which is described as “File Authorization for OtherClient.docx.” Before you tap to approve, how do you know that you’re really decrypting this file, and not SensitiveClient.docx? What if someone swapped the underlying files? The answer lies in authenticated metadata.
Metadata, in this context, is the string of text identifying a given cryptographic object, such as a file. When using Atakama as a filesystem, it’s most natural for that metadata to simply be the path of the file within the Atakama folder. As described above, it’s important to know which file you’re actually decrypting — so just send the file path along with the request to the phone, right? Sadly, that simple approach is insufficient for two reasons:
File paths on disk are not authenticated; someone without access to the data in Atakama could rename or move files.
Because Atakama’s security principally comes from the use of 2 or more devices, we cannot rely on the computer alone to “tell the truth” about the operation being performed.
In order for metadata to be useful, it must be authenticated. Specifically, anyone should be able to verify the authenticity of the claimed metadata of a file, and that metadata should only be modifiable when the file is unlocked or by a secure action involving the cooperation of 2 or more devices. It’s acceptable — and desirable — for the user to be able to change the metadata in both of these scenarios because in either case the user could get access to the file contents anyway, and that’s precisely what we’re protecting with the authenticated metadata.
Under the hood, this is implemented via cryptographic signatures. When a new file is saved to the Atakama folder, it gets a random asymmetric keypair. The private key is used to sign the initial metadata, and this signature can later be verified against the public key, which is itself used in the decryption process. When renaming without access to cached keys, we sign 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 made with a secure action.
Ultimately, this extra step in the user’s workflow provides enormous security. Authenticated metadata is available and should be verified before tapping the green button — if it’s not what the user expected, that is a red flag.