Technical Overview

Looking for our FAQ?
  1. General Overview
  2. Secure Key Fragmentation
  3. Key Storage & Management
  4. Mount Point / Virtual File System
  5. Back-end Data Storage & Cloud Integration
  6. Device Linking
  7. Access & Authentication
  8. Device Recovery & Backup Devices
  9. Data Transfer Between Devices
  10. File Sharing
  11. Active Directory Integration
  12. Searching Through Encrypted Data

1. General Overview

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

2. Secure Key Fragmentation

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

3. Key Storage & Management

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.

4. Mount Point / Virtual File System

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.

5. Back-end Data Storage & Cloud Integration

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.

6. Device Linking

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.

7. Access & Authentication

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.

8. Device Recovery & Backup Devices

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.

9. Data Transfer Between Devices

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.

10. File Sharing

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.

11. Active Directory Integration

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 is coming soon and we can't wait to share it with you.

Ready to try Atakama?
Time is running out to join our preview program - apply today!

Have questions?
Contact us

Apply to join the Atakama Preview Program

Thanks for your interest in Atakama!  We'll let you know as soon as it's ready.

Check your inbox (and spam folder) to make sure you received our messages.
Oops! Something went wrong while submitting the form.