mouse at Rodents-Montreal.ORG
Thu Jan 7 17:52:01 CST 2016
>>> If you want data security and don't like destroying your hardware,
>>> SED ("sel$
>> You're assuming that the SED doesn't store an extra copy of the
>> decryption key in NVM or on the medium.
That was my initial reaction too!
>> Also, reverse-engineering has shown that at least some SEDs have
>> very bad crypto implementations.
I was not aware of that, but (and this is a depressing commentary on
_something_) it does not surprise me in the least.
>> 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.
> The key here is the use of signed firmware, which I believe is the normal pr$
That's hardly a fix; all it does is somewhat reduce the pool of people
who can create the compromised firmware. I don't trust the vendor's
internal security to keep the key from leaking and I don't trust the
vendor's HR security to prevent malware authors from making it to the
inside, and I *sure* don't trust the vendor to resist a request from
law enforcement for an easy-to-access backdoor (which will, of course,
promptly get abused, either by others or for other purposes).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
More information about the cctalk