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