markwilson.it

Public key infrastructure (PKI) is one of those things that sounds like a good idea, but which I can never get my head around. It seems to involve so many terms to get to grips with and so, when Steve Lamb presented a “plain English” PKI session at Microsoft UK a few weeks back, I made sure that I was there.

Steve explained that a PKI can be used to secure e-mail (signed/encrypted messages), browsing (SSL authentication and encryption), code (authenticode), wireless network connectivity (PEAP and EAP-TLS), documents (rights management), networks (segmented with IPSec) and files (encrypted file system).

Before looking at PKI, it’s necessary to understand two forms of cryptography – symmetric and asymmetric. I described these last year in my introduction to IPSec post.

The important things to note about public key cryptography are that:

• Knowledge of the encryption key doesn’t give knowledge of the decryption key.
• The receiver of the information generates a pair of keys (either using a hardware security module or software) and publishes the private key in a directory.
• What one key does, the other undoes – contrary to many texts, the information is not always encrypted with the recipients public key.

To some, this may sound like stating the obvious, but it is perfectly safe to publish a public key. In fact, that’s what a public key certificate does.

Having understood how a PKI is an asymmetric key distribution mechanism, we need a trust model to ensure that the public key really does belong to who it says it does. What if I were to generate a set of keys and publish the public key as my manager’s public key? Other people could send him information but he wouldn’t be able to read it because he wouldn’t have the private key; however I would have it – effectively I could read messages that were intended for my manager.

There are two potential methods to ensure that my manager’s public key really is his:

• One could call him or meet with him and verify the fingerprint (hash) of the key, but that would be time consuming and is potentially error-prone.
• Alternatively, one could employ a trusted third party to certify that the key really does belong to my manager by checking for a trusted digital signature on the key. The issue with this method is that the digital signature used to sign the key needs to be trusted too. Again, there are two methods of dealing with this:
  • A “web of trust” model, such as Phil Zimmermann‘s pretty good privacy (PGP) – upon which the GNU privacy guard (GPG) on Linux systems was built – where individuals digitally sign one another’s keys (and implicitly trust keys signed by friends/colleagues).
  • A trusted authority and “path of trust” model, using certificate authorities (CAs), where everyone trusts the root CA (e.g. VeriSign, Thawte, etc.) and the CA digitally signs the keys of anyone whose credentials have been checked using it’s published methods (producing a certificate). One CA may nominate another CA and they would automatically be trusted too, building a hierarchy of trust.

Most CAs will have multiple classes of trust, depending on the checks which have been performed. The class of the trust would normally be included within the certificate and the different levels of checking should be published in a document known as a certificate practice statement.

The analogy that I find useful here is one of writing and signing a cheque when paying for goods or services. I could write a cheque on any piece of paper, but the cheques that I write are trusted because they are written on my bank‘s paper – that bank is effectively a trusted CA. When I opened my account the bank would have performed various background checks on me and they also hold a reference of my signature, which can be checked against my cheques if required.

The padlock that indicates a secure website in most browsers also looks a bit like a handbag (UK English) or purse (US English)! The Internet Explorer 6 version looks like this and the Firefox 1.5 version is like this . Steve Lamb has an analogy for users that I particularly like – “it’s safe to shop where you see the handbag”; however, it’s also important to note that the padlock (not really a handbag!) just means that SSL security is in use – it doesn’t mean that the site can automatically be trusted (it may be a phishing site) so it’s important to examine the certificate details by double clicking on the padlock.

Each verification method has its own advantages and disadvantages – web of trust can be considered more “trustworthy”, but it’s time-consuming and not well understood by the general public – CAs, whilst easy to deploy and manage, can be considered to be the tools of “Big Brother” and they have to be trusted implicitly.

Digital signatures work by calculating a short message digest (a hash) and encrypting this using the signatory’s private key, to provide a digital signature. The hash function should result in a unique output (although it’s theoretically possible that two messages could produce the same hash as a large volume of data is being represented by a smaller string) – the important point to note is that even the tiniest of changes will break the hash.

Upon receipt, the recipient uses the signatory’s public key to decrypt the hash. Because the hash is generated using a one-way function, this cannot be expanded to access the data – instead, the data is transmitted with the signature and a new hash calculated by the recipient. If the two hashes match then the integrity of the message is proven. If not, then the message has almost certainly been tampered with (or at least damaged in transit).

Certificates are really just a method of publishing public keys (and guaranteeing their authenticity). The simplest certificate just contains information about the entity that is being certified to own a public key and the public key itself. The certificate is digitally signed by someone who is trusted – like a friend (for PGP) or a CA. Certificates are generally valid for a defined period (e.g. one year) and can be revoked using a certificate revocation list (CRL) or using the real-time equivalent, online certificate status protocol (OCSP). If the CRL or OCSP cannot be accessed, then a certificate is considered invalid. Certificates are analogous to a traditional passport in that a passport is issued by a trusted authority (e.g. the UK passport agency), is valid for a number of years and contains basic information about the holder as well as some form of identification (picture, signature, biometric data, etc.).

X.509 is the standard used for certificates, with version 3 supporting application-specific extensions, (e.g. authentication with certificates – the process that a browser will follow before displaying the padlock symbol to indicate that SSL is in use – authenticating the server to the client). Whether or not this certificate is issued by an external CA or an organisational (internal) CA is really a matter of choice between the level of trust placed in the certificate and how much the website owner is prepared to pay for a certificate (it’s unlikely that an external certificate will be required for a secure intranet site, whilst one may be expected for a major e-commerce site).

The SSL process works as follows:

1. The browser (client) obtains the site (server) certificate.
2. The digital signature is verified (so the client is sure that the public key really belongs to the site)
3. To be sure that this is the actual site, not another site masquerading as the real site, the client challenges the server to encrypt a phrase. Because the server has the corresponding private key, it can encrypt the phrase and return it to the client.
4. The client decrypts the phrase using the public key from the certificate – if the phrase matches the challenge, then the site is verified as authentic.

Most certificates can be considered safe – i.e. there is no need to protect them heavily as they only contain publicly available information. The certificate can be stored anywhere – in a file, on a USB token, on a memory-only smartcard, even printed; however private keys (and certificates that include them) are extremely vulnerable, requiring protected storage within the operating system or on a smartcard with cryptographic functionality (see below). Windows 2000 Server and Windows Server 2003 include a CA which can be used to issue and store certificates, especially within a company that is just looking to secure its own data. The Windows Server 2003 CA even supports auto-enrollment (i.e. where a certificate request is processed automatically), but what if the administrators within an organisation are not considered trustworthy? In that case, an external CA may be the only choice.

Most organisations use more than one root key for signing certificates. This is because it does not scale well, can be difficult to manage responsibility for in a large organisation and is dangerous if the key is compromised. Instead, certificate hierarchies can be established, with a CA root certificate at the top, and multiple levels of CA within the organisation. Typically the root CA is installed, then taken offline once the subordinate CAs have been installed. Because the root is offline, it cannot be compromised, which is important because complete trust is placed in the root CA. With this model, validating a certificate possibly involves validating a path of trust – essentially this is just checking the digital signature but it may be necessary to walk the path of all subordinate CAs until the root is reached (or a subordinate that is explicitly trusted). Cross certification is also possible by exporting and importing certificate paths between CA hierarchies.

The list of trusted root CAs increases with each Windows service pack. Some certificates can be obtained without payment, even those included in the list of Windows’ trusted root CAs. Whilst these are as valid as any other certificate, they are unlikely to have undergone such stringent checks and so the level of trust that can be placed in them may not be deemed sufficient by some organisations. If this is a concern, then it can be cleared down from within the browser, using group policy or via a script – the only client impact will be a (possibly confusing) message asking if the certificate issuer should be added to the list of trusted authorities when a site is accessed.

Smartcards are often perceived as a useful second factor for authentication purposes, but it’s useful to note that not all smartcards are equal. In fact, not all smartcards are smart! Some cards are really just a memory chip and are not recommended for storing a private key used to verify identity. More expensive smartcards are cryptographically enabled, meaning that the key never has to leave the smartcard, with all processing done on the smartcard chip. Additional protection can also be included (e.g. biometric measures) as well as self-destruction where the card is known to have been compromised.

It’s worth noting that in the UK, organisations that encrypt data and do not have the means to decrypt it can fall foul of the regulation of investigatory powers (RIP) act (2000). There is an alternative – leaving the keys in escrow – but that is tantamount to leaving the keys with the government. Instead, the recommended practice for managed environments with encryption is to store keys in a location that is encrypted with the key recovery operator’s key – that way the keys can be recovered by an authorised user, if required.

After attending Steve’s session, I came away feeling that maybe PKI is not so complex after all. Steve’s recommendations were to set up a test environment and investigate further; to minimise the scope of an initial implementation; and to read up on certificate practice and certificate practice statements (which should be viewed as being more important than the technology itself if defending the trustworthiness of a certificate in court).

For anyone implementing PKI in a Microsoft infrastructure, there’s more information on PKI at the Microsoft website.