Pocket Guide: Encryption at Rest

Idea

Encrypting data makes it readable only to the person or system which has the encryption key. It can be done in transit to protect the data from eavesdropping, or it can be done at rest. It is not obvious who does encryption at rest protect from, so let’s dig into that.

The data rest on several layers of application stack and each of these layer have their own access mechanism:

• Physical disk – can be accessed via Serial Advanced Technology Attachment (SATA)
• File system – can be accessed via Operating System (OS)
• Database system – can be accessed via file system (FS)
• Column – can be accessed via database (DB)
• Application – can be accessed via Application Program Interface (API)

Encryption at rest could be applied at any of these layers, meaning that data on the layers below it will be encrypted, unreadable for attackers. Data above the encryption layer will be in plain text, accessible to valid users.

It may well be possible that different layers are managed by different organisations. Using that model, we can say that:

• Disk-level encryption protects data from exposure via the disk interface. For example, it would prevent a rogue cloud provider employee from physically removing a disk from our server in the data center and reading the plaintext data via SATA interface.
• File-level encryption protects data from the scenario mentioned above, as well as from file-based exposure. If the encryption key is not stored on the file system, file system access will not be advantageous for attackers.
• Database-level encryption protects data from all the scenarios mentioned above and is applied to fewer files, thus reducing the attack surface.
• Column-level encryption protects data from all the scenarios mentioned above, plus it protects from rogue database administrators.
• Application-level encryption offers the strongest protection, safeguarding data from all the scenarios mentioned above, as well as from a complete compromise of the database operating system.

Application examples

AWS CMK and GCP CMEK are applied at the disk or database layers.

Risks

Protecting the encryption key is a paramount. If the key is compromised, then only data access controls stand between the attacker and the data.

Common oversight is storing the encryption key alongside the data. That creates the illusion of safety, but does little for real security.

The encryption key should be periodically changed to minimise the window of opportunity for the attackers. That also minimises the amount of data which could be exposed due to a key compromise. Though this is considered an industry best practice security control – I don’t believe in it. It is hard to imagine a single key compromise, most likely the whole encryption mechanism would be compromised.

For example, on January 1999, researchers broke DES algorithm. Key rotation wouldn’t have helped, but a stronger encryption algorithm would. That is why it’s important to stay on the top of cryptography developments and employ stronger algorithms as soon as they become publicly available. Developing your own encryption algorithm is inadvisable due to complexity of the cryptoanalysis field.

Quirks

It is amazing how often encryption at rest is considered as a binary “Yes/No” tick-box. Just by reading this article you realise that not all encryptions at rests are created equal, and the overall security of a solution depends on how and where it is implemented. In this article I detail the cloud examples of that.

Hashing is not the same as encryption. Hashing is irreversible, one-way cryptographic translation of the data and it does not require keys. It is designed in such way that the same data yields the same hash value, so it is still useful for comparison. For example, we can compare the currently supplied and agreed passwords, even though we cannot tell what the actual passwords are! Magic! If the hashes the same – the user has supplied the correct password.

Further reading

Demystifying Encryption at Rest with Customer Managed Keys

Pocket Guide: Special data protection techniques

Please check out the map of cyber security controls below. It is simple yet awesome.