But what exactly is PKI?
If you don’t work in IT, chances are low you’ve come across the acronym “PKI.” You’re probably not familiar with the concept or – more likely – you’ve never even heard of it. And that’s no surprise, since PKI is designed to work as an actor in the background. The basic concept is rather simple, and the hype around it has long settled. Nevertheless, key management is a fundamental component of information security, which is why we thought we’d dedicate a few lines to explaining it in a way everybody can understand – even if you don’t work in IT.
Forget everything you thought a “key” was
PKI stands for Public Key Infrastructure. Each letter in the acronym reveals a little more about what it is we’re dealing with.
For better understanding and a didactically more careful approach to explaining PKI, we must start with the “K,” which stands for “Key.” In the field of cryptography, which is the science of sending secret messages (the word itself derives from the Greek kryptós for “hidden, secret” and graphein for “to write”), the term is used with a meaning slightly different from what you might expect.
Have you ever practiced cryptography? Sent a secret message to your crush in high school on a piece of paper, rendered unreadable for the eyes of your curious classmates?
You might have done something similar to the above illustration. The process of adjusting forward by three letters in the alphabet is called an algorithm in mathematical terms. In cryptography, the process of moving letters is called the cryptosystem; the number 3, in this case, is called the key.
Now imagine you tried to run the system illustrated above with a pen pal that lives thousands of miles away. It’d work – but only if at some point you managed to share the cryptosystem and the key with them. And that’s the problem – the “Catch-22,” if you will – of what we now call symmetric cryptography: You’d need a secure channel to share the key, but you cannot establish a secure channel until a key has been shared.
The 19th century Dutch cryptographer Auguste Kerckhoff made this very important observation about cryptosystems: “It [the cryptosystem] should not require secrecy, and it should not be a problem if it falls into enemy hands”. Nowadays, we know this as Kerckhoff’s principle and it’s essential in the practice of cryptography. However, this makes the secrecy of the key fundamentally important. Without that, an eavesdropper would know exactly how to decrypt your message.
“Public” keys – but not necessarily public access
Luckily the genius cryptographers Whitfield Diffie, Martin Hellman and Ralph Merkle developed a concept that would resolve this central issue of sharing a key over an insecure channel.
Picture this: Alice wants to send Bob an item by packing it in a small metal box, securing it with a padlock. Alice would have to pack her box, lock it with her padlock, and then send it to Bob. To unlock, Bob would need Alice’s key sent to him. But imagine this: Instead of Alice locking the box she sent with her own padlock, she uses the padlock of Bob to which only Bob owns the corresponding key. Bob doesn’t have to worry about sharing his padlock, since it’s only used to lock a box, not open it. This is great, since Bob can receive a package and open it without Alice or Bob ever having to share a key.
The comparison isn’t perfect, but it’s as close as we can come to providing a real-life example. In technical terms, this process of securing data is called public-key cryptography. Instead of the padlock and its key from our example, in public-key cryptography we’re talking about private keys and public keys. And unlike the padlocks, public-key cryptography works both ways: Public keys can decrypt encryption from private keys and vice versa. In addition, it’s virtually impossible to deduce a private key from the corresponding public key. This is based on a concept called “Trap-Door Functions” which goes far deeper into mathematic equations than we are going to cover here.
The takeaway is this: By each holding a public and a private key, Alice and Bob can communicate in perfect secrecy. They’re free to publish the public key (hence the name) and still have a guarantee of communications remaining confidential – as long as they watch the security of their private key.
What about the “I”? Identity? Integrity? Infrastructure?
Public-key cryptography was widely celebrated as revolutionary in the world of information security. Primarily because, as it turns out, by cleverly applying public-key cryptography, some guarantees could be made for the crucial aspects of both privacy and security. The three fundamentals of privacy and security have often been referred to as the “CIA-Triangle.” (This is quite ironic, as public-key cryptography at one point became the worst nightmare for the United States’ own Central Intelligence Agency, also known as the CIA.)
CIA in this context is short for Confidentiality, Integrity, and Authenticity. In other words: Preventing eavesdropping, ensuring a message cannot be altered, and verifying the sender of a message. We’ve explained how Alice and Bob keep their conversation confidential, so let’s look at the integrity and authenticity pieces. To cover integrity and authenticity we need to introduce two other terms: hashing and digital certificates.
Hashing is easily explained as taking the fingerprint of a file. A fingerprint is a unique identifier for a person. Yet, no matter the person, each fingerprint is (pretty much) the same in size and provides no information about the looks or character of the person. A document hash will have the same characteristics as a fingerprint: unique, uniform in size, and anonymous.
Digital certificates are attestations of identity for the owner of a certain public key (and consequently, the corresponding private key), much like passports are attestations of identity for a person. Alice can obtain a digital certificate from what is called a Certificate Authority (CA), just like she would when getting a passport from the passport office. She would need to prove her identity to a part of the CA called the Registration Authority (RA) just like she would have to use a birth certificate when applying for a passport the first time.
After the RA verifies Alice’s identity, it issues her public and private key pair. Since public keys need to be shared but are too big to be easily remembered, they are stored on digital certificates for secure transport and sharing. Since private keys are not shared, they are stored in the software or operating system you use, or on cryptographic hardware (e.g., a USB token or hardware security module otherwise known as an HSM) containing drivers that allow it to be used with your software or operating system. Since private keys remain private (ideally), we can be confident that any actions performed by Alice’s private key (such as decrypting a message or digitally signing a document – more on this below) were actually performed by Alice.
By combining hashing, digital certificates and public key cryptography we’re able to create a digital signature which will guarantee the integrity as well as authenticity of messages.
As you can see above, the process of signing and validating signatures combines the three elements. If the hash from the plain text and the result of decryption match, we know the message hasn’t been altered, thus guaranteeing integrity. If we use Alice’s public key successfully for decryption, we also know it must have been her private key used for encryption, thus guaranteeing authenticity.
This is why Public Key Infrastructure can be built on top of public-key cryptography. Remember how we discussed Alice getting a certificate from a CA? The beauty of PKI is that a CA will digitally sign Alice’s certificate with its private key, therefore guaranteeing that – before issuing the certificate – the RA did in fact verify her identity. Anyone can then validate the integrity and authenticity of Alice’s certificate by applying the CA’s public key for validation. The certificate associated with the CA’s public key is called a root certificate, making the CA a root CA.
Technically speaking, a CA can be created by anyone who has a home PC. Getting your CA to be publicly trusted, on the other hand, is a complicated endeavor, consisting of rigorous audits of authentication, security, and other vetting methods identified by WebTrust.org. As a result, only a select few CAs enjoy public trust recognition from browsers, operating systems, and other software programs. But a third-party CA offers much more than public trust: revocation services, timestamping authority, a deep understanding of the costs, knowledge, and manpower needed to secure the infrastructure and keep up with best practices, and in some cases, the ability to manage it all for you.
If you haven’t figured it out yet, GlobalSign is a trusted CA and has been for nearly 30 years. And since building a CA that complies with all the necessary rules to be publicly trusted requires some serious knowledge, you might also say we’re experts in PKI and public-key cryptography.
PKI has rightfully been called the “Swiss Army Knife of Information Security.” Seeing how it can be used to help construct systems around identity and access management, encrypted communication and digital signatures for documents and files, it’s hard to disagree.
Other PKI Resources:
Whitepaper: PKI for Critical Infrastructure
Webcast: PKI Automation for Mixed Endpoint Environments
Webcast: PKI – The Swiss Army Knife
