Corporate and governmental information systems must be able to process and exchange private and sensitive data in a secure manner. At the core of many of these information systems is an infrastructure that builds the framework for establishing trust between the various users, applications and data repositories. The public key infrastructure or PKI and its certificate authority (CA) support the creation and exchange of digital certificates used to identify machines and users. Using asymmetric cryptography, public certificates and private keys enable applications to encrypt and decrypt data so that it can be used and exchanged securely and to digitally sign messages to confirm their integrity.
Many organizations today manage their own PKIs and have built them on Microsoft Active Directory Certificate Services (AD CS). A considerable number of these have been in operation for more than a decade. Early adoption of in-house PKIs was driven in part by the fact that Microsoft made the capability readily available as a free option included in the Windows operating system. PKIs are architected hierarchically – there is a root CA at the top that delegates trust to one or more issuing CAs that then sign and issue all certificates used across the organization. The basis of trust in a PKI relies on the secrecy of private CA keys used to sign the certificates that are issued. If there is even the suspicion that these CA private keys might be available to attackers, all your systems that use certificates from that CA must be considered compromised, and all certificates would need to be reissued! Imagine if the services you depend on most for your daily business were disabled because a single key was stolen. In today’s distributed enterprise world, that could be a lot of applications used by your employees, your suppliers, and your customers. Organizations therefore should be extremely vigilant as to how they protect these keys.
Recent revelations such as the Heartbleed vulnerability have highlighted how sensitive information (including keys) can leak from the memory of standard servers and operating systems. With mission-critical server based applications such as a CA, it is imperative to use additional levels of security to protect the CA software and the server platform on which it runs. This includes the use of specialist hardened devices – what the industry calls hardware security modules or HSMs.
If you thought recovering from the Heartbleed exploit was painful, recovering from a root CA key compromise can be orders of magnitude worse. Heartbleed affected things that use certificates, but a root CA key compromise impacts the issuance of certificates, and since many internal certificates live in physical smart cards that take longer to re-issue and re-distribute, this adds logistical complexity and cost. For the typical organization this would mean interruption of operations, lost revenue, damaged reputation, and massive remediation costs. Recovering from such an attack can be devastating.
This brings me back to Microsoft Active Directory Certificate Services. Introduced over 10 years ago and made part of Windows Server 2003 – many organizations have used this effectively for years, but there are a number of reasons why it has become critically important to develop specific migration plans to a more up-to-date version. Microsoft has significantly improved the security and functionality of its PKI technology over the years with new releases that include stronger algorithms, longer key lengths, and new certificate types. These enhancements can be used to provide higher levels of assurance for existing business applications and enable the use of PKI to support new applications in the future – in particular very high scale requirements around bring your own device (BYOD) and the ‘internet of things’. Perhaps the most important reason for migration is that Microsoft Windows Server 2003 reaches end of support next year (2015) and that means there will be no more security patches going forward.
Hackers are well aware of the prevalence of this PKI and operating system and the implications of its end of life. If you have not already, it’s time to start migrating to a supported version of Windows PKI and to re-evaluate your PKI security requirements and potential use of HSMs. And even if you have migrated, you should ensure that your critical keys are protected by an HSM. It’s time to enhance the trust in your CA and strengthen your PKI. Get prepared and don’t become the next headline.
To learn how to mitigate risks and protect your critical CA root keys through migration and use of HSMs, download a copy of our new white paper 'Upgrading and Improving the Trust of Microsoft Windows Certificate Authorities'.