Public Key Infrastructure (PKI) (Continued)

Within PKI, we have the certificate authority that creates the certificate, stores the certificates, and digitally signs the certificates. The registration authority, the RA, verifies the identity of entities requesting digital certificates. So this is the registration process. We typically have a directory of some kind, a database of some kind to manage all those different public/private keys. So we need some kind of management system and some kind of database to do that. We also need a certificate policy to say what kind of encryption is in use, how the PKI implementation works, in effect. The format of a certificate is based, usually, on the X.509 standard. So this is used in many different protocols, including transport layer security.

And this then becomes the basis for HTTPS. The certificate typically contains the following fields. So the structure has a version number, a serial number, a signature algorithm ID, an issuer name - we want to know who’s issued it - a validity period, a subject name, a subject public key, and it will contain information, lots of optional fields, and information about the signature algorithm that was used and a copy of the actual signature as well. So if trust is incredibly important with PKI, what happens when that trust fails? And so when we’re issuing public key certificates, these are created through the use of the private key.

This is asymmetric encryption: we have a public and a private key. So the public relates to the private. We need to protect the private. And the certificate authority to show that the certificate is genuine signs the certificate with their private key, which means anybody with access to their public key, which is trusted by most browsers, can ascertain that certificate was signed by the certificate authority. So if they’re private, if the certificate authority’s private key is compromised or is not well managed, we have a huge problem. And that’s exactly what happened to both Diginotar and also to RSA. Diginotar were a Dutch certificate authority. Their private key, their root certificate, was compromised.

And consequently, all certificates that they issued could no longer be trusted. They had to be revoked. And the company went bankrupt as a consequence. If your primary business is trust and your certificate cannot be trusted, there’s an immediate and a fairly significant problem. RSA had one of their private keys, their root certificate, stolen in a hacking attempt. And as a consequence, they had to revoke all of their PKI hard tokens, soft tokens - massive impact for them. They had to reissue, I gained 200 replacement tokens at no charge, and that was just for me. Worldwide, this was a significant financial impact for RSA and also potentially the impact to their reputation as well. So how does PKI work in practise?

Well, a sender creates a message that they want to be encrypted. The message is hashed, and the hash is encrypted with the private key of the sender. So if we have encrypted the message with the private key of the sender, the only person that can decrypt it is somebody with access to the sender’s public key. But because the sender’s public key is indeed public, that means pretty much anybody should be able to decrypt it. So a recipient can then decrypt that message. It can gain the hash and check that the hash matches the message. So we have a non-repudiation activity here.

We know that the source of that message was the sender because only the sender has access to their private key to perform the encryption. And because the hash checks out, we know that the integrity of the message that’s been transmitted has not changed. So this is a very powerful operation, and it works well without a central domain service, without requiring a trusted relationship between the two parties involved. The sender and the recipient don’t need to trust each other. Instead, they’re relying on the integrity of the certificate authority.

So PKI, for encryption purposes - just skipping back, this was digitally signing - this was the signature process for PKI. Encryption with PKI works differently. Here, the sender would create a message, and the message would be encrypted. But now we’d be using a different key. Now we’re going to encrypt the message with the public key of the intended recipient. The recipient can then decrypt the message because they have the corresponding private key. The plaintext is then restored.

So this is a very powerful model. Again, it allows for cryptographic operations, integrity operations, non-repudiation - very commonly used. And this is the backbone of HTTPS, our secure websites model.