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:
- The key that's actually used to perform the disk encryption.
- 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.