Who is Locky For?

Organizations that store Social Security Numbers, Personal Photos, Text Messages, Electronic Health Records, Trade Secrets, and other sensitive data often follow a similar design pattern. This common pattern has a vulnerability which Locky solves for.

The Design Pattern

                                               
                                             __________
                                            |   DEK    |
                                     stores |  ______  |
            [Database]                 -->  | | Data | |
                |                           | |______| |
                |                           |__________|
                |                           
     ___________|______________              _________
    |           |              |            |   KEK   |
    |           |              |     stores |  _____  |
 [Server]    [Server]  ...  [Server]   -->  | | DEK | |
    |           |              |            | |_____| |
    |           |              |            |_________|
    |___________|______________|            
                |                           
                |                     stores   _____
          [Key Storage]                 -->   | KEK |
                                              |_____|

Sensitive data is stored in a relational, filesystem, or NoSQL database. It is encrypted with a symmetric algorithm like AES or ChaCha20, and the key is known as a DEK or "Data Encryption Key".

To avoid writing the DEK directly in configuration, when a server is provisioned the DEK is encrypted by another key, known as a "Key Encryption Key" or KEK. To utilize the DEK, the server must first decrypt it.

Decryption Process

The server decrypts the DEK by sending it, encrypted, to a Key Management Service (along with some auth). It then receives a decrypted DEK from the Key Management Service. The Server then uses this DEK, in memory, to interact with the database.

A popular variation includes storing the encrypted DEK within key storage, like if using AWS Secrets Manager. The server then requests the DEK by name from the Key Storage. This variation has the same considerations.

The Vulnerability

The vulnerability lies in the fact that encrypted communication between the Servers and Key Storage can be intercepted and stored by an attacker. While AES and ChaCha20 are resistant against quantum attacks, in this model a quantum attack can reveal the DEK when it is sent from the Key Storage to the Server, rendering the encryption ineffective. Any systems using the above pattern are vulnerable to a Harvest-Now Decrypt-Later attack. An attacker can save traffic between the Key Storage and Servers and use it to decrypt traffic with the database.

Can't we worry about this in 10 years?

Quantum computers are not powerful enough today to break encryption. Is it OK to wait until they are powerful before we close this gap? Well, that depends on the data.

Credit cards generally expire within 10 years and passwords are rotated. However, a person cannot change their medical records, text messages, or browser history. Companies cannot change their trade secrets or intellectual property. Any data that still has value in 10 years is vulnerable to having traffic saved today with the intent to decrypt it later.

How Locky Solves The Issue

Locky is a Key Management System that can store and transmit 256-bit secrets to servers in a post-quantum-secure manner. An adversary that records traffic between the Servers and Key Storage cannot later use quantum computers to retrieve the DEK.