Duncan Campbell sends along with permission of Andrew:
Additional comment from Andrew D. Fernandes of Cryptonym
Corporation (who discovered the NSA_KEY) on the MS/Campbell
exchange on the NSA_KEY <http://cryptome.org/nsakey-ms-dc.htm>:
Microsoft's insistence that the second key is there for backup
purposes is not a satisfying explanation for a number of reasons.
The reason that the arguments are not satisfying is clear if you
have experience using dedicated tamper-resistant crypto-boxes.
A dedicated crypto-box internally generates a key pair, exports
the public key, and then digitally signs designated input whenever
properly prompted. These boxes are specifically designed to
NEVER export the private key as plaintext. Furthermore, these
boxes are designed to destroy their private key if the box detects
any attempted physical tampering.
The danger with a crypto-box is not only the potential compromise
of the private key. An almost as great danger is the loss of the
private key! Consider that a disgruntled employee could destroy
the private key by merely hitting the crypto-box, sticking a paperclip
into an input port, or dropping an ice cube on the box... (no, I'm not
making up the ice cube part - these boxes are usually temperature
sensitive). What you would have is a very ready denial-of-service
attack.
Therefore, almost universally, crypto-boxes allow the export of the
private key in encrypted format. A good crypto-box will even use
advanced cryptographic techniques called "secret splitting" to split
the encrypted key into several different parts - one part for each
senior manager. That way, if the crypto-box is lost or destroyed, a
new crypto-box can be quickly initialized and utilized.
It is possible that Microsoft's CSP team has a crypto-box that will not
export the private key even if it is in encrypted or secret-split format.
If that is true, it would be natural to assume a second backup key
would be necessary. However, look at this scenario in terms of
"failure analysis", where the security of the CSP scheme fails if a
signing key is lost.
There are two signing keys that can load a CSP. If the first key is
lost, Microsoft could rely on using the second key. If the second
key is lost, then Microsoft is out of luck, and must patch or upgrade
every copy of Windows in the world, as well as every CSP it has
ever signed, all because they did not buy a crypto-box capable
of data recovery.
Call me draconian, but given the extraordinarily high level of
cryptographic expertise that Microsoft employs, I would fire the
design team that presented a CSP signing system based on a
single backup, rather than data recovery.
So it is rather strange that the CSP signing key (labeled "_KEY")
has backup key at all... even more strange that it would be labeled
"_NSAKEY".
In fact, there is no specific requirement in the BXA's EAR that
backup keys exist. That document draws heavily on the
Wassenaar Arrangement on the export of dual-use goods
(http://www.wassenaar.org/) for its wording and substance.
-----
