On Jan 7, 2016, at 3:33 PM, Eric Smith <spacewar at
gmail.com> wrote:
On Thu, Jan 7, 2016 at 1:17 PM, Paul Koning <paulkoning at comcast.net> wrote:
If you want data security and don't like
destroying your hardware, SED ("self-encrypting drives") are a solution. Those
encrypt all data, and "erase" by discarding and replacing the data encryption
key. So all your sectors instantly turn to random noise. SSD versions of those are
starting to appear, which addresses the invisible old copies problem that regular SSDs
have. The great thing of an SED is not just the security of its erase function, but in
particular the speed: it takes only seconds to destroy all the data on the drive.
You're assuming that the SED doesn't store an extra copy of the
decryption key in NVM or on the medium. IMO, that's a very naive
assumption. Also, reverse-engineering has shown that at least some
SEDs have very bad crypto implementations.
True. I know of at least one first generation SED that uses ECB mode. Anyone who has
looked at IEEE 802.11 knows that cryptographic competence is not common, and that some of
the people designing cryptosystems are not only unqualified to do so, but sufficiently
ignorant that the aren't even aware that they aren't qualified.
With SEDs as with any other security tool, one has to be sceptical and ask very pointed
questions. For example, with the SSD kind, I probed deeply into how the key is replaced
in a "crypto erase" operation, down to the level of the flash memory primitives
involved. The particular implementation I looked at had the correct answers.
Even if your SED doesn't have a back door or badly
implemented crypto,
you also have to worry about whether someone has managed to install
compromised firmware on it. People once thought that hacked drive
firmware was too difficult or expensive to develop for anyone other
than three-letter agencies, but that's been proven false.
The key here is the use of signed firmware, which I believe is the normal practice. With
that, it's not just a matter of reverse engineering, the attacker would also have to
steal the firmware signing key.
I'm OK with an SED being a component of the data
security solution,
but I'm not willing to count on it exclusively. I'll still run
software disk encryption. Preferably open-source software disk
encryption, so that the source code can be audited, though that's not
a guarantee either.
Agreed. I've been a TrueCrypt user ever since DriveCrypt went off track.
One might expect that simple security measures would
be enough as long
as the threat model you're concerned with isn't three-letter agencies.
Unfortunately any back doors or badly implemented crypto, whether
installed by TLAs or just through incompetence, are likely to be
exploited by many miscreants, not just TLAs.
If your threat model IS three-letter agencies, you're basically doomed
from the outset.
Maybe so. But you can definitely make things much harder, which is worth doing.
paul