It’s easy to focus on the ‘I’ in PKI, treat it as just another piece of infrastructure, focus on quality of service, uptime, resilience – all the usual metrics. But what makes a PKI special is that it forms the trust anchor for all the systems and applications that rely on the credentials that it issues. Anyone building, and certainly anyone auditing those systems, will ask the question, ‘just how trustworthy are those credentials’. That’s not an easy question to answer, trust is like beauty, it’s subjective, contextual – it’s in the eye of the beholder.
Trust can be no more defined by technology alone than beauty can be defined by bone structure – there’s much more that makes up the overall picture. All security professionals are taught that security is as much to do with process and people as it is with technology and that’s certainly true with PKI. Organizations must consider procedural as well as technical aspects when planning their PKI deployment. Procedural aspects involve policies on access controls for administrators, separation of duties, dual controls for authorizing critical operations, system and software vulnerability scanning and potentially behavioural analysis to spot atypical activities and other ‘red flags’.
Once defined, all of this needs to be captured in a formal document. After all, if you’re selling trust it’s not good enough to say you are doing the right thing – you need to be able to demonstrate you are doing the right thing and that means defining what you regard the ‘right thing’ to be. The standard terms for such documents are the certificate policy and certification practice statement (CP/CPS). The preparation of these documents – often legally binding – describes how certificates are handled within the organisation and what mechanisms are in place to ensure that those practices are followed. Together the CP and CPS define the level of trust that the organisation can place in the certificates it issues.
Of course there’s more to PKI than just certificate issuance and the checks and balances that exist to control those processes. Just as much emphasis should be put on mechanism to limit the damage when something goes wrong. That brings me to the Achilles heel of PKI – revocation. One of the strengths of PKI is the ability for an application (a consumer of certificates) to validate the certificates that are presented to it, both online and offline. What is trickier is enabling the application not only to check that the certificate is valid but also that it has not been revoked. Traditional approaches like maintaining and distributing static certificate revocation lists (CRLs) are obviously going to slow down that ability and real time systems using the online certificate status protocol (OCSP) can really help provided the applications are online and, of course, that they bother to check!
Detecting that a breach may have occurred and getting the word out quickly in the form of a revocation can be crucial in limiting damage. In the era of targeted attacks the bad guys may only need a few minutes to exploit a breach. Then, once the panic has died down, comes the issue of forensics not just figuring out how a breach happened by determining which certificates have been affected – which are now suspect and which can still be trusted. This can have a huge bearing on the clean up costs. Like in chemical spill, knowing which chemicals are toxic and which are not is essential. Having to clean up everything, or reissue in this case, might be the difference being going bust and living to fight another day.
High profile breaches, such as DigiNotar, have shown that targeted attacks can corrupt systems and take advantage of weak controls to issue bogus certificates without ever stealing a key. It’s easy to see how the quest for an easy user experience can betray the ‘trust’ that is being delivered, which brings me back to the importance of defining what trust really means.
Finally, to return to the topic of cryptography, even given all this talk of process, we can’t forget that what makes PKI different from most systems is that it’s really all about the management of secrets. If someone can steal the key, the game is over and I’ll discuss that in my next post.
Part 1: What is a PKI and why is it important?
Part 2: Security considerations of a PKI