Crypto 201: Public Key Infrastructure (PKI) – Cryptography for smarties (Part 2 of 3)

Ahh, the Public Key Infrastructure.  It’s sounds monolithic doesn’t it?

That’s because it is.  Don’t try to understand it by yourself. You need an expert.  You need Vonnie.  You need to read on playa.

In the last article in this three part series, I ended with a tantalizing question: how do we know the digital certificate signing isn’t forged by a hacker?

The problem is that it’s basically impossible for someone to forge the Versign signing.  Why?

Now pay attention here because this took me years to understand:

The Verisign signature; it’s name, is encrypted with Verisign’s private key.

“So what!”  You retort.  “How does that prove anything?”

Well, think about it.  This means the only thing that can decrypt Verisign’s signature is Verisign’s public key.  Slow down and reread that because it took me a while to get this.  Maybe I’m a slow learner or just stupid but I didn’t get this right way.

Every web browser in the world has a list of trusted CA’s built into the browser.  Verisign is in the list of trusted root CA’s.  So every browser has Verisign’s public key.  It’s public.

So let’s think this through: if your browser can decrypt the signature with Verisign’s public key and see the Versign name inside, then you know for certain that the certificate is genuine because no one else on the planet has Verisign’s private key!

I know this is deep, but this is how it works.  Anyone can genreate a self-signed certificate but unless it’s validated by a trusted CA it doesn’t mean anything.

The mighty Certificate Authorities

It all comes down to the Certificate Authority (CA).   There are lots of CA’s on the web. And the complex collection of these trusted servers is known as the Public Key Infrastructure. (PKI)

Every browser on your computer contains a list of CA’s that it trusts.  These CAs are built into the browser; Thawte, GoDaddy and Verisign are examples of well-known and trusted CA’s.

On your Mac, you can see the trusted root certificate store by pressing Command + Space and typing “keychain access“. Click Certificates in the bottom left corner of the screen to see all the root certificates trusted by your browser.

On a PC, just mash the Windows Logo key and type Managed Computer Certificates.

Then in the left pane, expand Certificates – Local Computer and drill down to Trusted Root Certificate Authorities and click the Certificate sub folder.

So before Bank of America could do online transactions, it would send its public key to a trusted Certificate Authority, such as Verisign.

This is technically called a Certificate Signing Request (CSR) and is usually done using the Public Key Cryptography Standard #10. (PKCS #10)  The CSR comprises all the relevant details of the bank so that the CA can begin its investigation.

Verisign would verify that Bank of America is actually a legitimate bank.  It might require the bank to fax or mail legal documents proving that it is a real company.  Or Verisign might require proof that Bank of America is authorized to function as a bank. Verisign could also require the senior staff of the bank to show up in person for a face to face meeting.  Once Verisign validates that the Bank of America is the real deal, it will issue a digital certificate to bank in what’s know as the X.509 format.

This is just a file with a bunch of certificate information in a standard format.  Here’s what it looks like on my Mac.

The most important data attribute is the 256 byte public key listed at the bottom of the window.

So lets look at a few of these fields.  You’ll see a version number and a serial number in the cert.  The serial number is important because if a hacker filches the private key from the Bank of America, he could use it to dupe customers into forfeiting their confidential information.

So the bank would contact its CA and say:

Hey guys, this is embarrassing but we were hacked.  Someone stole our private key.  We regenerated a new public/private key pair but need some help.  Can you quickly reissue a new digital certificate and add the compromised certificate to a special reject list?

The CA says:

Sure thing, we’ll revoke the bad cert and add it to our certificate revocation list (CRL).  Now your customers can check this list to see whether your certificate is valid.

You could check the CRL or use the Online Certificate Status Protocol (OCSP) to get a quick response from the database. Using OCSP to query a database is faster the the CRL but it’s also vulnerable to a man-in-the-middle attack so it’s not ideal.

---

So the serial number in the X.509 format makes it easy for the CAs to track and revoke bad certs.

What else is in the certificate? The algorithm is there.  Along with the hash (MD5 or SHA) and issuer.

As long as the issuer is from a valid source; in other words, it’s from a company that your web browser trusts, your browser will use the public key in the X.509 cert to encrypt traffic.

The subject is also in the digital signature along with the banks URL.

The Bottom Line

Are you starting to get the hang of this Public Key Infrastructure thing?  It’s not so bad right?

Yeah right.  It’s still crazy.  I still have a hard time with it when I start ruminating on public and private keys but the point is that the entire system is built on trust. Everyone trusts that the private key really is private.  Everyone trusts that it wasn’t compromised or that if it was, it was posted to a public Certificate Revocation List.

We’ll finish up the series tomorrow with a little talk about invalid certificates and we’ll look out how malware can trick your hapless browser into installing those invalid certificates.  Try to guess what happens if your browser starts trusting a cert issued by Mr. Hacker?  Ha… yeah – it sucks.

Stay tuned tomorrow.