There is no "Back Door" in Windows
Originally Posted: September 03, 1999
Revised: September 07, 1999
On This Page
Summary
A report alleges that Microsoft "may have installed a 'back door' for the National Security Agency... making it orders of magnitude easier for the US government to access their computers". Specifically, the report alleges that a cryptographic key labeled "NSA key" within the CryptoAPI architecture constitutes a "back door" that could be used by government agencies to start or stop system security services on user's computers. This allegation is false.
Is the allegation true?
No. Microsoft does not leave "back doors" in our products. This is in keeping with our historical stance on this issue. For instance, we have opposed the various key escrow proposals that have been suggested by the government, because we don't believe they are in the best interests of consumers or the industry.
What's CryptoAPI?
CryptoAPI is a Microsoft technology for providing cryptographic services to general-purpose software programs. The technology addresses a common problem in software development: software applications frequently need to perform cryptographic functions such as encrypting or decrypting data, but implementing these functions is a highly-specialized skill. CryptoAPI frees general-purpose software developers from needing to implement cryptographic functions by allowing them to simply request cryptographic functions through it. At the same time, it enables cryptography specialists to focus on their area of expertise by building the modules that deliver these functions, known as Cryptographic Service Providers (CSPs).
The end result is that both sets of programmers can focus on what they do best. Developers who write general-purpose programs can use cryptography without needing to be an expert in it, and cryptographers can deliver CSPs that can be installed and used by any general-purpose programs that need cryptographic support. For more information on CryptoAPI, see http://msdn.microsoft.com/library/en-us/security/security/cryptoapi_system_architecture.asp
Are there two keys?
Yes. However, both are Microsoft keys. We do not share them with any third party, including the National Security Agency or any other government agency.
What are the keys used for?
The keys are used to verify the digital signatures on CSPs.
Why do CSPs have to be signed? And why by Microsoft?
CryptoAPI is subject to US export laws regarding cryptography. One element of this requires Microsoft to take reasonable steps to ensure that CryptoAPI will only load CSPs that meet US cryptographic export laws. This is done by digitally signing all CSPs. Before it loads a CSP, CryptoAPI verifies that the CSP has been digitally signed.
Part of Microsoft's responsibility as the vendor for CryptoAPI is to sign the CSPs. When a vendor has a new CSP that they want to release, they submit it to Microsoft for signing and assert that one of the following is true:
| • | The CSP will be deployed in North America only, and therefore is not subject to US export controls. In this case, Microsoft digitally signs the CSP immediately. |
| • | The CSP may be exported from North America and has received export approval. In this case, Microsoft confirms the export approval and signs the CSP. |
Can the keys be used to decrypt data?
No. The keys can only be used to identify software components, as a way of insuring that only ones that comply with US export laws can run under CryptoAPI.
Can the keys be used to stop or start security services on a user's computer?
No. The keys can only be used to identify software components. There is no capability to use them to stop or start security services without the user's permission.
Are these keys in any way related to my login password?
No. They are only used to identify CryptoAPI CSPs.
Could someone use these keys to weaken my security?
No. They would need the private half of either key pair; and as noted above, we have not shared these keys with anyone, including the NSA. Even Microsoft could not use the keys directly to weaken your security. The worst thing that could be done with the keys would be to digitally sign poorly-written CSPs, but even then there would be no way to get the CSPs onto your computer without your approval.
Why are there two keys?
There is a primary and a backup key.
Why is a backup key needed?
The backup key is needed for disaster recovery. Specifically, it's provided as a contingency against loss of the primary private key. To see why this is needed, suppose we had only one signing key. If a natural disaster destroyed the building in which it were kept, all of the previously-signed CSPs would continue to function normally, because the key used for verification exists in every copy of Windows. However, to sign new CSPs, Microsoft would need to generate a new signing key and sign future CSPs with it. In order for these CSPs to be verified, matching key material would need to be provided to all of the millions of customers using Windows 95, 98 and Windows NT. Clearly, this would be a massive undertaking.
This is why there are two keys. If something befell the primary key, Microsoft could immediately begin signing CSPs using the backup key. Because the backup is already in every copy of Windows, there would be no disruption to customers. Microsoft works with over 50 security vendors in the U.S. and elsewhere producing strong encryption CSPs for customers worldwide. We sign CSPs from vendors on a daily basis - their own product release schedules are dependent on our ability to respond to their signing requests quickly. It would be unthinkable to allow a global security platform such as CryptoAPI to be removed from service by a loss or failure of a single private key component.
It's very important to note the difference between key loss and key compromise. Key loss means the loss of the private key itself, and with it the ability for Microsoft to sign CSPs. Key compromise means the loss of the confidentiality associated with the key, as would happen if, for example, someone gained a copy of the key.
How does Microsoft protect against key compromise?
We cannot disclose specific security procedures, but can say that recognized security techniques using a combination of hardware, software, and physical security are employed.
Why is the backup key labeled "NSA key"?
This is simply an unfortunate name. The NSA performs the technical review for all US cryptographic export requests. The keys in question are the ones that allow us to ensure compliance with the NSA's technical review. Therefore, they came to be known within Microsoft as "the NSA keys", and this was used as a variable name for one of the keys. However, Microsoft holds these keys and does not share them with anyone, including the NSA.
I heard that there is a third key in Windows 2000. Is this true?
There was a third key present in the beta versions of Windows 2000, but it did not provide a "back door". It was simply a test key that allowed the developers to sign test CSPs while Windows 2000 was under development. It is not present in the production version of Windows 2000.
As part of our development methodology, Microsoft built a new version of Windows 2000 virtually every day. This build includes the default CSP that ships with Windows 2000, as well as any other test CSPs that are needed. These CSPs must be signed every time they are re-created. Because of the security discussed above associated with the primary key, it is not feasible to use it to sign the daily builds. Even if it were feasible, it wouldn't be advisable to sign test CSPs with a production key. For these reasons, a third key is used solely for signing CSPs during development.
By the time Windows 2000 shipped, the test key had served its purpose and was removed. The default CSP will be signed using the production key. This will have the additional benefit of ensuring that any CSPs that were developed solely for testing purposes will be unable to run under the released version of Windows 2000.
Does this have any effect on CryptoAPI's compliance with US export law?
No. The CryptoAPI architecture is fully compliant with US export law.
Revisions
| • | September 03, 1999: Bulletin Created. |
| • | September 07, 1999: Revised to provide additional detail. |
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.