I'm afraid I don't find Mr. Fernandes' argument convincing. Given the
nature of the Microsoft CAPI concept -- that only approved
cryptographic modules can be allowed to run -- NSA would surely want
to know how use of the CAPI signing key was ultimately controlled. A
crypto box that allowed export of private keys, even in encrypted
form, begs that question. One then has to ask who controls the export
keys? It is entirely believable that NSA insisted on the CAPI key
being stored in a token that specifically did not allow key export.
Microsoft might then have raised the backup question and NSA would
have responded by suggesting a second token and key. That would
explain the programmer calling it _NSAKEY.
It is true that if both tokens are damaged then Microsoft has to
issue a patch, but service packs come out all the time. There would
not be a need to resign existing modules, however, as the old public
keys could continue to be included in the OS.
To me the mystery is why Microsoft is unwilling to fully explain its
actions. Perhaps there are other details they do not wish to reveal.
For example, since each CAPI module to be signed would require BXA
approval beforehand, NSA may have wanted the tokens kept at a trusted
third part, perhaps some law firm, giving BXA positive control over
what gets signed. Whatever the reason, the _NSAKEY incident
demonstrates that Microsoft has some secret relationship with NSA.
Arnold Reinhold
At 8:54 PM -0400 5/26/2000, John Young wrote:
>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.
>
>-----
