Recently, a friend of mine asked a question about key exchange in SSL without encrypting the key. His question came after examining a Key Usage certificate extension setting in the certificate template. There are two options: Allow key exchange only with key encryption and Allow key exchange without key encryption. How it can be possible that the key is not encrypted??? Here is an image of the respective setting:

Abstract

Before I’ll explain the question, we need to become more familiar with the SSL subject.

When web browser connects to web server by using HTTPS address a lot of interesting things occur there collectively called SSL/TLS handshake.

Generally, the following procedure is performed:

1. Client requests secure connection to a server and sends all required information (supported SSL/TLS version, ciphers, session data, etc.);
2. Server responds with its server certificate. Along this, the server provides a proof that he possesses an associated (to a public in the certificate) private key by signing some data.
3. Client validates server certificate and all received signed data to identify that server owns associated private key.
4. Thus far, everything was transferred over unsecured channel. At this point, client and server select random symmetric session key that will be used to encrypt all traffic between client and server.
5. Client and server start application protocol that is transferred over secure tunnel.

The most interesting point here is random symmetric session key generation and transfer to peer.

Key encryption

Obvious question: who is responsible to generate the key? The answer may not be that obvious. It is impossible for server to be responsible for session key generation. Why? Because there is no secure way to tell that key to client.

Instead, the key is generated by client. Once generated, the client encrypts the key with server’s public key and sends the key to server. Server uses its own private key to decrypt the key and he is ready to start higher-level application protocol. This technique is called: key exchange with key encryption. There is no place for MITM (Man-In-The-Middle) attack, because an attacker cannot decrypt encrypted key as he do not have access to private key (which is held by server only).

This key exchange mechanism may have security issues. Only one peer has control over session key generation. No [perfect] forward secrecy: if secured traffic was recorded by an attacker and later he gets an access to a server’s private key, the hacker then will be able to decrypt session key and decrypt recorded traffic and data.

Another issue (not that important, but anyway): only two peers can communicate via single SSL tunnel. For example, if you need a shared SSL tunnel for more peers then you will have to establish as much as  tunnels with unique session key in each tunnel. Key encryption generally is used in SSL protocol.

Key agreement

However, there is another way to securely exchange session key that supports:

• key exchange over unsecured network;
• Key exchange between multiple peers.

This technique is called key agreement. The most popular key agreement protocols is Diffie-Hellman protocol which can be simplified to the following image (stolen from wikipedia):

1. Alice and Bob create individual secret color and select common (public) color. Common color can be transferred over public network. Secret colors are not transferred in pure way.
2. Alice and Bob mix their secret and common colors. Two new colors are produced.
3. Alice and Bob exchange mixed colors to each other over public and unsecured network.
4. Alice and Bob apply their original colors to a mixture as the result they both get the same common secret.

Even if attacker records entire traffic, he will be unable to extract secret color by having mixture and common (public) color.

As you can see, natively Diffie-Hellman key exchange even do not require digital certificates to secure key exchange (however, they are required to authenticate peers). By using this technique, you can easily connect as much parties as you wish. Actual DH protocol implementation is more complex and can provide additional security features (like perfect forward secrecy), main principle is the same. Key agreement protocols are used in TLS protocol.

Conclusion

Today we discovered the difference between two common session key exchange techniques with and without key encryption, their advantages and disadvantages (where possible). Now we can conclude that key agreement key exchange protocol looks more interesting and preferred for secure connections.