2

Is it possible to store the master decryption key for accessing a LUKS encrypted volume inside an SGX enclave so that the master key cannot be accessed by any user on the system, even the root user with privileges to make system calls?

Currently, LUKS necessarily has to store the master key in memory that's used to decrypt data stored on an encrypted volume. Therefore, the root user can not only access the drive's contents, but they can also access the drive's master key.

Intel SGX was designed to be able to create enclaves where a machine can run applications such that the host OS can't access the code or data executed inside the enclave.

Is it possible to exploit an SGX enclave in order to store the master key and decrypt the volume's contents such that the host OS can request decrypted data from a LUKS-encrypted volume via the decrypting process running in the enclave, but it cannot access the master key that's stored inside the enclave?

Michael Altfield
  • 826
  • 4
  • 19

1 Answers1

2

Here's how I understand LUKS works:

  • A LUKS volume is encrypted by a single key.
  • A LUKS volume has a number of keyslots.
  • Each keyslot stores an encrypted version of the key, protected by a (key derived from a) keyphrase.

Do you want to prevent access to:

  1. The key that's actually used to perform the disk encryption.
  2. The passphrases that are used to encrypt the keyslot.

... and what is your attack model; must the system boot autonomously without a user present to unlock the disk, or must some user/sysadmin still provide a passphrase to unlock the disk, so that the disk cannot be accessed after the entire system is stolen?

For 1 above:

The cryptographic operations that implement disk encryption in Linux are typically performed by the CPU itself, in software, in the kernel. In this case, the CPU must have access to the key in order to implement encryption, It is possible to implement kernel crypto drivers that perform the crypto operations, typically in a separate hardware device. You may be able to implement an SGX-based enclave and expose it to the kernel as a crypto driver, thus hiding the key inside the enclave. However, kernel crypto drivers run kernel mode, and I have not seen any way to launch SGX enclaves in kernel mode. That said, I think it's all just software, so with enough resources, you may be able to implement that. Alternatively, perhaps one could run the enclave in user-space, and implement something similar to FUSE/CUSE to allow the kernel to use that user-space application as the backend for a crypto driver.

For 2 above:

Since using the pass-phrase to derive the disk encryption key from the LUKS keyslot is a small self-contained operation, you could probably adapt the cryptsetup application to run that part of the code inside an SGX enclave. This would allow the crypto operations to occur without observation. However, the enclave would still need to obtain the passphrase for the keyslot from somewhere, which in practice means that the kernel has to pass it in somehow, and thus it could be stolen then. Of course, if you're able to set up a trusted (encrypted, etc.) channel between the SGX enclave and some form of trusted input device, so that the channel cannot be snooped or otherwise tampered with, you may be able to transfer the passphrase into the enclave without anything being able to see it.

I guess overall the simple answer is no. The answer may be yes with a significant amount of effort.

Stephen Warren
  • 246
  • 1
  • 6