Computer Security Concepts for Understanding Certificates

Intended for:

Certificate users.

Scenario/Use case:

This article describes some computer security concepts to help you understand how certificates work.

Instructions:

Encryption is the coding of messages such that only those with the "key" to decode a message can read it. There are two types of encryption:

• Symmetric-key encryption.
• Asymmetric public-key encryption.
  
  

Symmetric-key encryption (used in Kerberos)

In symmetric-key encryption, each computer has a secret key (a code) that it can use to encrypt a packet of information before it is sent over the network to another computer. Symmetric-key requires that you know which computers will be talking to each other so you can install the key on each one. Symmetric-key encryption is essentially the same as a secret code that each of the two computers must know in order to decode the information. The code provides the key to decoding the message.

message = crypt(crypt(message))

For example: Take each letter and replace it by the one 13 letters down the alphabet. Call this "move13":

A = move13(N)

N = move13(A)

N = move13 (move13(N))

Asymmentric public-key encryption

In public key (PKI) technology, the encryption algorithms have a two-part identifier for each party: a public key and a private key. Information encrypted with the public key can only be read by using the private key (and vice versa).

The public key assigned to an identity is intended to be widely known since each person intending to communicate securely via PKI with a given individual needs to have access to that individual's public key. The private key is to be known only to the keyholder (or to his computer).

An encrypted message encoded with one of the keys can only be decoded with the other:

message = priv(pub(message))
message = pub(priv(message))

For example: (There's a better example in this short, informative cartoon introduction to digital signature and trust chains.):

1. Send your public key to Bob, but not to Joe. Encrypt a message using your private key. Send it to Bob and Joe. Bob can decrypt it using your public key and read it, Joe cannot read it.
2. Now send Joe your public key.
3. Bob sends you and Joe his public key. Then he sends a message encrypted with your public key (and his private key -- yes, doubly encrypted) to you and Joe. You can decrypt it with his public key and your private key (order matters), but Joe cannot read it. Joe would need your private key!
4. You feel sorry for Joe, and decide to re-encrypt the message with your private key and send it to him. He can now decrypt it with your public key and read it.

The concept of certificates has been created to bind public and private keys to some more recognizable identity (the certificate) and append a trusted signature. The subject named in the certificate (the issue) is assumed to be the only holder of the private key. The private key is what needs to be protected.

The system is only as good as the protection of that private key. Whoever possesses a private key can "become" that individual in all that regards PKI. There is no way to change protection of a private key after it's been stolen. For example, changing the password which encrypts the private key solves nothing, since changing the user's copy does nothing to the stolen one -- the stolen one is still valid. The private key itself must be changed, and hence the certificate associating the old public key to the identity must be revoked and a new one issued. Since identity in PKI is tied to a private/public keypair, this is nearly equivalent to establishing a new identity.

Hash Values

The key in public-key encryption is based on a hash value. This is a value that is computed from a base input number using a hashing algorithm. Essentially, the hash value is a summary of the original value. The important thing about a hash value is that it is nearly impossible to derive the original input number without knowing the data used to create the hash value. Here's a simple example. Add the digits or letter values, e.g.:

Public-key encryption is actually much more complex than this example, but that is the basic idea. Public keys generally use complex algorithms and very large hash values for encrypting, including 40-bit or even 512-bit numbers.

Digital Signatures

The signature of a digitally-signed message, certificate or other data consists of the hash of the data content encrypted with the sender's private key:

signature = priv(hash(message))

The recipient decrypts the signature and checks if it matches the hash of the message (which it can't "unhash"):

hash(message) = pub(signature)

Certificate Authority as Trusted Middleman

To implement public-key encryption on a large scale, such as what a secure Web server might need, requires a different approach. Getting a public key from somewhere doesn't ensure that anyone will trust it. We need a trusted middleman. This is where digital certificates come in. There is an independent source known as a certificate authority (CA) that issues the key and says "I, being a trusted authority, certify that the person presenting this key is so-and-so." How? The CA bundles into a document known as a "certificate" the following information: a description of who the person is, their public key, who the CA is, and an electronic signature of all of these items. (The private key is not in the certificate per se, but the CA issues files which contain the certificate plus an encrypted version of the person's private key.) Whenever the certificate holder presents his certificate to a service, the service's job is easy: If the service trusts the signing CA, the person gets in. If not, he's rejected.

Authentication vs Authorization and Security Tokens

Authentication answers the question "Who are you?". Authorization answers the question "What are you allowed to do?".

Upon authentication, you get some sort of security token. This token authorizes you to do certain things, like access protected data on a computer. You might need different tokens for different things.

Real world examples of security tokens: driver's license, credit card, and Fermilab ID badge.

Electronic examples of security tokens: Kerberos ticket (TGT), UNIX user id, and digital certificate.

Shared session Keys

Public-key encryption takes a lot of computing, so most systems use a combination of asymmetric public-key and symmetric key. When two computers initiate a secure session, one computer creates a symmetric key, called a session key, and sends it to the other computer using public-key encryption. The two computers can then communicate using symmetric-key encryption. Once the session is finished, each computer discards the symmetric key used for that session. Any additional sessions require that a new symmetric key be created, and the process is repeated.

An example of using session keys: To send data (e.g, an email message) to multiple recipients, you can send copies of the session key encrypted with different public keys, and then the message encrypted in the session key, as well.

See Also:

• Everything you Never Wanted to Know about PKI but were Forced to Find Out (A PDF by Peter Gutmann, U of Auckland). You don't actually need to know it all, but it's there if you're curious!
• SSL Certificates How To from the Linux Documentation Project.
• S/MIME Secure Email - A Beginners Guide.
  
• Using PKI from Dartmouth College.
• Wikipedia on Public Key certificate.
  
• Certificates at Fermilab.