My first experience with PKI was back in 1997. We (Andy Khomenko, currently with Caspio, and I) have been developing a business-to-business e-commerce site. We decided to use client certificates for authentication, as just-released IIS 2.0 on Windows NT 4.0 was supporting them. There was no Microsoft CA back then – so I have written a CGI wrapper around SSLeay (now OpenSSL) that managed client requests, certificate issuance process and kept the relevant logs in Microsoft SQL Server database. Looking back, the whole setup wasn’t very secure – and not only because of the endless vulnerabilities in the technologies that we used. But in the end we had a working product using then-leading edge technologies, and cut our teeth in the e-commerce technology and Internet security.
In early 2000s I have seen transition of internal PKI from a test facility running from a floppy in a guy’s desktop to an enterprise service with countless applications depending on it. At the same time, the certificate authority key migrated from the floppy to HSM, the hardware security module. HSMs are amazing devices: they can require multiple people with smart cards to perform an operation (based on the policy, even basic tasks like signing certificate request or CRL may require multiple custodians present), and can drop keys is the device is shaken or temperature changes. The whole idea is to have private keys stored more securely than anywhere on the commodity hardware and operating systems.
Amazingly, while HSMs prevailed in enterprise environments, design decisions are made as if the CA keys are stored in the Inetpub folder on a Windows NT 4.0 SP1 system. That’s the rationale behind implementation of the offline root CA.
In Deploying and Managing PKI inside Microsoft (a must-read), under MS PKI Security Requirements, Microsoft guys say: “Even though Microsoft internal hierarchy no longer had the previous intermediate CAs, Microsoft IT did not lower any of the existing security controls. The root and the new intermediate CA were offline and never exposed to network traffic, thereby minimizing the chance of a compromise“. But hang on: what is the compromise of CA?
There are two common fault scenarios: issuance of certificates to unintended recipients; and losing ownership of the CA keys. The first scenario is not mitigated by the offline root: you revoke the certificates and possibly review the process. That’s happened with Verisign and other commercial CAs. The second scenario – total loss of the CA keys – is mitigated by the use of HSM. Even if you own the system connected to the HSM, you can’t get the keys out.
One might say – what if you compromise a system that can connect to the HSM and use that as a base to exploit vulnerability in the HSM? That assumes that the infrastructure is already owned by someone else – hardly they will need to spend time running the research project that is finding a vulnerability in HSM. And the trivial solution is keeping the HSM, not the client system, offline.
Technology evolves. Offline root CA is just one of those obsolete ideas that are labeled the “best practice” in hope that there will be no critical analysis.