Are There Back Doors in Microsoft's Operating Systems?

You might already be aware of a new report that alleges there are backdoors in Microsoft’s OSs. In the report, Andrew Fernandes detailed hisdiscovery of two cryptographic keys within the Windows OSs: KEY and _NSAKEY. It is this second key and its name that touched off a frenzy of allegations and debate.

In a nutshell, Microsoft OSs have a subsystem called the CryptoAPI that helps provide cryptographic services for the OSs. Developers can use the CryptoAPI to create their own Cryptographic Service Providers (CSPs); Microsoft uses the two keys to sign those CSPs. According to Microsoft, the first key is a primary key and the second is a secondary (backup) key in case an intruder compromises the primary key.

However, Microsoft's explanation for the second key isn't pacifyingeveryone. More than one cryptography aficionado haspointed out that usually a mechanism exists to revoke compromised keys; however, no such revocation mechanism exists within the CryptoAPI. This lack of protection has raised suspicions within the security community.

I watched and read various online forums and mailing lists as person after person lashed out at Microsoft. Many people are centering their thoughts on the second key's name: _NSAKEY. Some people apparently think the name alone is enough to convict Microsoft of putting a back door into Windows. So, let me clear the air a little on this matter.

First, programmers can define variables using any namingconvention, and just because someone at Microsoft used the name _NSAKEY doesn't mean that the company delivered the key to the National Security Agency (NSA). Granted, the name leaves room for suspicion, but it's hardly convicting evidence. Second, a cryptographic key alone does not constitute a genuine back door, because you can’t use the key by itself to access a Windows OS. Granted, the key can be an essential tool for cracking system security, but again, it's useless without a way into the system. I fail to see how the existence of the second key can be deemed a genuine back door. In comparison, tools exist to recover lost administrator passwords, so should this potential also be considered a back door? I think not.

Microsoft's source code is not in the public domain, so it's incredibly difficult to discover what undocumented functionality might reside under the hood. Even Microsoft's developers aren't aware of everything in an OS, because source code access at Microsoft is heavily compartmentalized. As an example, a related discovery last year showed that Windows 2000 (Win2K) has not only two, but three cryptographic keys for use by the CryptoAPI. But when that information was released at a 1998 cryptography convention, a Microsoft employee in attendance displayed surprise at the revelation, having no knowledge of the third key, even though he directly took part in developing Win2K’s CryptoAPI. So what's the moral here? We simply have to trust vendors that don't provide source code for peer review. That's a tough item to accept, but at this point I know of no other choice.

Although the _NSAKEY name is suspicious, and I'm now required to trust Microsoft when it says it hasn't shared the key with anyone outside of Microsoft, I think a bigger issue Fernandes discovered is the fact that a user can easily replace the key. Fernandes made that point by releasing a utility that can replace the second key.

So what are the implications with this part of his discovery? Well, several security reports have stated that an intruder can Trojanan OS, so what's to stop a Trojan from overwriting the second key, loading a new CSP, signing the new CSP with the newly replaced second key, and using that CSP to further subvert network security? The answer is diligent security practices--the same practices you'd use to prevent a Trojan from altering or stealing your SAM database or other sensitive system information. If you don't already employ technology to monitor and guard your system files and Registry information, you should consider adding that type of functionality. Consider using a tool such as Tripwire for NT (http://www.tripwiresecurity.com) to help monitor your system for unauthorized changes. I reviewed Tripwire for NT and found it to be a great add-on. Look for my review of Tripwire in the November 1999 issue of Windows NT Magazine.

Keep in mind that if does Trojan your system, you have more than just a vulnerable backup cryptography key to worry about. Until next time, have a great week.