> On Jan 7, 2016, at 3:33 PM, Eric Smith <space...@gmail.com> wrote:
>
> On Thu, Jan 7, 2016 at 1:17 PM, Paul Koning <paulkon...@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
