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.).
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 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 .vida file extension, may be designated by the user either during First-time Setup or at any time through the Settings page. 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, Google Drive and Microsoft OneDrive.
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.
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 Settings page on their workstation.
Users also have the option during the onboarding process or at any time in the Settings page 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, Google Drive, and Microsoft OneDrive. 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.