Public key based cryptographic algorithms strength is determined based on the time taken to derive the private key using brute force methods. The algorithm is deemed to be strong enough when the time required to derive private key is prohibitive enough using the computing power at disposal. The threat landscape continues to evolve. As such, we are further hardening our criteria for the RSA algorithm with key length less than 1024 bits.To further reduce the risk of unauthorized exposure of sensitive information, Microsoft has created a software update that will be released in August 2012 for the following operating systems: Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This update will block the use of cryptographic keys that are less than 1024 bits.Some issues that you may encounter after applying this update may include:
To prepare for this update, you should determine whether your organization is currently using keys less than 1024 bits. If it is, then you should take steps to update your cryptographic settings such that keys under 1024 bits are not in use.
The Crypto API builds a certificate trust chain and validates that chain using time validity, certificate revocation, and certificate policies (such as intended purposes). Once the update is applied, during chain building there is an additional check to ensure that no certificate in the chain has key length less than 1024 bits). Chain building is done using the CertGetCertificateChain function. If a key chain building issue is encountered with such a certificate, then the errors produced are as follows:Event 11, CAPI2
• CERT_TRUST_IS_NOT_SIGNATURE_VALID• CERT_TRUST_HAS_WEAK_SIGNATURE
There are three cryptographic service providers (CSPs) that defaultto allow minimum 512 bit keys in Windows Server 2008 R2:
When working with V2 certificate templates, if you do not specify the key size, then the default CSP with default key size will be used to generate the key. If the default CSP is one of the above 3 CSPs on the client box, then the generated key will be under 1024 bits. The CA which has been updated with weak key protection will reject such request. As a result, we recommended that you do the following:
When using certreq, ensure that you specify a 1024 bit or larger key in the INF file. For additional information, see Best Practice for Configuring Certificate Template Cryptography.
You can run the following query on your Certification Authorities (CAs) in order to discover certificate templates that are utilizingkeys under 1024 bits:
Certutil -dstemplate | findstr "[ msPKI-Minimal-Key-Size"| findstr /v "1024 2048 4096"Note: The command should be run in each forest in your organization.
If you run this query, templates that utilize keys that are smaller than 1024 bits will be shown with their key size. The following figure illustrates that two of the built-in templates SmartcardLogon and SmartcardUser templates have default key lengths that have minimum key sizes of 512 bits. You may also discover other templates that were duplicated with minimum key sizes of less than 1024 bits.
For each template you discover that allow less than 1024 bit keys, you should determine whether it is available to issue certificates as shown in the Certificate Templates section of the Certification Authority console.
For these templates, you should consider increasing the Minimum key size to a setting of at least 1024 (assuming the devices to which these certificates are to be issued support a larger key size).
You should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size (assuming certificate autoenrollment is enabled).
If you have issued certificates using the built-in Smartcard Logon or Smartcard User templates, you will not be able to adjust the minimum key size of the template directly. Instead, you will have to duplicate the template, increase the key size on the duplicated template, and then supersede the original template with the duplicated template.
After you have superseded the template, you should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size.
You can utilize CAPI2 logging starting with Windows Vista or Windows Server 2008 computers to help identify keys under 1024 bits. You can then allow the computers to perform their normal operations and check the log after a period of time to help identify such keys. You can then use that information to track down the sources of the certificates and make the necessary updates.
To accomplish this, you must first enable verbose diagnostic logging. To enable verbose mode logging:
Once you do this, you can then enable CAPI2 operational logging in the Event Viewer. The CAPI2 Operational log is located under Applications and Service Logs, Microsoft, Windows, and CAPI2 in the Event Viewer. To enable logging, right-click the Operational log and select Enable Log.
Once you've collected the log, you can use the following filter to reduce the number of entries that you have to search through in order to find certificate operations with keys under 1024 bits. The following filter looks for keys of 512 bits.
<Select Path="Microsoft-Windows-CAPI2/Operational">Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength='512']]]]] andUserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName='RSA']]]]]]</Select>
You can also query multiple key lengths with a single query. For example, the following filter queries for both 384 bit and 512 bit keys.
<Select Path="Microsoft-Windows-CAPI2/Operational">Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength='384']]]]] andUserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName='RSA']]]]]]orEvent[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength='512']]]]] andUserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName='RSA']]]]]]</Select>
Ingolfur Arnar Stangeland came up with a certutil command to show whether a CA has issued RSA certificates with keys less than 1024 bits. He published the instructions in his blog post "How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)" http://blogs.technet.com/b/instan/archive/2012/08/03/how-to-identify-if-your-adcs-has-issued-any-certificates-with-public-keys-lt-1024-bits-in-preparation-for-kb2661254.aspx
Security advisory http://technet.microsoft.com/security/advisory/2661254.
KB 2661254: http://support.microsoft.com/kb/2661254
Additional blog posts:
I strongly hope you are taking under consideration in this update that some '1024' keys are actually 1023 or 1022 bits long keys. Or you will run into very serious problems with it.
Please delete a "[" character from
1. I'm interesting in doing/using Event Forwarding to forward CAPI2 events to a central server. I'm already familiar with event forwarding and using it to forward from security, application and other logs. When I try to forward from the CAPI2 log the forwarder returns an error. I started with the Machine Account but even tried my domain admin account and the forwarder says 'no active channel is available'
2. Just a comment: You can enable the capi2 log by a registry or GP update also. Set the following key to a value of 1. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-CAPI2/Operational\Enable
Fixed the command. It should have included a space in the syntax (as shown in the figure). Thanks for reporting. As for the other comment about us considering the length of keys, we have done extensive testing on this and continue to do so. We will be posting an article in the future that will explain more, including troubleshooting steps and modifications to the settings. This posting is just an informational post about what is coming in the future. There will be more information and steps presented in the future as well.
jbourdet23, Would you please post the technical issue regarding the forwarding of CAPI2 logs to the Security forum (social.technet.microsoft.com/.../threads)?
Questions and answers:
1. Is this update targeting only RSA keys less than 1024 bits? Yes, only RSA keys are targeted.
2. Will there be a KB article? Yes, one is planned and will go out with the update.
3. If after installing the patch on a Microsoft CA, will the Web enrollment interface allow PKCS # 10 requests for certificates that use a key of 512-bit? Once the CA is patched, requests for certificates that are less than 1024 bits will fail.
4. Will the 1023 bit keys that are issued by IBM’s WebSphere be affected by the update? No, those keys will not be blocked by the update.
Will there be the chance to _intentionally_ delete / uninstall the respective MS patch? (=as a work-around in case that customer systems will not be able to be updated till August)
Kai Rohrbacher - When the update comes out, you will be able be modify how it works through the registry modifications. For example, you will be able to set 512 as minimum or set the system to only log issues - not block them. We have another blog post to discuss these settings planned as well as a TechNet Wiki article planned to describe how to identify and resolve issues with the update.
How will this affect the Secure ID RSA tokens?
Q: How will this affect VPNs?
A: PPTP used for VPN uses MPPE (technet.microsoft.com/.../cc757532.aspx) for encryption, which is different protocol and is not affected by the blocking RSA keys less than 1024 bits. Microsoft’s MPPE uses RC4 cipher suite for encryption, while non-Microsoft clients may use different ciphers for encryption. None of these is affected by this change.
This change is applicable only to RSA asymmetric keys and we are changing the behaviour of chain building (msdn.microsoft.com/.../aa376078.aspx) only.
RFC 3078 specifies that for initial session keys, peer credentials are used. If certificates less than 1024 bits are used for authentication then the authentication will fail before MPPE comes into picture.
Donna Simpson - I received a detailed answer to your question:
At a very high level view, the RSA SecurID authentication consists of a token(software/hardware) which is assigned to a computer user and it generates an authentication code at fixed intervals.
A user authenticating to a network resource, needs to enter both a PIN and the number being displayed at that moment on their RSA SecurID token. The server computes what number the token is supposed to be showing at that instance of time, checks it against user entered data and makes a decision to allow or deny access.So here the chain building function((CertGetCertificateChain()) is not invoked and it will not be hit in this case.
However, there are newer versions of SecurID which feature USB connector, which allows the token to be used as a smart card–like device for securely storing certificates (example: SID800 model).This device is capable of storing digital certificates which can be used to log on to a windows operating system and in that case if the certificate has RSA key less than 1024 bits then build chain function error and prevent user logon.
If you are not referring to RSA SecurID but in general taking about RSA secure token authentication, then whenever the authentication is based on RSA certificates then the chain building function will be used and if the certificate size is less than 1024 bits, the functionality will be broken.
Is the update one of the updates that Microsoft releases with the security patches every month? And will the patch be downloaded though Windows update?
When will there be more information about the update and the modifications of it?
If you are using certificates with one of the three CSP listed above, but you are using keys like 1024bit or longer, will there be any issues then?
Is Microsoft working with these CSP to change the default behavior or to delete the CSPs? It seems strange having them as available CSP if Microsoft dosnt changes the CSPs.
We have a website which requires client certificates in ssl negotiation and for signing docs with capicom. All client certs were issued by a certe authority with 512 rsa pub key. Although signing will probably work we are worried clients will not be able to log into the website after the update is pushed because their browsers will not build a trust chain. We can reissue the CA root cert but do we have to reissue all client certificates as well?
Will this update also affect .Sign/.Verify operations using the RSACryptoServiceProvider class?