Key Management, Authentication and Identity Management

Key Management

While cryptography enables Alice and Bob to talk secretly they still need some way to exchange the shared key first, so that only they know this key and other's don't. In general this is a hard problem to solve. Alice and Bob could exchange this shared key offline, e.g., by sending a letter to each other, but this does not scale. They could also use public key cryptography: Alice could choose the shared key and encrypt it with Bob's public key - only Bob would be able to read it. This works but we are interested in exploring if there are any other ways to securely exchange keys. Two main approaches we will explore are Diffie-Hellman Key Exchange and Key Exchange with a Key Distribution Center.

Diffie-Hellman Key Exchange

In Diffie-Hellman Key Exchange Alice and Bob want to exchange a shared secret in a "room full of people" that can hear all their messages. How can Alice and Bob end up with a secret that only they know? They first agree on two numbers g and n, n should be large. Alice chooses a random number a and sends ga mod n. Bob similarly chooses a random number b and sends gb mod n. Now Alice takes what she got from Bob, raises it to power a and ends up with ga*b mod n. Similarly Bob takes what he got from Alice, raises it to power b and ends up with the same shared secret. The eavesdroppers cannot calculate this secret because they don't know a and b.

Key Exchange with a Key Distribution Center

Let us assume that there exists a Key Distribution Center (KDC) that both Alice (Client - C) and Bob (Server - S) trust and they share keys with this KDC - this means that there already exist KKDC,C and KKDC,S. Client sends a request to KDC with its own identity and that of a server - C, S. The KDC generates shared key KC,S and sends to the client EKKDC,C(S,KC,S) and to the server EKKDC,S(C,KC,S). The message sent to the server is called a ticket. KDC can also give this ticket to the client to provide to the server on their first communication.

Do you have to memorize all this information? No. You can reason about why it is there and thus infer what should be in messages. The client must send its and server's identities to KDC so KDC knows which keys to use to encrypt the replies. The reply communicates the shared key KC,S to both parties. It must be encrypted, otherwise someone could snoop it from the network. The replies are encrypted so that only client and server can read them. Why are identities of the other party in the messages? They have to identify who this shared key applies to, who is the other party holding the same key.

This simple KDC-based algorithm has a problem - Mallory could capture the messages from KDC to C or to S and replay them at will. This would either force C and S to use the same secret for a long time, if both second and the third message are replayed, or it would cause C and S to have different ideas about which shared key they are using, if only the third message is replayed.

A way to fix replay problems is usually to introduce a sequence number, a timestamp or a random number, called nonce into request messages. The replies then must carry this number of some known transformation of this number, otherwise they are considered a replay.

Needham-Shroeder Key Exchange

Needham-Shroeder Key Exchange protocol uses nonces to handle replay problems. In the first step the client asks KDC for a shared key to talk to the server and includes in this request nonce N1 - the complete request is N1, C, S. KDC replies sending back the nonce N1, server's identity S, the shared key KC,S and the ticket EKKDC,S(C,KC,S), all encrypted with KKDC,C. This message cannot be replayed because it includes the nonce that enables the client to check if it is fresh.

The client now needs to send the ticket to the server in a way that prevents replay. The client will include in the message a nonce N2 encrypted with the shared key KC,S. The server needs to decrypt this message, extract the nonce and return its transformation to the client - N2-1, also encrypted with KC,S. Why the transformation? Because if the server sent back the same number Mallory could just capture the message sent by C and return it back to C, no need to decrypt it. Why does the reply need to be encrypted? Because we want to ensure that Mallory cannot just send an arbitrary message to S at this point and get it decrypted.

As the final step S can send to C a nonce N3, and C can return its transformation N3-1. Both of these messages are encrypted with KC,S. Figure below combines this step with the previous one but they could be performed separately as well.

What if the attacker somehow compromised an old session key KC,S plus captured the ticket that carried that key? He could perfom all the steps between C and S and force S to use an old session key. To avoid this we need to use timestamps in tickets and ensure that tickets expire.

Kerberos Key Exchange

Kerberos introduces two changes to Needham-Shroeder protocol:
  1. It splits the KDC functionality into Authentication Server (AS) and Ticket Granting Server (TGS). This means that the user needs to perform two exchanges to receive a ticket to talk to the server S - (1) authenticate themselves with AS and obtain a ticket to talk to TGS and (2) ask TGS for the ticket to talk to S. Figure below illustrates this process.

  2. It adds timestamps to requests and expiration time (timestamp + lifetime) to replies to ensure that these expire after certain time. The timestamp in the request serves like a nonce.

We will try from this easy-to-remember description to infer how the protocol works, so that you don't have to memorize all the details directly. Just like before ticket requests hold client identity and server identity. The request to AS is for a ticket to TGS so it has username, TGS, timestamp1.

AS looks up user's password, generates a shared key for the user and TGS and returns the ticket and the shared key to the user - all encrypted with a key derived in a known way from the user's password. Let's start with the ticket. Like before the ticket holds client's identity C, shared key KC,TGS and we add timestamp and lifetime to it to ensure expiry. This is all encrypted with the key AS shares with TGS. The complete ticket looks like this: EKAS,TGS(C, KC,TGS, timestamp2, lifetime2). AS also returns to the user the shared key and the TGS identity, all encrypted with the key user shares with AS, like this: EKC, AS(TGS, KC,TGS, timestamp2, lifetime2).

We now repeat this cycle once again to ask TGS for a ticket to talk to S. The request again has the client and the server identity C, S and a timestamp, and is accompanied by the ticket the client got from AS. Some of these elements will have to be encrypted and some can go in clear. The client encrypts C, timestamp3 with the key it shares with TGS. This authenticator EKC,TGS(C, timestamp3) serves to authenticate the client to TGS - proving that the client has the same KC,TGS that is in the ticket and that the request is recent. The rest of the message - S and the ticket to TGS can be sent in clear.

The TGS retrieves the shared key from the ticket, decrypts the authenticator, generates the shared key for the client and the server - KC,S, and sends to the client that key and the ticket. The ticket for the server looks identical to the ticket for TGS except that it holds elements specific to the server like this: EKS,TGS(C, KC,S, timestamp4, lifetime4). TGS also returns to the client the shared key and the server's identity, all encrypted with the key client shares with TGS, like this: EKC, TGS(S, KC,S, timestamp4, lifetime4).

Finally the client sends the server's ticket to S to ask for service, and an authenticator: EKC,S(C, timestamp5). The figure below outlines all the messages.

Public Key Exchange

While everyone can obtain someone's public key the challenge is how to verify that the key really belongs to the claimed identity. For example, suppose Alice wanted to talk to Bob and asked him for his public key. On the path, Mallory intercepts this message and sends her public key back to Alice claiming that it belongs to Bob. How can we help Alice detect this?

One way is to have a trusted third party, Trent, sign the Bob, KPubBob information with its private key. This signed information is called digital certificate and it looks like this: EKPrivTrent(Bob, KPubBob). When Alice receives this she uses Trent's public key to decrypt the message and retrieve Bob's public key. Trent - the Certificate Authority must be someone that both Alice and Bob trust, and whose public keys are easy to obtain and verify. One way to ensure this would be e.g., to distribute public keys for well-known Certificate Authorities with OS installations or with browser binaries.

Certificate-Based Key Exchange

This protocol combines public-key authentication and verification with shared key exchange. Alice wants to talk to Bob and wants to exchange a shared key with him, because symmetric crypto is much faster than asymmetric crypto. She chooses a nonce (to authenticate Bob) and sends it to Bob along with her certificate. She cannot choose the shared key because she has no way to send it secretly to Bob - she doesn't have his public key. Bob chooses the shared key, encrypts that and the nonce with Alice's public key (for confidentiality) and signs everything with his private key (for integrity). He sends this and his certificate to Alice. She verifies the certificate and obtains Bob's public key. She then decrypts the message, verifies Bob's signature on the message, and verifies the nonce, and starts communicating with Bob using the shared key.

Pretty Good Privacy - PGP

Since it is sometimes hard finding a Certificate Authority that both Bob and Alice trust, PGP introduces the idea of having multiple certificates issued by various authorities. Alice would send to Bob these multiple certificates and Bob would choose one or a few that are issued by authorities he trusts. The good side of PGP is that now Bob and Alice need not agree on a single trusted authority. The down side is that this increases the size of messages they need to exchange before they trust each other's public keys.

SSH

SSH protocol lets users set up passwordless login. The user needs to generate a private/public key pair (or use their existing ones), log in with their password and manually put the public key into a file in their account. The server will then attempt to authenticate the user with this public key and will not ask for a password anymore. The user can also authenticate the server. This authentication occurs by the user's computer remembering the server's host key, i.e. the public key of the machine associated with its IP address. On subsequent SSH sessions the client side of SSH program checks that the machine has the same host key. This is weak authentication because there is no way to verify the server's identity on the first access.

Recovery from stolen keys

Someone could steal Alice's private key. Should this occur she will want to revoke the public key associated with the stolen key so that the thief cannot impersonate her. She will also generate new public/private key pair and obtain new digital certificate.

One way to revoke keys is for the Certificate Authority to maintain a revocation list of public keys that match compromised private keys. Entities that want to talk to Alice would obtain and check this list after they receive Alice's public key, to ensure that the key is still valid. Such a list could grow very large very quickly and thus would be costly to transmit.

Another way to revoke keys is to force all keys to expire after some short time. This limits the amount of time a stolen key can be misused. But short expiration time means more key exchanges and is wasteful.

Another way to revoke keys is for the Certificate Authority to maintain a service that someone can query after they receive Alice's public key and verify that it is valid.