This article describes how Atakama protects your data. The core principles below guide our software development process. Understanding our core principles will help users get the most out of Atakama.
These core principles specifically apply to the protection of user data at rest.
Core Principles
Multiple factors are used to protect data exposure (i.e., decryption of information).
Each individual file is encrypted such that the file can be accessed (i.e., decrypted) by one or more groups, each of which consists of multiple Keys and a threshold value (i.e., number of Keys).
- Data is only exposed given the consent of the threshold number of Keys in a group.
- Keys in separate groups, even when each group has its own access to the same data, cannot cooperate to induce data exposure. The threshold value must come from the same group.
- Consent of fewer than a threshold number of Keys in a group leaves data as protected as if no devices consented.
Data is individually protected.
- Each newly encrypted object (e.g. file) in Atakama is individually protected.
A given object can be decrypted without also exposing the contents of other objects. In other words, data that is not in use will remain encrypted at rest, from a cryptographic perspective.
Data is securely identified.
- When performing a MOFNOP to decrypt an object, the object is securely identified such that the user is confident that they are not exposing another, unintended object.
In practice, this is Authenticated Metadata. Note that choosing to use certain features, like Sessions, means forgoing the opportunity to identify the objects being exposed.
Data protection does not rely upon authentication or obfuscation.
The protection that Atakama provides is inherent to its cryptographic model and could not be thwarted by malicious software modification in a single factor.
- For decryption operations that involve using multiple factors, the use of the multiple factors is due to the actual need for the private cryptographic components owned by each factor.
- Data protection does not rely upon the assumption of an attacker’s lack of knowledge of the product’s implementation (obfuscation).
Practical Limitations & Best Practices
To maximize security and fully realize Atakama’s Core Principles, please consider the following practical limitations.
Data may have a life outside of Atakama.
When data is directly written to the Atakama Vault and then locked, no unencrypted data (plaintext) should remain. However, if that data already existed and was moved to Atakama, plaintext copies may persist in other locations.
For example, you might have a file saved to your desktop. You then encrypt the file with Atakama. While you may not be able to directly access the original file anymore, plaintext remnants may still remain on disk. This risk can be at least partially mitigated by the additional use of full disk encryption.
Third party applications can make copies of data.
When using a third party application (e.g. a PDF reader) to view or edit data in Atakama, that application could make copies of the unencrypted data. An application may do this, for example, for performance reasons and as part of an auto-save feature. This behavior is often configurable, so understanding what third party applications do with your data will help you mitigate this risk.