Analog5:002 Article 003

A primer on PKI

By: Cooper
Published: March 20th, 2007

Suppose you need to transmit a private message to someone across an untrusted network. What would you do?

Obviously you'll need to encrypt your message. But for that you need a key, and the receiving party needs to know about that key so they can decrypt your message. So you set up a meeting with this other individual, and you two decide on a key to employ. You both take this key back with you, and from that point on communicate in a secure manner by encrypting all you data using that one key.

This is called symmetric cryptography, the symmetry being that both parties know the key. The problem with this is that you need to trust the other party to keep this key secure. The assumption is made that no other person has access to this key, so when you receive a message encrypted with this key you trust it to have come from the other person. When it's only 1 key you have to worry about, this might still be doable. But what if you've got a network of people you need to stay in touch with in a secure way? All the people on this network need to be able to securely communicate with each other. Having a special key for communicating between 2 people in the network means each person's key repository will grow exponentially with the size of the network. Meeting with all these individuals personally to decide on a key becomes troublesome and may expose your relationship, and if someone loses his keys the fun can really start.

The solution lies in the use of asymmetric cryptography, also referred to as public key cryptography. The concept of asymmetric cryptography is that each individual has a private and a public key. When you want to securely transmit a private message to someone you can encrypt it using the receiver's public key. The receiver must then use his private key to decrypt the message. As he's the only person who has access to this private key, you know the message will remain secure while in transit. But since the public key is public in a rather literal sense of the word, what's to stop someone from intercepting your message, throwing it away, and sending a different message to the receiver, claiming to be you? The answer lies in another function of public key cryptography: signing. You can compute a signature over your message using your private key, and then attach it to the outgoing message. The receiver can then verify the contents of this message using your public key, and thus be assured that the message was sent you, and has also not been tampered with while in transit.

As always, there's a drawback to using public key cryptography. Typically the keys needed considerably longer than those needed by symmetric cryptography. More importantly, the algorithms used are considerably slower than their symmetric counterparts. One popular way of dealing with this last drawback is for the sender of the message to enrypt the message using a secure one-time key and a symmetric encryption algorithm. He then encrypts this one-time key with the public key of the recipient, and attaches it to the sent message. When there are multiple recipients, simply repeat this step for each recipient. The recipient can use his private key to decrypt the one-time key and use that to decrypt the actual message.

So now that you know the difference between symmetric and asymmetric cryptography, there's one more problem to fix. So you have this file that contains someone's public key. How do you know it's in fact HIS public key? Public keys are stored and transmitted as certificates, which combines the public key value with the name of the person the certificate belongs to. But people can still lie about who they are. So how do you know?

There are 2 ways to know. First is the old fashioned way of simply meeting in person, proving to eachother that you are who you say you are, and then exchanging self-signed public keys for future communication. You should add this certificate to your system's trusted key repository, or Truststore, to get your system to accept it for the encryption of outgoing messages and verification of signatures on received messages.

The other way to know is via a trusted third party. This trusted third party is called a Certificate Authority or CA. Instead of using self-signed certificates a person would sent the CA a certificate request, which contains his public key plus some additional, personal information about the individual. The CA would then verify this information and if he is satisfied the presented information matches that of the person requesting the certificate, he would use his private key to sign the certificate of this person. Now, this person can unsecurely send out this certificate, and the recipient can, using the public key of the CA, verify its signature to determine that this certificate belongs to you.

There are a number of big, commercial CA's out there that have very, very strict rules and procedures that you need to follow to get your certificate request signed. Their entire business is built around the idea that they are trustworthy so getting them to trust you takes more than just some money, a smile and a handshake. I'm sure people are familiar with Verisignas a CA, but there are a number of others, including Comodo and Hak.5 sponsor GoDaddy.

For some groups, using one of the big CAs simply isn't practical. It costs too much, the local, repressive goverment might look down on people that seek to prevent others, including law enforcement, to view their messages, and so on... An alternative is to simply assign one or several members of your community as a CA. The requirements to getting your certificate signed will probably be less but since the group is likely to be small there's a good chance people already eachother anyway. This last way of organising a CA has been coined the "Web Of Trust".

It's important to realise what signing someone else's certificate signifies. Chances are that in all but the most private of conversations, people will trust that a certain individual is person X because you as a CA said so, and they trust you. This is why, for this trusted third party thing to work, it's pivotal that you actually meet face to face with someone who can present you with sufficient identification that attests to his or her identity before you agree to sign their certificate. This is in fact what the signing parties are all about. You don't (or shouldn't) trust an untrusted distribution network like email to bring you certificates for signing. It could be anybody who sent you that stream of bits!

The one remaining unexplained thing in this is just what exactly PKI is. PKI is the abbreviation for Public Key Infrastructure, and it's the whole package of dealing with the distribution and management of public keys. The mechanism of assigning an person's identity via an intermediary like a CA or a trusted third party from your community. As asymmetric cryptography is such an integral part of PKI people often consider this part of PKI, but as it has very little to do with infrastructure, it really should not be seen as such.

If you want to start playing with certificates, look no further than the OpenSSL suite of programs. You can get them at this URL: http://www.openssl.org They only distribute their product in sourcecode form. Most Unixes come with OpenSSL pre-packaged by default, so look at your package manager to see if there are precompiled binaries for your platform. Behind the 'Related' tab on the left of the OpenSSL website you will find a link to precompiled binaries for the Windows platform.

The manual for these programs can be a bit daunting, so here are a few commands to get you started:

 openssl genrsa -des3 -out myname.key 2048

Generate a 2048-bit RSA key-pair (contains both the public and private key), encrypted using des3. The result will be stored in a file named myname.key and you'll be prompted for a passphrase:

 openssl req -new -x509 -days 1001 -key myname.key -out myname.cer

Create a self-signed certificate for this personal key. This certificate will remain valid for 1001 days, and be stored in a file named myname.cer. You will be prompted for the passphrase of your private key and a number of items like your country code, city, etc.

In order to sign other peoples' certificates, you need to set up a directory structure that is described in your openssl.cnf file, and create a new key-pair and certificate solely for your CA. You could use your own key-pair and certificate, but it's more secure to have one set for signing certificates and another for your day-to-day encryption and verification needs. The directory structure to create with the current version of OpenSSL's default openssl.cnf can be created with these commands:

	mkdir demoCA
	mkdir demoCA/newcerts
	mkdir demoCA/crl
    echo "" > ./demoCA/index.txt
	echo "01" > ./demoCA/serial

On Windows, those slashes should of course be replaced by backslashes.

 openssl req -new -key myname.key -out myname.csr

Generate a certificate request from our private key, to be sent to the CA for singing. You will be prompted for the same information as with the self-signed certificate, plus 2 extra fields which I left blank.

  openssl ca -policy policy_anything -cert ca.cer -in myname.csr

      -keyfile ca.key -days 360 -out result.cer

This is a single command that I split up over 2 lines. This command will process the certificate request in 'myname.csr'. It will display the information from the request to you, and ask if you really wish to sign it. You should try to verify the data presented to you before selecting yes. Afterwards it will ask if you want to update the database in which issued certificates are being tracked (this is used for certificate revocation, should that need arise). You should answer yes.

 openssl x509 -in result.cer -text

Display the contents of this signed certificate. When compared to the self-signed certificate created earlier you'll notice that the data in the signature field is different.

 openssl x509 -in result.cer -outform DER -out result.der

The certificates generated above are in the PEM format, but Windows tends to prefer the DER format for some uses. The above command transforms the certificate to DER format.

-Cooper