On Dec 12, 2013, at 1:36 PM, "Wolfgang S. Rupprecht" <wolfgang.rupprecht@xxxxxxxxx> 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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
