On Dec 12, 2013, at 12:32 PM, Wolfgang S. Rupprecht <wolfgang.rupprecht(a)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-...
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...
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