Terms of Use For FixedByVonnie

By proceeding to access fixedByVonnie.com, you expressly acknowledge, and agree to, all of the following:

fixedByVonnie.com is a personal website and blog owned by Security Plus Pro LLC, which is being presented for informational purposes only. The views on this website are solely those of the website owner (and not those of any employer or of any professional associations affiliated with the website owner).  Any views expressed in this website and any information presented on this website, or in any of its blog entries, should not be relied on for any purpose whatsoever other than as the personal opinions of the website owner.  The website owner expressly disclaims any and all liability for any information presented on this site.  The owner of this website and its blog posts shall not be held liable, and shall be held harmless, for any errors or omissions in any information or representations contained in this website, or in any of its blog entries.  The website owner also expressly disclaims any liability for the current or future availability of any such information. The website owner makes no representations as to the accuracy or completeness of any information on this website or which may be found by following any link on this website. The website owner shall not be held liable for any losses, injuries, damages, claims, or causes of action, from the display or use of any information on this website or in any of its blog entries. If you use the information on this website, or on any of its blog entries, you do so solely at your own risk.

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

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.

Trusted Root Certificates on Mac

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.

Manage Root certificates

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.

The trusted root certificate

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.


Connect with Vonnie on Twitter

Posted in Mac OS X 10.10 Yosemite, Mac OS X 10.8 Mountain Lion, Mac OS X 10.9 Mavericks, Windows, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Vista, Windows XP Tagged with: , , , ,