During customer visits, I am often asked what is the most secure way to store and handle private key material. As we probably all know, two-factor authentication methods are the ones that are usually described when private key protection is of the utmost importance. So, in case of storing the private key of an Offline or Issuing Certification Authority, a Hardware Security Module (HSM) would be proposed, and for digitally signing emails or documents, a smart card would be ideal to store the key pair. Some companies, however, are reluctant to introduce hardware devices to their environment for two reasons: a) they believe they will add complexity to an already complex IT environment and that would degrade the end-user experience and b) they are not prepared to bear the added cost. In case of smart cards, that would amount to a pretty cheap device (around $20-40 or more, depending on quantity and software used). In both situations, the companies’ IT (or Security) departments do have a point, but they usually still need to have an extra layer of security for their end users. So, is there any “poor man’s added security” for private key usage?

Strong key protection while enrolling a certificate

Strong key protection password window during enrollment

Well, in the client-side of the Windows PKI world, the folks that designed CryptoAPI added an extra security feature called strong key protection. In essence, what strong key protection does, is to force the user to enter a user-defined password which protects the private key whenever (almost, as we are going to see later on) this is going to be used for a cryptographic operation. When such an operation (for example, digitally signing an email) is performed, the user will have to provide this password and only then the underlying client (Outlook, in this case) will be able to have access to they key.

The prerequisites to enable and use this feature are to select the relevant option in the Request Handling tab of the certificate template, and then have the user enter a password during user certificate enrollment. There are two caveats here that are hard to spot: a) there is now way to force a user to select the High security option and b) once you enter the password in Outlook, for example for signing or decrypting, the system will not ask for it again except if you close and re-open the application. Moreover, the password entered by the user if the certificate is generated by a Windows XP client will not conform to the domain policy’s complexity requirements – Windows Vista and later clients, though, will conform to it.

Certificate template settings for strong key protection