There's been some discussion recently on this news alias about how Microsoft handles key management (and some related topics) in CryptoAPI (more specifically, the Microsoft base CSPs). Below is a document we've put together to help answer these questions.
Thanks, -JasonG
Product Manager, Windows NT Security Microsoft Corporation
Microsoft's Response to Recent Questions on the Recovery of Private Keys from various Microsoft Products
Recently, there has been discussion on some Internet forums about the methods Microsoft uses to store private keys in some of its products, as well as about CryptoAPI's role in key management. These discussions included some inaccurate information about the PFX and PKCS-12 formats, as well as how Microsoft implements these formats in its products.
This paper was prepared by the Microsoft Public Key Infrastructure team to provide some additional insight and clarification on these issues, and in some cases, identify long-term plans that Microsoft has to continue the improvement of security in our products.
CryptoAPI One area to clarify at the outset is the role of CryptoAPI. Implications that any key management problem on Microsoft's Internet products would be an example of fundamental problems with CryptoAPI are absolutely inaccurate. CryptoAPI is a set of cryptographic technologies that are provided for use by other software--sort of a cryptographic toolbox. The actual cryptographic functions are provided through Cryptographic Service Providers (CSPs), which are implemented as DLLs. With the exception of the details about a possible PKCS-12 attack, all the issues raised in the recent discussions are specifically aimed at Microsoft's base CSPs, not at CryptoAPI. The base CSPs are the royalty-free, software-based CSPs provided with Windows NT 4.0, Windows 95, and Internet Explorer. These attacks do not apply in general to other CryptoAPI CSPs and do not indicate any fundamental concerns with the security of the CryptoAPI architecture or applications built upon it.
PFX/PKCS-12 Microsoft products do not "store" private key material using PKCS-12, contrary to recent descriptions on the Internet. For clarification, PKCS-12 is a standard format, used for export/import of Public Key Certificates and related key material. At present, the only Microsoft product that supports use of this format is Microsoft Internet Explorer 4.x. Internet Explorer uses PKCS-12 solely as a means of migrating a user's Certificate and public-private key pair between multiple Internet Explorer installations or between Internet Explorer and other products, such as Netscape Communicator.
Some background might help. Microsoft originally developed the draft specification for an encrypted export/import format, referred to as PFX, but the PFX specification was never implemented by Microsoft. Instead, the PFX specification was handed over to RSA Labs and it became the draft PKCS-12 specification. The design was then reviewed, and contributed to, by a number of other companies to arrive at the current PKCS-12 standard. Microsoft and Netscape have both implemented PKCS-12 with 40-bit encryption. This was done to provide a common, exportable solution that was completely interoperable.
The example of breaking a PKCS-12 data blob, which was given in discussion on the Internet, is not an attack on the "weak" cryptography of PKCS-12. Rather, it is simply a dictionary attack (long known and well understood in cryptography), which works well if people use poorly-chosen passwords to protect the PKCS-12 data blob. Examples of such bad passwords include words in the English dictionary. In our implementation of PKCS-12, we could possibly do some things to make brute-force attack against an exported PKCS-12 data blob more difficult. For example, performing a dictionary check on the password before accepting it for encrypting the data blob would reduce the use of weak passwords. Alternatively, we could iterate the setup function to increase "diversity" making it much more expensive for an attacker to search. However, neither of these methods are required for protection of the data blob. Good security is always a combination of technology and policy. As part of a strong security policy, strong passwords should be used on all resources. The Microsoft Security Advisor website (http://www.microsoft.com/security) has some guidelines for choosing strong passwords.
One statement by the original poster argues that Microsoft managed to design a security format that actually makes it easier to break into the protected data. As stated above, a number of well respected companies were involved extensively in the design and review of PKCS-12 before it became a standard. An iteration count, which would make the type of attack described above more difficult (in terms of time), was added late in the PKCS-12 evolution. It was, however, too late to make it into the Internet Explorer 4 product release. Future versions of Internet Explorer will include support for the an iteration count, further strengthening the security of exported key material.
Of course, in general the PKCS-12 data objects will not be available on a user's machine, since they are only used by Internet Explorer 4.x when exporting key material to, or importing key material from another system. As with any sensitive data, users should take care when working PKCS-12 data blobs and not leave them on their hard drives.
Exploiting Internet Explorer One of the fundamental requirements to perform any possible cryptographic attack discussed in the recent postings is the assumption that a malicious entity could somehow access to data on a user's computer system, without the permission or knowledge of the user. This is a large leap of faith. Users that are using Public Key Certificates today are generally sophisticated and savvy users, or part of a larger corporate infrastructure with knowledgeable administrators. This class of users will certainly keep abreast of current security issues and install security-related patches and updates as they become available. Microsoft has been extremely responsive in dealing with all known Internet Explorer security attacks and has posted patches for all currently known attacks. And, of course, security issues are certainly not limited to Microsoft software.
Information on security-related issues with Microsoft products is available on the Microsoft Security Advisor website at http://www.microsoft.com/security.
Attacks against Authenticode signing keys Another concern identified was that if a malicious hacker could steal a user's or company's Authenticode signing key, that hacker could sign objects with that key and distribute them. Then when other users tried to download the signed object, they would think the key's owner really signed the object, which might contain malicious code. The Authenticode program has been designed to ensure that only trusted programs are allowed to run on a users machine. As stated earlier Microsoft has been very responsive is addressing security issues with IE.
However, it is extremely unlikely anyone could be successful with a simplistic strategy for stealing Authenticode signing keys and then using them. As noted above, there are security patches already released for known Internet Explorer bugs that could possibly allow a key blob to be stolen off a user's hard disk (assuming a user left an Authenticode 'key' file on their hard disk). Second, anyone signing code using Authenticode technology is extremely unlikely to leave their key material sitting on an end user machine routinely used for browsing the Internet.
Microsoft recommends storing key material, such as that used in Authenticode, in hardware tokens. Such tokens prevent any of these attacks from getting started as the keys are not stored in the PC and are not exportable. The Authenticode signing keys that Microsoft uses for all our software, for instance, are stored in such a physical hardware key storage mechanism.
Attacks on Encrypted Key material There is some confusion over the algorithms and methods that Microsoft uses to provide protection of encrypted key material in Internet Explorer when using the standard Microsoft base CSPs. There were changes between Internet Explorer 3.0x and Internet Explorer 4.x specifically to address any possible concern. Note, this concern is unlikely to be valid for any third-party software CSP and is not relevant to hardware CSPs.
Microsoft is constantly working to improve the security of our products. We determined that there were better suited methods for storing keys than using the RSA RC4 stream cipher algorithm used in Internet Explorer 3.0x. In particular, a stream cipher, such as RC4, is not ideally suited for this particular use because it can be susceptible to a "known-keystream attack". In a known-keystream attack, if you know the plain text, which you arguably might be able to determine given the number of standard PKCS-8 fields, you can recover the keystream. If you recover the keystream, then a XOR function will indeed decrypt anything else encrypted with the same key. However, Microsoft only used this RC4-based implementation in the base CSPs that shipped with Internet Explorer 3.0x. The CSPs that shipped in Internet Explorer 4.x protect private key material in a form that is encrypted using DES, which is a block cipher and is not susceptible to the known-keystream attack that can be used against RC4.
Again, note that this kind of attack assumes some degree of security breach on the user's system such that the keystream could be obtained.
Key export attacks The original Internet posting raises concern about the CryptoAPI interface CryptExportKey(). This function is fully documented and does indeed export private key material in an encrypted format. The presence of the CryptExportKey() function is to support functionality such as migrating key material between machines for a user or creating a backup copy of a key. It should be noted however, that many CSPs, including most hardware based CSPs, do not allow exportable private keys and will return and error in response to a CryptExportKey() request.
Also, Microsoft's base software CSPs provide a means to mark keys as non-exportable when they are generated. An additional security protection is provided if the flag CRYPT_USER_PROTECTED is set, in which case each use of the private key, including export, requires the user to supply a password to access the key. Some commercial CAs are not currently setting this flag and do not provide the user a way to request it during Certificate enrollment. We recognize this as a problem. We will continue working with CAs to assist them in supporting these security features. However, we will also make available a utility to allow setting this flag after key generation for users concerned with this type of attack.
The posting also asserts that an ActiveX control could be downloaded from a web page, simply ask for the current users key, ship the key off for collection by an unscrupulous person, and then delete itself without a trace.
If users run unsigned code, or code from an unknown origin, a number of unpleasant things can happen. This could indeed occur if the key as been marked exportable and the CRYPT_USER_PROTECTED flag is not set. However, such a scenario assumes that the user follows few or no policies with regard to good security, such as running code from unknown sources. Similarly, if the user were running software from unknown/untrusted sources, that software could reformat their hard drive, or manipulate other user data. This concept is certainly not new.
There was also discussion of 16 dialog boxes appearing to the user for their password if the CRYPT_USER_PROTECTED flag is set. Certainly asking the user too many times would be better than too few times, however in our tests, under extreme (and uncommon cases), a user might be asked for their password at most four times when a key is used with the Microsoft base CSPs. Perhaps the claim came from an early beta release.
---------------------------------------------------------------- Users Guide http://www.microsoft.com/sitebuilder/resource/mailfaq.asp contains important info including how to unsubscribe. Save time, search the archives at http://microsoft.ease.lsoft.com/archives/index.html