hardware full disk encryption

[Chris Murphy]

On Dec 12, 2013, at 12:32 PM, Wolfgang S. Rupprecht <wolfgang.rupprecht at gmail.com> wrote:

> 
> I've got a standard consumer Intel 520 SSD, which claims to do hardware
> based AES disk encryption with no speed penalty.  It sounds like a
> useful way to protect laptop data if the laptop is ever stolen.  Has
> anyone tried to do hardware-based full disk encryption with Fedora?

Yes, but I failed to really follow-up on whether we even have tools to do this, like if hdparm can communicate correctly with at least TCG OPAL compliant drives. This is just a few weeks old and seems the answer to that is no:

http://security.stackexchange.com/questions/45542/free-libre-software-to-handle-tcg-opal-2-0-compliant-self-encrypting-drives-sed

To boot from these drives it requires firmware that supports the specific implementation in order to communicate with the drive in this pre-boot environment. And it might even require a controller that supports this as well, and seems to require a TPM also. I wasn't able to get clarity on that either. Here is a SNIA + TCG doc that gets into some of this:

http://www.snia.org/sites/default/files/Cox-J_TCG_Trusted_Computing_Group_Storage_Spec.pdf

One challenge is to get the right keymaps set for boot and resume from hibernation, to make sure the passphrase the user thinks they're inputting is in fact what's being communicated to the drive. So some firmware support is necessary and probably also work in the kernel and I don't think any of that's done.

Also from the 520 spec sheet, I can't tell if it's OPAL compliant or not. The updated spec just says it supports AES 128 bit encryption rather than the original spec of 256 bit AES encryption. But is the implementation a totally proprietary thing? I can't tell, and in my research that was really common. Many drives purporting to be SEDs didn't explicitly say they were OPAL compliant, and that seems to be a minimum requirement - some kind of standard.

But per usual, the drive industry couldn't get their act together and agree on a single standard, or cross platform method to support these drives. So by the time they got around to OPAL, pretty much no one cared about it which is one reason why all the effort has been on hardware accelerated (via AES-NI) software solutions like dmcrypt, BitLocker, FileVault2, etc. And that's why there's still proprietary SED implementations floating around instead of universal OPAL.

> Does one need to boot from a live usb or something in order to get to an
> environment where one can even enter the AES key for the disk
> decryption?  

For booting, I think this is for now a total dead end, which is too bad. The work is being done regardless on these drives. They always encrypt, they just have the symmetric cryptographic key unencrypted therefore the drive is always unlocked and therefore always appearing to the world as not encrypted. But internally, it's always encrypted.

For a data drive, this is probably more practical to figure out but last time I check a year or so ago I didn't find any FOSS tools for OPAL compliant drives. And it was so annoying I can't say I did an exhaustive search, so I might have missed something.

> 
> Google is failing me here due to search spam for LUKS which doesn't
> appear to be capable of *full* *disk* encryption.  It only seems to
> encrypt individual partitions.

LUKS is a specification and a metadata format. What implements FDE on linux is dm-crypt, which can use plain or LUKS methods.

Whether dmcrypt is FDE sorta depends on how you define FDE. The widely accepted definition means encryption under the file system, rather than on top of it like file, folder, or vault encryption. Everything on the file system contained on the encrypted block device is encrypted.

For example you can use dm-crypt on an unpartitioned drive which effectively encrypts the entire physical drive. Using LUKS there is a metadata header at the start of the drive, which isn't encrypted. This isn't altogether different than how an SED functions, since it also has an plaintext portion that contains bootloaders, tools, and metadata for the encrypted portion of the drive. When the drive is locked, only the plaintext portion is visible. When the drive is unlocked (default behavior), a plaintext logical volume is presented as if it were the physical drive, while the ondisk content of this logical volume is of course ciphertext.

So just because not every single byte stored on a drive is ciphertext doesn't mean it's not FDE.


Chris Murphy