_NSAKEY is a variable name discovered in
Windows NT4 Service Pack 5 (which had been released unstripped of its symbolic debugging data) in August 1999by Andrew D. Fernandes of Cryptonym Corporation. That variable contained a 1024-bit public key.
Microsoft's operating systems require all cryptography suites that can go into its operating systems to have a digital signature. When only Microsoft-approved cryptography suites can be used, complying with the Export Administration Regulations(EAR) of the US Department of Commerce, Bureau of Export Administration(BXA) (now known as the Bureau of Industry and Security or BIS) is easier. It was already known that Microsoft uses two keys, a primary and a spare, either of which can create valid signatures. The primary key is stored in the variable _KEY; Fernandes had discovered the second key.
Fernandes published his discovery, touching off a flurry of speculation and development of numerous conspiracy theories. If the private half of that key were actually owned by the United States
National Security Agency, the NSA (as suggested by the name), it would allow that intelligence agency to subvert any Windows users' security.
In addition, Windows 2000 had a third key with an unknown purpose, found by Dr. Nicko van Someren. [cite web |title=Microsoft, the NSA, and You |publisher=Cryptonym |date=1999-08-31 |url=http://web.archive.org/web/20000617094917/http://www.cryptonym.com/hottopics/msft-nsa/msft-nsa.html |accessdate=2007-01-07 (
Internet Archive/ Wayback Machine)] Microsoft claims this is only in beta builds of Windows 2000 and that its use was for signing Cryptographic Service Providers. [cite web |title=There is no "Back Door" in Windows |publisher=Microsoft |date=1999-09-07 |url=http://www.microsoft.com/technet/archive/security/news/backdoor.mspx?mfr=true |accessdate=2007-01-07] It did not have any clear purposes according to van Someren, [cite web |title=How NSA access was built into Windows |publisher=Heise |date=1999-01-04 |url=http://www.heise.de/tp/r4/artikel/5/5263/1.html |accessdate=2007-01-07] and it is unclear whether it is present in final builds or just beta builds. ( [http://web.archive.org/web/20061124104925/www.microsoft.com/technet/archive/security/news/backdoor.mspx There is no 'Back Door' in Windows] conflicts with [http://web.archive.org/web/20000816181539/http://www.cryptonym.com/hottopics/msft-nsa/msft-nsa.html Microsoft, the NSA, and You] and [http://www.heise.de/tp/r4/artikel/5/5263/1.html How NSA access was built into Windows] )
Microsoft, however, denied all such suggestions. "This report is inaccurate and unfounded. The key in question is a Microsoft key. It is maintained and safeguarded by Microsoft, and we have not shared this key with the NSA or any other party." [cite press release|title=Microsoft Says Speculation About Security and NSA Is "Inaccurate and Unfounded"|publisher=Microsoft Corp.|date=1999-09-03|url=http://www.microsoft.com/presspass/press/1999/sept99/rsapr.mspx|accessdate=2006-11-09] The key's symbol was "_NSAKEY" because the NSA is the technical review authority for U.S. export controls, and the key ensures compliance with U.S. export laws.
The Computers, Freedom and Privacy 2000 (CFP2000) conference was held from 4-
7 April 2000in Toronto, Canada. During a presentation to that conference, Duncan Campbell, Senior Research Fellow at the Electronic Privacy Information Center(EPIC), mentioned the _NSAKEY controversy as an example of an outstanding issue related to security and surveillance.
Richard Purcell, Microsoft’s Director of Corporate Privacy, approached Campbell after his presentation and expressed a wish to clear up the confusion and doubts about _NSAKEY. Immediately after the conference, Scott Culp, of the Microsoft Security Response Center, contacted Campbell and offered to answer his questions. Their correspondence began cordially but soon became strained; Campbell apparently felt Culp was being evasive and Culp apparently felt that Campbell was hostilely repeating questions that he had already answered. On
28 April 2000, Culp stated that "we have definitely reached the end of this discussion ... [which] is rapidly spiraling into the realm of conspiracy theory" [cite web |title=The Culp-Campbell correspondence (Microsoft Stonewalls _NSAkey Questions) |publisher=Cryptome |date=2000-05-25 |url=http://cryptome.org/nsakey-ms-dc.htm |accessdate=2006-11-27] and Campbell's further enquiries went unanswered.
Explanations from other sources
After a great deal of discussion featuring wildly varying levels of cryptographic expertise, various conclusions have been presented. To begin with, some observers, including Fernandes, doubt the BXA's EAR have specific requirements for backup keys. However, none of the commentators claim the legal expertise necessary to authoritatively discuss that document.
Microsoft insists that the second key is present as a backup to guard against the possibility of losing the primary secret key. Fernandes and
Bruce Schneierboth doubt this explanation, pointing out that the generally accepted way to guard against loss of a secret key is secret splitting, which would divide the key into several different parts, which would then be distributed throughout senior management. [cite web |title=Analysis by Bruce Schneier |publisher=Counterpane |date=1999-09-15 |url=http://www.schneier.com/crypto-gram-9909.html#NSAKeyinMicrosoftCryptoAPI |accessdate=2007-01-07] Such a plan would be far more robust than simply using two keys; if the second key is also lost, Microsoft would need to patch or upgrade every copy of Windows in the world, as well as every cryptographic module it has ever signed.
On the other hand, if Microsoft failed to think about the consequences of key loss and created a first key without using
secret splitting(and did so in secure hardware which doesn't allow protection to be weakened after key generation), and the NSApointed out the problem as part of the review process, it might explain both why Microsoft weakened their scheme with a second key and why the new one was called _NSAKEY. (The second key might be backed up using secret splitting, so losing both keys needn't be a problem.)
Another line of speculation concludes that Microsoft included a second key to be able to sign cryptographic modules outside the United States, while still complying with the BXA's EAR. If cryptographic modules were to be signed in multiple locations, using multiple keys is a reasonable approach. However, no cryptographic module has ever been found to be signed by _NSAKEY and Microsoft denies that any other certification authority exists.
A third possibility is that the _NSAKEY enables the NSA or other agencies to sign their own cryptographic modules without being required to disclose those modules to Microsoft, which would allow them to create modules in-house that implement classified algorithms. Of course this capability would also enable an agency to sign modules that could be used to undermine the security of any Windows installation. Such speculation is usually followed by cynical comments on such undermining not being difficult even without access to the cryptographic API.Fact|date=August 2007
Microsoft denies that the NSA has access to the _NSAKEY secret key.
The key is still present in all versions of Windows, though it has beenrenamed "_KEY2."
It is possible to remove the second, _NSAKEY using the following:
There is good news among the bad, however. It turns out that there is a flawin the way the "crypto_verify" function is implemented. Because of the way thecrypto verification occurs, users can easily eliminate or replace the NSA keyfrom the operating system without modifying any of Microsoft's originalcomponents. Since the NSA key is easily replaced, it means that non-UScompanies are free to install "strong" crypto services into Windows, withoutMicrosoft's or the NSA's approval. Thus the NSA has effectively removed exportcontrol of "strong" crypto from Windows. A demonstration program that replacesthe NSA key can be found on Cryptonym's website. [cite web |title=Microsoft, the NSA, and You |publisher=Cryptonym |date=1999-08-31 |url=http://web.archive.org/web/20001109204800/http://www.cryptonym.com/hottopics/msft-nsa/msft-nsa.html |accessdate=2007-01-07 (
Internet Archive/ Wayback Machine)]
CAPI Signature Public Keys as PGP Keys
1999, an anonymous researcher reverse-engineered both theprimary key and the _NSAKEY into PGP-compatible format and published themto the key servers. [cite web |title=The reverse-engineered keys |publisher=Cypherspace |date=1999-09-06 |url=http://cypherspace.org/adam/hacks/ms-nsa-key.html |accessdate=2007-01-07]
Microsoft's Primary (_KEY variable) CAPI Signature KeyType Bits/KeyID Date User ID pub 1024/346B5095 1999/09/06 Microsoft's CAPI key
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCPAzfTc8YAAAEEALJz4nepw3XHC7dJPlKws2li6XZiatYJujG+asysEvHz2mwY 2WlRggxFfHtMSJO9FJ3ieaOfbskm01RNs0kfoumvG/gmCzsPut1py9d7KAEpJXEb F8C4d+r32p0C3V+FcoVOXJDpsQz7rq+Lj+HfUEe8GIKaUxSZu/SegCE0a1CVABEB AAG0L01pY3Jvc29mdCdzIENBUEkga2V5IDxwb3N0bWFzdGVyQG1pY3Jvc29mdC5j b20+iQEVAwUQN9Nz5j57yqgoskVRAQFr/gf8DGm1hAxWBmx/0bl4m0metM+IM39J yI5mub0ie1HRLExP7lVJezBTyRryV3tDv6U3OIP+KZDthdXb0fmGU5z+wHt34Uzu xl6Q7m7oB76SKfNaWgosZxqkE5YQrXXGsn3oVZhV6yBALekWtsdVaSmG8+IJNx+n NvMTYRUz+MdrRFcEFDhFntblI8NlQenlX6CcnnfOkdR7ZKyPbVoSXW/Z6q7U9REJ TSjBT0swYbHX+3EVt8n2nwxWb2ouNmnm9H2gYfXHikhXrwtjK2aG/3J7k6EVxS+m Rp+crFOB32sTO1ib2sr7GY7CZUwOpDqRxo8KmQZyhaZqz1x6myurXyw3Tg=
=ms8C -----END PGP PUBLIC KEY BLOCK-----
Microsoft's Secondary (_NSAKEY variable, now _KEY2) CAPI Signature Key
Type Bits/KeyID Date User ID pub 1024/51682D1F 1999/09/06 NSA's Microsoft CAPI key
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCPAzfTdH0AAAEEALqOFf7jzRYPtHz5PitNhCYVryPwZZJk2B7cNaJ9OqRQiQoi e1YdpAH/OQh3HSQ/butPnjUZdukPB/0izQmczXHoW5f1Q5rbFy0y1xy2bCbFsYij 4ReQ7QHrMb8nvGZ7OW/YKDCX2LOGnMdRGjSW6CmjK7rW0veqfoypgF1RaC0fABEB AAG0LU5TQSdzIE1pY3Jvc29mdCBDQVBJIGtleSA8cG9zdG1hc3RlckBuc2EuZ292 PokBFQMFEDfTdJE+e8qoKLJFUQEBHnsH/ihUe7oq6DhU1dJjvXWcYw6p1iW+0euR YfZjwpzPotQ8m5rC7FrJDUbgqQjoFDr++zN9kD9bjNPVUx/ZjCvSFTNu/5X1qn1r it7IHU/6Aem1h4Bs6KE5MPpjKRxRkqQjbW4f0cgXg6+LV+V9cNMylZHRef3PZCQa 5DOI5crQ0IWyjQCt9br07BL9C3X5WHNNRsRIr9WiVfPK8eyxhNYl/NiH2GzXYbNe UWjaS2KuJNVvozjxGymcnNTwJltZK4RLZxo05FW2InJbtEfMc+m823vVltm9l/f+ n2iYBAaDs6I/0v2AcVKNy19Cjncc3wQZkaiIYqfPZL19kT8vDNGi9uE= =PhHT -----END PGP PUBLIC KEY BLOCK-----
Trusted Computer System Evaluation Criteria
Wikimedia Foundation. 2010.