It’s OK this is a lot less hard going than the Crypto page. But I think it’s important to be a bit comfortable with the terms and how the generics work in order to understand what’s written in this page.
I call Digital Certificates : ‘passports’ really.
Part of the training program I helped to write about PKI explained this really
well, if I manage to find it again I’ll post it.
Think about what a passport is, its proof of identity which is associated to a country. Hopefully using security techniques to prove the authenticity in that the passport hasn’t been forged.
Digital certificates are literally no different, they show an identity associated to a trust highearchy using cryptography to prove the authenticity.
Go back to the Crypto page and think about the public and private keys, and that the private key should only be held by you….
If the private key should only be held be you then it would be fair to assume that your public key can identify you as the private key holder. But just with the keys alone, you can’t unless somehow it’s linked to an identity.
Digital Certificates are a way of showing the identity of the entity that holds the private key of the corresponding public key within the certificate itself. It’s a bit like saying your photo and name in the passport is only held by you so it must be you. And since it’s got a country’s crest on the front, they are vouching your identity as a citizen.
So your certificate will contain some information about you, your public key and it lifespan etc… but at the end of the day, anyone could just replace your key with theirs, this is called a ‘man in the middle’ attack.
But if the information within your application – Public key, info about you etc… and this is then signed by a root certificate – this is like then putting the country’s crest on the passport.
Who ever is identified in the Root Certificate is happy that they have made checks about your identity to a level that they are happy to say that you are part of their group, or trust model.
If I go through what happens to make a digital certificate, then we can go into what they look like and what’s contained in them. You can go to many sites which offer trial certificates, basically they all follow the same type of process.
You visit the site and navigate to apply for a certificate, the site will ask you for personal information such as your name, address etc… your computer will generate a public and private key pair for you (how nice). Your Private key is stored in either the hidden registry, a token (USB Token or SmartCard) or database never to see the light of day until you need it.
The public key on the other hand will be sent to the CA as part of your application. And then at the end of the application the site you are at will collect the info and save this in a database.
Depending on how much they care if you are who you say you are, they will conduct checks on the information to a level that they are happy with (this is set out in the CPS – Certificate Practice Statement) and then format the information that goes into a digital certificate request using PKCS #10. PKCS is Public Key Crypto Standards, and #10 is used to format the requests.
The request will contain, something called a DN or Distinguished
Name, this is a standard way of being able to identify an entity.
CN = Common Name
O = Organization
OU = Organizational Unit
L = Location
ST = State
C = Country (As defined in an ISO Standard for Country Codes)
E = Email
G = Given Name
So mine would be ” CN=Graham Dunnings, O=My Company,
OU=My Department, L=My Town, ST=Hampshire, C=GB, E=graham@dunnings.net,
G=Graham M Dunnings “
Using this, it ‘distinguishes’ me from any other identity that may exist, and if it doesn’t you can add more OU fields until you do. For personal certificates, its normally Email addresses that help the most. Unless its for a webserver where the CN would be the servers DNS name… ie. www.dunnings.net
So this DN is then added to other information about what type of things I want to use the certificate for, i.e. Email encryption, authentication, code signing etc… these are formatted using OID’s called Object IDentifiers, which there are hundreds of thousands of (for general computing) but certain ones mean certain things in the certificate requests.
So it’s my DN, my Public key which was collected at the site (normally called the RA – Registration Authority), the uses that I want for my certificate and things like validity period.
Then it’s cryptographically signed by a private key belonging to the issuer (or Root Certificate). This then creates a string that contains all my information, and the information of the issuer. You can see my information in a certificate called “subject” and the issuers info is under “issuer” both of these are displayed as DN’s.
Depending on the security of the Issuer (or CA – Certification Authority) the private key is normally held on kit called HSMs – Hardware Security Modules, these are shit hot bits of kit that store Crypto keys in a secure way (read up on FIPS 140-3), so say if I nicked it and tried to break into it, the likelihood of me doing so without destroying either the box or the keys is so remote, I’d have more chance winning the lottery without actually buying a ticket.
Once signed and you get the encoded certificate, this is written back the their database and then you can either go and collect it and go through an installation process, or they will send it to you in an installation Email. – Job done.
On any windows computer, do a search for .cer or .crt then right click and open with notepad, you’ll see what a certificate looks like encoded. There again, if you can live without that type of boredom – don’t.
Have a look at what a digital certificate looks like in IE.
In a certificate viewed in IE5, if you view the certificate
and select the Public Key (see below)
Now think back to the Crypto tutorial and think about asymmetric keys, the public and private key… I said that the public key was given out, but see the below to what it all means… Its in BASE64 which is a way of storing/displaying information in a format that doesn’t look like complete crap to the untrained eye, well in either format to the untrained eye, both will look like garbage, just a little more pretty.
The structure is in ASN.1 which is a way of formatting data in a way that is meaningful to the computer that is processing it – I’ll explain a little more about what the below ‘crap’ is…
3048 0241 00D0 51DF E628 7459 3D62 23EB 3A11
B638 0F79 D341 5CBA 40EB 60A0 772E E8F0 2C64
6C14 BDBE 984B BFBF 977C 7F1E 2734 406E 9AD2
74C0 8A6F D921 24D0 D54A 60EB 6BCA CB02 0301
0001
Looking at the string above, see below for what the different numbers represents: –
30 – This denotes a “Constructed String of Unknown Length” (String)
48 – The Length of the “String” in (Hex) = 72 in Decimal
02 – This denotes that the String is an Integer (no decimal places)
41 – This denotes the length of the Integer in (Hex) = 65(octets) in Decimal
And from the 00D0 to the end of CB02 on the 4th Line represents the actual Public Key and the rest of the string means: –
02 – This denotes that the number is an Integer (no decimal places)
03 – This denotes the length of the Integer in (Hex) = 3(octets) in Decimal 010001 – This denotes 65537, used as your E for the RSA algorthim. (Yes its always the same)
There are documents that CA’s can post, the most relevant ones are the CPS and a Certificate Profile, a Certificate profile gets all technical about what the certificate is made up from.
My thesis for my MSc was about simplifying what they had as a “cross-certification” PKI, basically you letting someone else sign your root. To me it was overly messy and with my view on them as passports, to me it should have been more simple – why not just have a Treaty, we have been using them since Henry VIII issued the warrant (read the front page of your Passport – “… allow the bearer to pass freely…”). When you travel other countries accept that as there are Treaties in place as they can Trust the right levels of authentication have taken place on the holder(Now it’s all electronic and biometric data related, let alone the number of sneeky security controls in the paper – did I mention our PKI company was bought out by De La Rue who still print passports and have some really neat tricks). Anyway, back then there was an RFC 2527 called Certificate Practice Statements and Certificate Policies, basically setting out how you set it up. If two parties can stick their CPS’s side by side and either include or exclude into one single document, it’s a treaty! Then you can install each others Root without the technical complications of additional Root certs and let alone the complications of rolling over Root certificates.
Also about the same time, another brighter spark beat me to it, a student at Berkley Uni in the US came with a ‘Bridging Policy Statement’, basically the same idea I had, they published when I was still writing mine but was unaware they had for a while. I kinda liked their name for it too 🙂 Respect to them.
This is just a quick overview without going into ‘too’ much detail, I could list all the RFC and other standards that are used from one end of the process to the other, but I’ll save you from that for now, I may write another page to explain all that.