KMS in the Cloud

As a part of our work on new Key Management System (KMS) for rclone, it was more than appropriate to look for prior art. There are well-tested cryptosystems providing file encryption for file systems built on top of block devices. However it has turned out that these systems offer little to no inspiration for an object storage systems encryption.

Although the basic requirements are relatively modest, some basic use-cases have to be covered when implementing a encrypted storage solution. For multi-user access the necessary features of its KMS are:

• key addition - when new user needs to be granted access,
• key revocation - when a user should no longer access the data.

An important aspect of any research like this is check for any prior art as nobody really wants to reinvent the wheel. One class of prior art solutions in this matter would be block storage encryption systems:

• LUKS - Linux Unified Key Setup
• BitLocker
• CGD - CryptoGraphic Device (NetBSD)

File-backed encrypted containers such as VeraCrypt supports are also a good example. For our analysis we used LUKS as the primary target and then checked any differences of the other systems. So how does LUKS perform its key management and what can it offer?

LUKS header section contains two headers - each containing binary and JSON part - and a keyslots area with the actual encrypted keys. There are parts of the header data structures dealing with volume identification, checksums, encryption configuration and others, however we are mostly interested in how the actual encryption keys for the data are stored, managed and protected.

The main problem is that all encryption keys for the actual data are protected using symmetric cipher with a symmetric key derived from one or more of the following sources:

• passphrase
• external token
• file contents

In the end a specified digest is computed from the source(s) which is then used as a key for decrypting the keyslot with the actual data encryption key. If this fails, other slots may be tried and when no more keyslots are remaining given LUKS volume cannot be decrypted using the provided source data.

Although in general this is a good choice if the users use combination of strong passphrase and one of the other choices. However if the user uses just a weak password a brute-force attack is possible. A weak password with other mechanism is actually relatively good choice. And what if the attacker gets their hands on the key derived from these sources? In such case no further knowledge is necessary to unlock given keyslot.

As there always will be users opting for weak passwords, in a networked environment with keyring containing keyslot for each and every member of the team the probability of a brute force attack suddently becomes one.

Funnily enough BitLocker and other systems suffer the same problems when multiple parties must be able to work with all the keyslots.

The main take-away from this survey is that a new approach will be needed to support a full-blown KMS in a cloud object storage system.

What it should support and how can those features be achieved? That is definitely a good question which we will try to address now.

See ya next time for more KMS design news!