Atakama is a data privacy and security solution that leverages advanced encryption technologies as well as the processing power of your computer and your mobile devices together to safely and securely protect your data better than any single device could by itself.
Files protected by Atakama are encrypted using the AES-256 standard. A unique private key (a file based on a random number that acts like a strong password) is generated for each file which Atakama splits into smaller pieces, each of which are also encrypted before being distributed across more than one physical device that you trust, such as your smartphone or tablet. A trusted device can also belong to colleagues, close friends, or family members.
As a result of Atakama managing keys in this fashion, hackers and malware are unable to access files protected by Atakama without having both physical and digital access to your devices.
Instead of requiring a password when opening a file encrypted by Atakama, an approval request is pushed to your trusted devices. A simple tap of the "Approve" button in the Atakama mobile app securely transmits the piece of the requested file's key stored on that device back to your computer. Atakama then recombines the key from its pieces, decrypts, and opens the file. This entire process takes place instantly.
No. 2-Factor Authentication is simply a method of strengthening a log-in process by requiring a second type of password. It has no impact on the way data is protected within a system that uses it.
Like many modern platforms and services, Atakama relies on using mobile devices in conjunction with a computer but that's where the similarities end.
The Atakama system architecture ensures that you, and only you, are able to view and access the data you protect with Atakama. There are no back doors for remote access or administration of any kind, even for us.
Atakama is built with common-sense precautions that do not impact security in the event a device ever becomes lost, inoperable, or compromised. However, if you do not follow our best practices and precautions, you will indeed be at risk of losing access to your encrypted data!
When you set Atakama up for the first time, you’ll be prompted to add spare keys, including a set of unique offline recovery words. You can use the spare keys to regain access to your protected data in the event you're unable to use your primary device.
As part of your personal Atakama configuration, you can add as many spare keys as you'd like, included trusted friends, family members, and colleagues as spare key holders. The more spare keys you have the less likely you are to ever lose access to your encrypted data.
Yes. In fact, we recommend using Atakama with a cloud storage service for increased protection and ultimate data privacy. Atakama currently integrates with Box, Dropbox, and Google Drive.
We built Atakama to work with as many platforms as possible. Atakama for desktop and laptop computers is compatible with Windows, macOS, and Linux and the Atakama Mobile app is available for both Android and iOS. You can mix and match any combination of devices and operating systems.
Yes! In fact, the more devices you link together with Atakama, the better protected your data becomes.
We named Atakama - Ah-tah-kah-mah - after the Atacama Desert in Chile. Although the Atacama Desert is seemingly void of activity, upon closer inspection it is one of the most unique and beautiful places on Earth. In a similar vein to the Atacama Desert, our encryption solution is unique among cybersecurity offerings and beautiful in its simplicity. By preventing unauthorized access to data, to the bad guys Atakama is a digital desert.
Atakama enables the encryption of files without reliance on usernames and passwords. Atakama runs locally on an individual user’s workstation (Linux, Mac, Windows). Once installed on the workstation, Atakama creates a new mount point behind which runs a virtual file system. Each file saved to this location is automatically encrypted using AES with a 256 bit key. The unique key is then automatically fragmented into “key shards”. The key shards are each separately encrypted using elliptic curve integrated encryption and distributed through Atakama's relay server to at least one more physical device (smartphone, tablet, secondary workstation, etc.) linked to the user’s primary workstation.
When a user needs to access a file, the Atakama Mobile application running on the user’s mobile device(s) will prompt the user to approve the access request. Upon approval, the key shard stored on the linked device is securely transmitted back to the user’s workstation for reassembly of the complete key followed by decryption of the requested file.
By default, Atakama uses AES-256 bit encryption for file level encryption and the SECP256K1 curve based ECIES for the encryption of key shards. The choice of curve allows for higher speed operations while maintaining at-rest security.
Learn more about how Atakama secures fragmented encryption keys
Learn more about the Atakama Virtual File System
Once they are generated as part of Atakama's file encryption process, key shards are each encrypted with an elliptic curve public key before being delivered automatically through Atakama's relay network to the user’s physical devices.
Atakama makes use of a secure mechanism for fragmenting key shards known as “Verifiable Secret Sharing” which has been extensively reviewed in academic and professional literature. Atakama uses elliptic curve cryptography, rather than large primes, for the public commitment portion of this mechanism.
For example, one key shard is saved to the user’s workstation and another to the user’s mobile device where it is managed by the Atakama Mobile app. Any remaining key shards are encrypted and saved to any other devices that the user may be using, such as the user’s tablet, another computer, or the mobile device of another person designated by the user (e.g., friend, relative, significant other, colleague, etc.).
Learn more about Device Linking
The size of a key shard is less than 500 bytes. For example, 100,000 key shards would require less than 50 megabytes of storage space on a user’s mobile device. Each shard is encrypted with the public key of the device on which the respective shard is stored. Decrypting and opening files is nearly instantaneous to the user as the time it takes to reassemble key shards is on the order of a millisecond.
Private keys for devices are stored using the device’s keychain and/or hardware element if available:
- On Windows, Atakama uses the PasswordVault class within the Windows.Security.Credentials API
- On macOS, Atakama makes use of Apple Keychain Services
- On mobile devices, if a secure element exists and supports AES-256 then the secure element is used for key storage
On desktop devices, keys are by default wiped from RAM within 15 minutes of use, but this value is configurable. On mobile devices RAM wiping is not comprehensive, however, if a secure element is used then private keys never enter main RAM.
As with many virtual file systems (VFS), Atakama's VFS provides the interface between the kernel and the user’s encrypted files. The Atakama VFS manages the creation, distribution and reassembly of the encryption key for each file stored.
The file system layer is built on FUSE -- Filesystem in Userspace. On Windows systems, WinFSP is used. By using a filesystem in this manner, only the specific file requested by the user is decrypted leaving all other data fully encrypted. The specific file for which decryption was requested is routed directly to the relevant application.
Applications that generate temporary files, including Microsoft Office applications, will write their temporary data to the encrypted drive when working with files protected by Atakama, however some must be configured to do so.
On Windows, an Explorer shell is used to detect user actions, restrict insecure programs from accessing data, and wipe fragments of files, temporary data, and other portions of secure data that may be leaked onto the local system. It is possible that some applications may retain encrypted data in unanticipated ways. In particular, proprietary applications or those we have not audited may leak secret data.
Atakama can provide auditing tools and services to test the security of local user applications.
The location for all of the user’s Atakama-encrypted files, which contain a .kama file extension, may be designated by the user either during first-time setup or at any time through the Atakama Control Center on their computer. This location can be either a local or network drive.
In addition to protecting files stored locally on a user’s workstation, Atakama can sync protected data with select cloud service providers by leveraging their API. Atakama currently integrates with Box, Dropbox, and Google Drive.
Atakama's cloud integration enables users to keep all of their cloud-stored data encrypted at all times, thus never relying on a cloud provider’s security systems.
In addition to running locally on a user’s workstation, Atakama requires users to download the Atakama Mobile app to the devices they intend to use to approve the decryption of their files.
Atakama links devices to a workstation without a traditional account system reliant on a username/email and a password. Instead, users are asked to link the devices in their possession during first-time setup by scanning a QR code using the Atakama Mobile app. Additional options via SMS and URL sharing are also available. Users may also use these methods to link devices in the possession of trusted third-parties.
A number of techniques are used to secure the device linking process. First, the hash of a device’s public key is used to produce a set of English words that are displayed to the user at both endpoints, which is a visual confirmation of correctness. Additionally, a one-time key and public key hashes are both verified during linking.
Even with these measures, the most secure form of device linking is by QR code. A knowledgeable, targeted attacker with sufficient access to a user’s communications network may be able to execute a man-in-the-middle attack during linking by other methods. After linking, however, the user is fully secured.
When attempting to access a file, the user receives a notification on their linked mobile device. If the user authorizes the process, the mobile device sends the required key shard back to the workstation, enabling reassembly of the key and decryption of the file. Users may also request and open multiple files at once.
Access and authentication can be customized in two different ways:
Instead of having to authorize the decryption of each file, users can choose to begin a “session” that is defined by a maximum number of files and time (e.g., 50 files and 2 hours). During the session, users need not authorize the decryption of files individually. Instead, when a user requests access to a file, their mobile device, without involving the user, sends the key shard for the specific file to the user’s workstation where the requested file is automatically decrypted. This is repeated until either the maximum number of files or time limit is reached, at which point Atakama will require the user to either initiate a new session or authorize on an individual basis each subsequent file being accessed.
Atakama does not require the reconstitution of all key shards in order to decrypt a file. As a result, users can customize the number of devices necessary to decrypt and access their encrypted Atakama files. This is achieved through the use of threshold cryptography to enable users to customize any “m of n” required device combinations (e.g., “2 of 3”, “2 of 4”, “3 of 5”, etc.).
We expect the most common arrangement to be a combination of 2 out of a total of 3 devices. In this scenario, a user would respond to file authorization requests on their primary mobile device and only rely on their tablet as a backup should the primary mobile device for any reason become inaccessible. A user’s workstation is always counted towards the required device threshold.
If a user does not have a third device, a virtual device is provided to the user in the form of “offline recovery words.” This is a set of 12 randomly selected English words that if invoked by the user are hashed by the system to become valid cryptographic data.
See Device Recovery for more information.
Users can optionally require additional mobile devices to decrypt and access their files. For example, in a “3 of 5” combination, the user would receive a notification on two linked devices when accessing a file. In such a scenario, authorizing the decryption process on only one of those two linked devices is insufficient to decrypt the file. That is because in a “3 of 5” scenario, 3 is the number of shards necessary to decrypt a file. The workstation plus one mobile device is only two devices, so the user would need to authorize the decryption process on one additional device before the file can be decrypted.
We expect devices will be lost, stolen, replaced and otherwise rendered inoperable. Users are able to remotely remove and replace a device through the Atakama Control Center on their computer.
Users also have the option during the setup process or at any time in the Control Center to generate a random set of “recovery words” that can be used to remotely remove and replace a lost, stolen, replaced, or inoperable device. The recovery words need to be transcribed to paper and secured by the user in a safe place. The words by themselves cannot be used to access any of the user’s Atakama-encrypted files.
Because Atakama does not rely on passwords or other personal credentials to access encrypted files, we recommend users link multiple backup devices to ensure that access to encrypted data is never lost. A “2 of 5” configuration, for example, is safer than a “2 of 3” configuration.
An example of a “2 of 5” configuration can include the user’s workstation, their primary mobile device, their tablet, a friend’s device and a family member’s device. The more backup devices included, the less likely the scenario of a user being unable to access their encrypted data. Backup devices on their own do not have access to files protected by Atakama.
A user’s devices must be able to communicate with each other in order to perform fundamental tasks such as the distribution of encryption key shards and the delivery of authorization requests and responses. In a general case, devices that are connected to the Internet can send messages to one another via Atakama's relay servers. A device establishes a WebSocket connection with a relay server that authenticates the identifier of the device and then accepts messages to be relayed to another device. Messages sent from one device to another are encrypted with the public key of the destination device to ensure the relay servers remain oblivious to message content beyond that which is necessary for successful delivery.
All communications are point-to-point encrypted between devices. At no time can an observer on the relay network or an observer listening to Bluetooth traffic obtain enough information to compromise the security of the overall system. Atakama retains no keys and has no ability to decrypt, restore or tamper with user data. An observer can determine that communication is happening, however, and an analysis could be used to determine, for example, times of day when data is more frequently being accessed.
When possible, a Bluetooth connection may be established between devices to supplement or replace use of the relay servers. In addition to reducing latency, this allows the system to be fully functional without access to the Internet.
Atakama allows for sharing of encrypted files through a shared storage location on a network or with cloud services including Box, Dropbox, and Google Drive. Assuming users have file system access to the same folder, Atakama will automatically detect the profiles of other Atakama users and enable sharing with them if such sharing is desired. After verifying a Atakama profile in a shared location, additional new files or changes to existing files will now include that profile.
Similar to network drives, Atakama can be configured to support file sharing in an Active Directory environment. Atakama respects existing file permissions governed by Active Directory and will automatically provide access to all authorized users when files are created or modified. In addition, Atakama allows administrators to enforce Atakama-specific policies via a control panel. One example of such a policy is the “minimum required devices” that would allow an administrator to create a requirement for all of their users to link a certain minimum number of devices to their profile in order to use Atakama.
Atakama's search feature allows users to search through their encrypted files without decrypting the files or exposing any information about the files, except for the fact that a particular file is itself responsive to a search term. To be able to search through encrypted files, Atakama creates an index for every file that it encrypts. The index is itself encrypted and appended to the encrypted file. Similar to the manner in which Atakama requires users to authorize the decryption of files, Atakama also requires users to authorize searches. When running a search, users enter their query in the Atakama search feature on their workstation and approve the query on their mobile device. The mobile device combines the search query with the encryption key shards for each encrypted file. The workstation then uses the resulting combined information to securely locate files that contain the search term.