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? 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?
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.
-wolfgang
On Thu, Dec 12, 2013 at 11:32:41 -0800, "Wolfgang S. Rupprecht" wolfgang.rupprecht@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? 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?
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.
It can do full encryption of block devices. If you aren't booting of the SSD you could encrypt the whole drive. The luks header will still be on the SSD. If you didn't want that either, you could do some trickiness with dm to have the header on a different physical device. This is all going to need manual setup, as it isn't the normal case. (For most people leaking the partition information isn't a significant risk and encrypting by partition is simpler.)
Bruno Wolff III bruno@wolff.to writes:
On Thu, Dec 12, 2013 at 11:32:41 -0800, "Wolfgang S. Rupprecht" wolfgang.rupprecht@gmail.com wrote:
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.
It can do full encryption of block devices. If you aren't booting of the SSD you could encrypt the whole drive. The luks header will still be on the SSD. If you didn't want that either, you could do some trickiness with dm to have the header on a different physical device. This is all going to need manual setup, as it isn't the normal case. (For most people leaking the partition information isn't a significant risk and encrypting by partition is simpler.)
No, leaking the partition info for the bootstrap isn't a worry for me either. ;-) It's just that LUKS shows up and dominates searches for FDE. If I didn't have always on, hardware FDE for free in the SSD, I'm sure I'd be happy with LUKS.
After a bit more research it appears that the SSD FDE machinery is always on, even with a blank password protecting the internally generated random AES key. It is impressive that the disk does ~ 480 MBytes/sec (actual measured speed) even when squeezing all the data through AES-128.
Of course, with the Snowden revelations, one has to wonder how random the randomly chosen internal AES key is. If it is from an intentionally crippled RNG, it may be easy for someone in the know to do a brute-force search for it.
-wolfgang
On Thu, Dec 12, 2013 at 12:36:59 -0800, "Wolfgang S. Rupprecht" wolfgang.rupprecht@gmail.com wrote:
Of course, with the Snowden revelations, one has to wonder how random the randomly chosen internal AES key is. If it is from an intentionally crippled RNG, it may be easy for someone in the know to do a brute-force search for it.
It's not just deliberate stuff from the NSA but screwups as well. These kinds of things are often kept as proprietary secrets that don't get reviewed by someone that knows what they're doing. There is hardware for AES, so it isn't that surprising that encryption can keep up.
On Dec 12, 2013, at 1:36 PM, "Wolfgang S. Rupprecht" wolfgang.rupprecht@gmail.com wrote:
If I didn't have always on, hardware FDE for free in the SSD, I'm sure I'd be happy with LUKS.
Yes, it's annoying. But the task is also difficult to do correctly in a preboot environment. Arguably they got ahead of themselves and should have first come up with an open SDK so that at the least we could easily use the SED feature for data drives, rather than the much more complex case of booting from them.
After a bit more research it appears that the SSD FDE machinery is always on, even with a blank password protecting the internally generated random AES key.
The symmetric cryptographic key is not blank. It is a real key, the data is really encrypted on disk media. However by being unlocked by default means the symmetric cryptographic key isn't itself encrypted with an assymetric cryptographic key which in turn is protected by a user passphrase. Since it's not encrypted, and is available (unlocked) the drive always appears to be unencrypted.
Supposedly in the latest ATA spec, there is a new CRYPTO ERASE command that can be used to wipe that key, and would be essentially instantaneous wiping of the disk. A new key is generated immediately in place. This ought to be accessible even if you're not otherwise using, or able to use, the drive as an SED.
CRYPTO ERASE is part of the same ATA command set as SECURITY ERASE and ENHANCED SECURITY ERASE. Those last two commands cause the drive to erase itself, all physical sectors, one by one, even ones that don't have LBA mappings. It's quite a bit faster than writing zeros. Only one of those commands or fstrim is recommended for SSDs, not writing zeros. But from the current hdparm man page I'm not seeing an option to issue this command to drives that support it.
It is impressive that the disk does ~ 480 MBytes/sec (actual measured speed) even when squeezing all the data through AES-128.
ASIC's are bad ass. Thing is, with AES-NI you will get this same performance for maybe 2% CPU cost with dm-crypt+LUKS.
Of course, with the Snowden revelations, one has to wonder how random the randomly chosen internal AES key is. If it is from an intentionally crippled RNG, it may be easy for someone in the know to do a brute-force search for it.
Right, small problem. Insofar as I know, the user can't create the symmetric key, the drive does. However, I vaguely recall it's possible to drop the same public assymetric key on all of the drives, thereby encrypting the AES key with a key you control. But, if the AES key is compromised anyway, this makes zero difference.
Chris Murphy
Chris Murphy lists@colorremedies.com writes:
On Dec 12, 2013, at 1:36 PM, "Wolfgang S. Rupprecht" wolfgang.rupprecht@gmail.com wrote:
If I didn't have always on, hardware FDE for free in the SSD, I'm sure I'd be happy with LUKS.
Yes, it's annoying. But the task is also difficult to do correctly in a preboot environment. Arguably they got ahead of themselves and should have first come up with an open SDK so that at the least we could easily use the SED feature for data drives, rather than the much more complex case of booting from them.
Thanks for this and the previous reply. That gave me a good background and a bunch of new acronyms to google for. I found an interesting white paper by the Intel IT dept. They tried dogfooding their own SSD's and if I'm understanding things correctly, the boot-time bios hooks are sufficient to query the user for the disk password and unlock the SSD.
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/it-...
It also strikes me that one can set the ssd disk password at any time after OS installation. Since the disk contents are already encrypted and will continue to be encrypted by the same AES key, from the data's perspective nothing has changed.
CRYPTO ERASE is part of the same ATA command set as SECURITY ERASE and ENHANCED SECURITY ERASE. Those last two commands cause the drive to erase itself, all physical sectors, one by one, even ones that don't have LBA mappings. It's quite a bit faster than writing zeros. Only one of those commands or fstrim is recommended for SSDs, not writing zeros. But from the current hdparm man page I'm not seeing an option to issue this command to drives that support it.
I figured out how to do the SECURITY ERASE a while back. The biggest complication is that for most bioses the disk has to be connected to a pcie disk controller. All the mobo sata ports have their attached disks ata "frozen" by the bios as an "aid" to users of virus-ridden OS's. In the absence of a pcie sata controller, one must power cycle the SSD while the computer is up. (I forget if pulling the sata and replugging it is good enough. it might be.) This clears the "frozen" bit.
Then one does the following:
disk=/dev/sdb pass=funkystuff
hdparm -I $disk echo 'Should say "not frozen"' hdparm --user-master u --security-set-pass $pass $disk || exit time hdparm --user-master u --security-erase $pass $disk hdparm --user-master u --security-disable $pass $disk hdparm -I $disk echo "should say 'not enabled'"
-wolfgang
On Dec 12, 2013, at 6:23 PM, Wolfgang S. Rupprecht wolfgang.rupprecht@gmail.com wrote:
It also strikes me that one can set the ssd disk password at any time after OS installation. Since the disk contents are already encrypted and will continue to be encrypted by the same AES key, from the data's perspective nothing has changed.
That's correct, but it requires platform specific user space tools to exist to access the unencrypted portion of the drive so that the encrypted AES key can be replaced.
Chris Murphy
On Dec 12, 2013, at 12:32 PM, Wolfgang S. Rupprecht wolfgang.rupprecht@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-han...
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_St...
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
-
Bruno Wolff III -
Chris Murphy -
Wolfgang S. Rupprecht