In Atakama, each protected file is individually encrypted. This practice is vital to the security that Atakama provides, because only the files which are actively in use are exposed on the user’s computer.

Say for example that you have one document per client, including SensitiveClient.docx for your most important client and OtherClient.docx for another. 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:

1. File paths on disk are not authenticated; someone without access to the data in Atakama could rename or move files.
2. Since 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 since 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 has a few important implications for Atakama users. First, authenticated metadata is available and should be verified before tapping the green button —  if it’s not what’s expected, that should be a red flag. It’s possible for users to inadvertently make metadata incorrect by, for example, renaming a .kama file directly in the Google Drive app. For that reason, it’s important to only use the Atakama Folder and other supported interfaces when performing these operations. When doing so, users will need to approve Secure Actions on their phones to proceed with the rename. It’s an extra step in the user’s workflow, but one that provides enormous security.

Request a demo to learn more about Atakama's Encryption and how Atakama can keep your critical data safe.