Recently, reports have surfaced (InfoWorld magazine, ZDNet and a number of other sites) regarding an "NSA key" in all versions of the windows operating system which is reported to enable a "back door" into potentially every computer in the world. In the past few days, we have received a large number of inquiries from our customers as to whether our products continue to protect them against this latest "menace." There is a very serious problem here but its scope has not been accurately reported and its significance appears to remain elusive.

 First, we'd like to assure our customers using our  IEClean 5.00  product, and have turned off ActiveX, Java, Hit logging (if using IE4 or IE5) and autocomplete (IE5 only) in the IEClean OPTIONS tab as we strongly urged you to in IEClean's instructions, that IEClean will cause your Internet Explorer browser to produce a warning message informing you that your security settings will not permit the download of any exploited control, crypto key or program before it can be downloaded and installed on your machine. You must then deliberately permit any such programs to be downloaded to your machine for an exploit of this flaw to be successful. You have the option of refusing any unexpected or unrequested download with IEClean installed on your machine. There is no need to upgrade or patch your IEClean as a result of this risk since the flaw is in the operating system itself and only Microsoft can remediate this problem in the absence of documentation which would permit others to step in to correct it for them. IEClean will at least alert our customers to any such attempts if they follow our advice and configure IEClean to refuse ActiveX, MS Java or other functions which are described in IEClean's documentation as inherently dangerous.

 This "bug" in Windows is NOT a trojan horse or an attack on your system, nor can it even remotely be used by government agencies to gain access to any machine by itself. In order to gain access to your machine, a separate executable program, Microsoft javascript, ASP script or ActiveX control must interface with the flawed libraries in order to exploit this hole. Should anyone decide to exploit this flaw in the absence of a Microsoft repair of the problem, customers using our BOClean 4.03 product will be covered by any necessary updates if and when it is exploited upon its discovery. People who are using the Netscape internet browser are not at risk because Netscape uses its own implementations of crypto which are built into Netscape and do not require the use of the Microsoft Cryptography API. However, we still advise those using our NSClean 4.50 product to disable java and javascript to protect against other risks when using Netscape.

  Privacy Software Corporation has studied this issue extensively over a five day period following the release of a security alert by Cryptonym on August 31, 1999 and has come to conclusions radically different from those reached by Cryptonym and reports in various media since the report was released by Cryptonym.We have determined that the "_nsakey" discovered by Cryptonym is in fact nothing more than a second "public key" and is not in any way, shape or form a "back door." We're willing to accept Microsoft's word that the second public key being named "nsakey" does not mean that it is connected in any way with the National Security Agency and is likely an unfortunate naming of an internal function of the "Cryptography API" during programming. However, we do not accept Microsoft's explanation that the "nsakey" is a "backup" key in the event of the "need for disaster recovery." It is clearly and unequivocally a separate and unique key from the first. This article probably explains the reason for that "second key."

 Our conclusion is that this "mysterious key" is in fact a second public key intended for use by the international banking community which permits the use of 128 bit ciphers offshore, carefully skirting around US export laws while protecting the "domestic use" public key. Originally, export restrictions prohibited "strong encryption" from being exported, but on November 15, 1996, President Clinton signed Executive Order 13026 which changed regulation of encryption from the U.S. Munitions list to the purview of the U.S. Commerce Department. On June 25, 1997, the export of 128-bit encryption by Microsoft and Netscape for purposes such as international banking was approved by the U.S. Commerce Department with significant restrictions.

 The issue of "Strong Encryption" has been a center of controversy between the U.S. Government and the computer industry for a number of years. During this time, only U.S. Citizens were permitted to download 128 bit encryption versions of both Netscape and Internet Explorer while citizens of other nations were limited to weaker 40 bit encryption. In order for U.S. Citizens to be permitted to download the 128 bit versions instead of the "international" versions however, they were required to fill out a form with a great deal of personal information to verify their citizenship as well as the location of the machine where 128 bit encryption would be installed. Microsoft has recently succeeded in convincing the administration in Washington to ease restrictions for Microsoft, and Netscape has just announced that because Microsoft was able to exploit a loophole in the regulations, that Netscape should be permitted to do so also.

 This exclusion was also granted but the issue of exporting of strong encryption in excess of 128 bits (some Russian cryptography programs exceed 1024 bits of encryption) remains a thorn in the side of U.S. software makers and conspiracy fans in usenet newsgroups are already suggesting that this "flaw" could be a deliberate attempt to make the issue moot by completely compromising the existing containment of cryptography. We are not suggesting this is the case, but the net effect of this security hole would indeed accomplish this (and probably already has). Prior to this flaw, there was absolutely no way for non-U.S. companies (or criminals) to embed their cryptography routines into Windows owing to the export controls in effect and Microsoft and Verisign's sole control of access to these routines and issuance of the necessary key pairs as well as the necessary authentication "signatures" which would permit this. Now it can be readily done by anyone in the world by exploiting this flaw.

 The risk in Microsoft's error is not that the libraries contain a "trojan horse" or "back door." We have determined this much for certain. The flaw involves providing a second public key as well as a serious design flaw that allows this second key to be manipulated and/or REPLACED with another key that might not originate from a certified source. Providing more than one valid key for a cryptography process effectively cuts the effectiveness of the cryptography in half since someone trying to break the cryptography now has two chances to "win" instead of one. This is significant enough of a security risk but Microsoft goes one better by allowing their Cryptography API to REPLACE this second key with simple calls to the API which copies out the second key, replaces it with another and saves it - all without raising any alarms.

 This is demonstrated by a downloadable program on the Cryptonym site which proves the exploit on Windows2000 and WindowsNT systems. While Cryptonym was not able to provide a demonstration for Windows95 and Windows98, we performed a test here using the "CryptAPI" and it works on these platforms as well. This flaw allows absolute circumvention of U.S. export laws by foreign manufacturers of encryption tools while U.S. interests remain at a disadvantage by permitting foreign manufacturers to integrate their products directly into Windows while domestic manufacturers are still prohibited from doing so. This flaw effectively ends U.S. government control of "strong encryption." It also serves to destroy the reputation of Verisign as a controlling influence in certification, permitting anyone to become a "root authority" by manipulating the flawed libraries so long as any copies of it exist.

 The Cryptography API is used to secure internet commerce (which uses the SSL protocol for online purchasing and banking) as well as encrypted communications by email and private virtual networks (which use the S/MIME protocol) for encryption and security. The flaw also renders "signed certificates" provided with ActiveX controls and other Microsoft "partner" products as no longer credible if the public key by which they are verified as "safe" has been compromised. In addition, a forged secondary key is capable of hiding a forged primary key, something we've been warning about in Internet Explorer since the release of our IEClean 4.01 product over two years ago as the basis for our insistence that ActiveX and Microsoft java are insecure because of their dependence on "certificates." This is an enormous security failure. The encryption is provided for both of these in Internet Explorer using the now "toxic" Microsoft Cryptography API. Again, Netscape remains secure as they do not use these libraries and therefore Netscape cannot be exploited in this manner.

 The flawed libraries are part of the Microsoft Internet Explorer browser and its integration into the Windows operating system itself which we warned against in testimony before the Federal Trade Commission back in 1997. We are unable to determine however whether or not popular standalone encryption software such as PGP and similar programs are at risk. If they make use of the Microsoft Cyrptography API then any such programs will definitely be at risk. We can only recommend that you contact your cryptography vendor and find out if their products use CRYPT32.DLL or MSOSS.DLL, the libraries which actually have the problem or if they filter their cryptography through the Internet Explorer browser. The ADVAPI32.DLL library cited in research by Cryptonym is but one module that calls the CRYPT32.DLL library, which in turn calls the MSOSS.DLL library and the flaws referred to are in these libraries and not in ADVAPI32.DLL itself. ADVAPI32 merely "marshalls" resources from other, more obscure library files in the Microsoft operating system.

 The keys themselves are actually hidden away in yet another DLL which contains the RSA encryption functions which will go unnamed here at this time. ADVAPI32.DLL is only the "connector" for Internet Explorer and now, the operating system as well. Individual programs which use the Microsoft Cryptography API can call directly down to the "Crypto" libraries without going through ADVAPI32.DLL to get to them. These Crypto libraries exist in order to make it easier for programs to incorporate encryption within them using Microsoft's prewritten code instead of having to create their own. Chances are a number of encryption programs are using these flawed libraries. Since Privacy Software Corporation does not sell encryption products, we have not bothered to test popular encryption software other than those in the browsers themselves.

CONCLUSION:

 The Microsoft Cryptography API is so seriously compromised that it must be considered to be untrustworthy and owing to the severity of the security issues involved, no Microsoft product which uses any of these functions or libraries should be used for any sensitive purposes until such time as Microsoft corrects these problems universally. Because these functions are integrated into the operating system itself (and other programs manufactured by Microsoft as set forth in the independent information contained in the links above) and so many portions of the operating system's functionality is dependent upon "trusted functions" whose "trust" is established by a flawed encryption system, the operating system itself should be considered "toxic" from a security standpoint.

 Since RAS, IIS, ODBC and VPN services running on NT servers also utilize the CRYPT32.DLL services, they should also be considered "toxic" as the authentication processes of NT are dependent on the veracity of certificates provided by the flawed crypto libraries as well. Any servers running on the NT operating system are therefore also likely to be at significant risk where they depend on the Microsoft Cryptography API for authentication. In addition, "trusted application" certificates from Microsoft and Verisign should also be considered to lack "trust" based on an untrustworthy certification engine.

 In particular, the use of SSL, S/MIME and certificates in electronic commerce on any Windows platform constitutes a hazard to both financial institutions and users of the Internet Explorer browser until these flaws are remedied. We pray that Microsoft will resolve this problem quickly and will be encouraged to do so in the national interest. In the meantime, we recommend the use of Netscape or other browser not associated with the Microsoft Cryptography API and to not use Internet Explorer (including any IE variants such as the AOL browser, NeoPlanet or other customized versions of the IE browser provided by your ISP), Microsoft Office (or its components or subcomponents) or Microsoft email software for sensitive communications at this time. Anything which utilizes the Microsoft Cryptography API library is at peril until such time as this problem is fixed. If the risks of widespread fraud under cover of the "y2k bug" is also considered, this flaw is ripe for abuse as a potential avenue of, or cover for, "criminal or terrorist activity" and a solution to these problems must be arrived at quickly as a matter of national security.

 In addition, based on our broad experience in defeating trojan horse remote control programs which allow unauthorized remote users to take control of Windows-based computers which we circumvent in our BOClean antitrojan software, we expect a very quick pickup on this security flaw by the various authors of these malicious programs to take advantage of whatever they are capable of accessing. As a result, this flaw represents a textbook example of a "clear and present danger" and requires the highest of priorities for remediation with all diligent speed. This is a very serious security problem contrary to the short shrift it received in the technical media. As a matter of national security, this could be more serious than the theft of nuclear weapons secrets from the Energy Department in its breadth, scope, severity and significance.

COPYRIGHTED MATERIAL:

Copyright (c) 1999 by Privacy Software Corporation.

Permission is granted for the retransmission of this advisory by electronic means. It is not to be edited in any way without the express consent of Privacy Software Corporation. Requests to reprint this information in whole or in part should be directed to technology@privsoft.com. Copyrighted material linked to in this page remains the exclusive property of their owners and our request for permission to reprint does not apply to pages linked to externally in this document.

Disclaimer: The information within this advisory may change without notice and is provided by Privacy Software Corporation AS IS. No warrantees, express or implied, are provided with respect to this information nor should any be construed by the transmission of this information. Any use of this information or its recommendations is solely at the risk of the user. Any opinions expressed in this document are those of its author, Kevin McAleavey and are based on his professional interpretation of the facts presented and are published by Privacy Software Corporation on the basis of his expertise.

Contact Privacy Software Corporation at http://www.privsoft.com, http://www.nsclean.com, or by email to technology@privsoft.com. Privacy Software Corporation reserves the right to refuse transmission without further explanation.