Atakama is a data privacy and security solution that leverages advanced encryption technologies as well as the processing power of computers and mobile devices together to safely and securely protect data better than any single device could by itself.
Files protected by Atakama are encrypted using the AES-256 standard. For each file Atakama generates a unique private key (a file based on a random number that acts like a strong password) that is then split into smaller pieces, each of which are also encrypted before being distributed across at least two physical devices.
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 multiple devices of the same user.
Instead of requiring a password when opening a file encrypted by Atakama, an approval request is pushed to a mobile device. 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 the computer. Atakama then recombines the key from its pieces, decrypts, and opens the file. This entire process takes place instantly.
Atakama's UX is familiar to anyone who has used 2FA. But 2FA 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. Once you've been authenticated, you have access to everything.
Like many modern platforms and services, Atakama relies on using mobile devices in conjunction with a computer but that's where the similarities end.
Atakama takes full advantage of file-level encryption and keeps files secure at all times. When a user approves access to a specific file the remainder of the files remain encrypted.
The Atakama system architecture ensures that authorized Atakama users are the only ones who are able to view and access the protected data. 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.
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, Google Drive, and OneDrive.
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.
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. 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 a physical mobile device (i.e., smartphone) linked to the user’s primary workstation.
When a user needs to access a file, the Atakama app running on the user’s mobile device 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.
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 5 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 Atakama-encrypted files, which contain a .kama file extension, may be designated either during first-time setup or at any time through the Atakama Control Center. This location can be either local or network drive.
Atakama can also sync protected data with select cloud service providers by leveraging their API. Atakama currently integrates seamlessly with Box, Dropbox, Google Drive, and OneDrive, and can be configured to integrate with most any private and public cloud service.
Atakama's cloud integration enables cloud-stored data to remain 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 device (i.e., smartphone) they intend to use to approve the decryption of files.
Atakama links devices to workstations 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.
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 (specific to the file being accessed) 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, a policy can be set to allow users to begin a “session” that is defined by a maximum number of files and time (e.g., 50 files and 2 hours, 100 files and 8 hours, etc.). 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, custom policies designating the number of devices necessary to decrypt and access files can be set for specific files and folders. 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.). A user’s workstation is always counted towards the required device threshold.
For example, in a “3 of 5” combination, at least two users 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 a second mobile device would need to authorize the decryption process before the file can be decrypted.
We expect devices will be lost, stolen, replaced, and otherwise rendered inoperable. Devices can be remotely removed and replaced.
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 such as Box, Dropbox, Google Drive, and 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.
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.