Part 4 of what currently still stands at a four part series. But I have high hopes for further posts. I was going to start off the intro to this blog by congratulating Jason on avoiding falling into the cliché trap of using Bob & Alice and all their cryptographic friends but you will quickly see, as I did, that this was a rather premature notion on my part.
As a side note; my Cryptography Lecturer at University was called Chuck. I’m quite surprised to see that “Chuck” is traditionally used as the bad guy that intercepts messages. I’m fairly sure he neglected to use his own name in the many slides he referred to this slightly weird bunch of fictional characters! Enough of my ramblings, Jason has a lot to say in today’s session:
If you have been reading the previous blog posts then you’ll know that Public Key Cryptography involves a Public Key which can be passed to whoever you want to give it to and a Private Key which you would never dream of passing to someone. If you haven’t already read the 3 posts preceding today’s, I suggest you have a look at these first as they build up and follow on.
You’ll also know that Public Key Cryptography can be used to offer:
So, how does all this work? Well imagine two people meeting up, let’s call them Alice and Bob. All cryptographers know Alice and Bob very well indeed. Alice and Bob meet up and want to exchange some encrypted data with each other. So, the conversation goes rather like this:
Alice : “Hello, my name’s Alice. Nice to meet you”
Bob : “Hello Alice, nice to meet you. I’m Bob”
Some pleasantries (geeks call this handshaking)
Alice : “Bob, wouldn’t it be good to be able to communicate securely?”
Bob : “Yes Alice. Let’s create some keys. Oh here we are. Have my PUBLIC Key called PuB”
Alice : “Thanks Bob. I’ll store PuB in my address book. Here’s my PUBLIC key PuA”
Bob : “Alice, that’s great – PuA’s going in my address book and I’ll be in touch. Bye”
Some more pleasantries (teardown)
After some time, Bob decides to get back in touch with Alice, so he generates a Symmetric Session Key (SKB), cracks open his address book, pulls out PuA and encrypts SKB with PuA. He then fires this over the network. Alice receives the package, retrieves her PRIVATE KEY (PrA) and uses it to decrypt SKB/PuA. So, Alice can see the B to A session key. She could reverse this process and then we’d have two security associations and they could exchange data two ways.
OK, two problems here (apart from a very wooden script) :
Let’s address the first of those problems first, because that’s a little simpler. Alice and Bob decided to store each other’s Public Keys in each other’s address books. That’s a great idea, but how about if they both had a shared address book which they could refer to? Outlook calls that address book the Global Address List. Now, all everyone needs to do when then want to exchange emails securely is to publish their public keys to the GAL and when they want to send a message, issue a simple query to the GAL for the recipient’s Public Key.
We’ve been talking about emails here, but the exact same principle applies to any other kind of public key. Some will be published to Active Directory and some will not.
The trust thing is an issue however, so let’s start looking at that. Typically if you ask me for my public key then what I’ll do is encapsulate it in a certificate. A certificate acts as a carrier for my Public Key. It’s a feature of a certificate that it will have:
These features allow us to put information into the certificate to better identify who I am and how long I should be trusted for.
SMS has always used certificates to identify the client but these are self-signed certificates. In essence the client says to the Management Point “Please trust me because I say that I’m trustworthy”. You can see this if you go into your certificates MMC and have a look in the SMS/Certificates section
You’ll see that the expiration date is, well a little longer than the expected lifetime of this laptop which I am using and if I open up one of these certificates, we'll see . . .
. . . The tell-tale signs of a self-signed certificate! Even though it says the certificate is not trusted and the issuer is the same as the subject, is this certificate good enough? Well the answer is probably – yes. This certificate is being used to digitally sign communications from the client to the Management Point in a mixed mode SCCM environment, so it’s likely that the other forms of authentication will also come into play. This changes in a Native Mode SCCM environment as you likely won’t have, for example a Domain Controller to authenticate your workstation.
So, what is Alice doing when she embeds her Public Key within a certificate? Well, in essence Alice is passing over the proof of her identity to a third party. What is Bob doing when he looks at Alice’s certificate? Well, he’s deciding that Alice is Alice not by trusting in Alice but by trusting the issuer.
It’s very much like a passport. When Angela (below) arrives at passport control and presents her passport, the choice of whether the border agent trusts Angela is not only that Angela looks like her photo (let’s call that her public key) but also that the passport is within its validity period and, crucially that the passport was issued by the United Kingdom Passports Agency. A decision has been taken by the country which Angela is trying to enter that British passports can be trusted. That’s not always the case – sometimes we need a visa to provide additional evidence of who we are (or an excuse for a country to racket visitors) and sometimes certain passports are de facto untrusted!
What’s all this known as in Microsoft Windows? If you’re still in your certificates MMC you’ll see a list of Trusted Root Certification Authorities. So, a Certificate Authority is some entity that you go to in order to help prove your identity.
When you install a copy of Microsoft Windows you will already have a list of TRCAs on your system, quite simply because someone, somewhere in Redmond decided that the list should contain certificates from GeoTrust, VeriSign, Go Daddy et al and not from Mikes-dirt-cheap-certs-4-U.COM. When your domain admin gets his or her hands on your system through Group Policies they can add internal CAs to the list and could, if they really wanted to add in Mikes-dirt-cheap-certs-4-U.COM into this list. So, ultimately who do you trust? The CA or the SA?
So, let’s say I wanted to start selling something online. Would you trust me with your credit card details? You wouldn’t? So, I am going to need to do something to prove to you that I am who I say I am. I’m going to go out and get a certificate from a Certificate Authority. There is a whole bunch of CAs out there, which one am I going to choose?
Of course, if all we are doing is something purely internal then we probably don’t need to go out and buy a certificate from someone else as we’ll be able to control the TRCA list internally and can add our own CA in via GPOs.
Let’s look at this at a well-known email provider. I went to login in to my emails and i got this:
Somewhere, some checks had been performed on the identity of Microsoft to say that they are who they say they are – Internet Explorer also kindly showed them as green so I am even confident. What happened here? Opening up the certificate I see some interesting things
Frist, I see that the Subject is the same as the website. That’s a good start. Then I see that the validity dates are good. Even better. I also see the Issuer Information VeriSign Class 3 Extended Validation. Let’s look at that a little more. In the Certification Path we can see that the certificate which Microsoft supplied us in fact also contains the certificate for the issuing CA AND the certificate for the CAs above that:
So, what we see here is that at VeriSign they have a ROOT CA and a subordinate ISSUING CA. The certificate of the issuing CA is issued and digitally signed by the ROOT CA. What about the ROOT CA’s certificate? Well, that’s self-signed – the ROOT CA is saying “you have to trust me because I’m the Root CA”
“Why should I trust the CA, in this case VeriSign?” Because they are open as to the steps they take to verify identity in The Issuer Statement – take a look for yourself.
The next question then I guesses is “Why should I trust the ROOT CA?” There, we’ll leave the discussion for now.
This post was contributed by Jason Wallace, a Premier Field Engineer with Microsoft Premier Field Engineering, UK