>> 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