7 Jan
2016
7 Jan
'16
4:03 p.m.
On Jan 7, 2016, at 3:52 PM, Mouse <mouse at
Rodents-Montreal.ORG> wrote:
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).
I don?t know if it?s typical or not, but every company that I?ve worked for that
has managed crypto-keys has taken key security *very* seriously. For example,
the key generating system (usually something custom) is kept in an ?air gapped?
vault (and I *do* mean vault). The vault can only be opened when two authorized
individuals are present (ie neither one can get into the vault without the other).
Everything is tracked and audited on a regular basis.
One big semi-conductor company does it this way (I have personal knowledge).
I also helped set up this type of crypo-key management for one of the startups I
worked for once upon a time (even to the point where they crypto-key hardware
would ?self destruct? if tampered with?sorry no sparks, smoke or other visual
aids?it just erased itself).
TTFN - Guy
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$