This file is available on a Cryptome DVD offered by Cryptome. Donate $25 for a DVD of the Cryptome 10-year archives of 35,000 files from June 1996 to June 2006 (~3.5 GB). Click Paypal or mail check/MO made out to John Young, 251 West 89th Street, New York, NY 10024. Archives include all files of cryptome.org, cryptome2.org, jya.com, cartome.org, eyeball-series.org and iraq-kill-maim.org. Cryptome offers with the Cryptome DVD an INSCOM DVD of about 18,000 pages of counter-intelligence dossiers declassified by the US Army Information and Security Command, dating from 1945 to 1985. No additional contribution required -- $25 for both. The DVDs will be sent anywhere worldwide without extra cost.

26 May 2000
Source: Duncan Campbell

Duncan Campbell: Additional comment from Andrew D. Fernandes of Cryptonym Corporation (who discovered the NSA_KEY) on the Microsoft/Duncan Campbell exchanges about 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.