This article provides insufficient context for those unfamiliar with the subject.March 2018) (Learn how and when to remove this template message)(
In computer security and cryptography, _NSAKEY was a variable name discovered in Windows NT 4 Service Pack 5 (which had been released unstripped of its symbolic debugging data) in August 1999 by Andrew D. Fernandes of Cryptonym Corporation. That variable contained a 1024-bit public key.
Microsoft's operating systems require all cryptography suites that work with its operating systems to have a digital signature. Since only Microsoft-approved cryptography suites can be installed or used as a component of Windows, it is possible to keep export copies of this operating system (and products with Windows installed) in compliance with the Export Administration Regulations (EAR), which are enforced by the US Department of Commerce Bureau of Industry and Security (BIS).
It was already known that Microsoft used two keys, a primary and a spare, either of which can create valid signatures. Microsoft had failed to remove the debugging symbols in ADVAPI32.DLL, a security and encryption driver, when it released Service Pack 5 for Windows NT 4.0, and Andrew Fernandes, chief scientist with Cryptonym, found the primary key stored in the variable _KEY and the second key was labeled _NSAKEY. Fernandes published his discovery, touching off a flurry of speculation and conspiracy theories, including the possibility that the second key was owned by the United States National Security Agency (the NSA) and allowed the intelligence agency to subvert any Windows user's security.
During a presentation at the Computers, Freedom and Privacy 2000 (CFP2000) 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.
In addition, Dr. Nicko van Someren found a third key in Windows 2000, which he doubted had a legitimate purpose, and declared that "It looks more fishy".
Microsoft denied the speculations on _NSAKEY. "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." Microsoft said that 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.
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" and Campbell's further inquiries went unanswered.
http://web.archive.org/web/19990422142445/http://www.mozilla.org:80/crypto-faq.html says that "It is in fact possible under certain circumstances to obtain an export license for software invoking cryptographic functions through an API. For example, Microsoft's implementation of the Microsoft Cryptographic API (CryptoAPI) specification was approved for export from the US, even though it implements an API by which third parties, including third parties outside the US, can add separate modules ("Cryptographic Service Providers" or CSPs) implementing cryptographic functionality. This export approval was presumably made possible because a) the CryptoAPI implementation requires third party CSPs to be digitally signed by Microsoft and rejects attempts to call CSPs not so signed; b) through this signing process Microsoft can ensure compliance with the relevant US export control regulations (e.g., they presumably would not sign a CSP developed outside the US that implements strong cryptography); and c) Microsoft's CryptoAPI implementation is available only in executable form, and thus is presumed to be reasonably resistant to user tampering to disable the CSP digital signature check."
Explanations from other sources
Some in the software industry question whether the BXA's EAR has specific requirements for backup keys. However, none claim the legal or technical expertise necessary to authoritatively discuss that document. The following theories have been presented.
Microsoft stated that the second key is present as a backup to guard against the possibility of losing the primary secret key. Fernandes doubts 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. He stated that this would be far more robust than 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 had 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 NSA pointed out this problem as part of the review process, it might explain 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 possibility is 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.
Microsoft denied that the NSA has access to the _NSAKEY secret key.
It was possible to remove the second _NSAKEY using the following (note this was for Windows software in 1999).
There is good news among the bad, however. It turns out that there is a flaw in the way the "crypto_verify" function is implemented. Because of the way the crypto verification occurs, users can easily eliminate or replace the NSA key from the operating system without modifying any of Microsoft's original components. Since the NSA key is easily replaced, it means that non-US companies are free to install "strong" crypto services into Windows, without Microsoft's or the NSA's approval. Thus the NSA has effectively removed export control of "strong" crypto from Windows. A demonstration program that replaces the NSA key can be found on Cryptonym's website.
CAPI Signature Public Keys as PGP Keys
Primary key (_KEY)
Type Bits/KeyID Date User ID pub 1024/346B5095 1999/09/06 Microsoft's CAPI key <firstname.lastname@example.org> -----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-----
Secondary key (_NSAKEY and _KEY2)
Type Bits/KeyID Date User ID pub 1024/51682D1F 1999/09/06 NSA's Microsoft CAPI key <email@example.com> -----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-----
- Lotus Notes – openly used an NSA key in order to comply with cryptography export regulations
- Backdoor (computing)
- "Microsoft, the NSA, and You". Cryptonym. 31 August 1999. Archived from the original on 17 June 2000. Retrieved 7 January 2007. (Internet Archive / Wayback Machine)
- "NSA key to Windows: an open question". CNN. 4 September 1999. Archived from the original on October 2015. Retrieved 7 January 2007. (Internet Archive / Wayback Machine)
- "How NSA access was built into Windows". Heise. 4 January 1999. Retrieved 7 January 2007.
- "Microsoft Says Speculation About Security and NSA Is "Inaccurate and Unfounded"" (Press release). Microsoft Corp. 3 September 1999. Retrieved 9 November 2006.
- "There is no "Back Door" in Windows". Microsoft. 7 September 1999. Archived from the original on 20 May 2000. Retrieved 7 January 2007.
- "Windows NSAKEY Controversy". Rice University.
- "Analysis by Bruce Schneier". Counterpane. 15 September 1999. Retrieved 7 January 2007.
- "NSA key to Windows an open question". 3 September 1999. Retrieved 20 November 2011.
- "The reverse-engineered keys". Cypherspace. 6 September 1999. Retrieved 7 January 2007.