Category Archives: Cryptography

Why does SSL / TLS not use Diffie-Helman Key Exchange by default?

As it is already known SSL has to deal with a lot of severe security problems and exploits. 1 2 3 4 5

This is how an SSL connection is established:
SSL Connection Establishment

  1. client_hello:
    This is the first packet which is sent from the client to the server. The client tells the server that he wants to establish a secure connection and informs the server about all cipher suites which are supported by the client. Following picture shows the client hello more in detail:
    suites One Cipher Suite could be:
    TLS_RSA_WITH_AES_256_CBC_SHA256
    That means that this suite uses RSA for Key Exchange. As symmetric cipher this suite uses AES with a keysize of 256 Bit. As mode of operation CBC is used, and SHA256 as hash algorithm.At the beginning of the connection, the server does not know which suites are supported by the client and vice versa. As the client wants to establish the connection, it is his task to tell the server about all supported cipher suites.
  2. server_hello: After the client_hello, the server answers with server_hello. Following picture shows it in detail:
    server_suite_decisionThe server decides which suite he would like to use. In the given example he decides to use TLS_RSA_WITH_AES_256_CBC_SHA256.
  3. Server Authentication: The server sends its certificate to the client which then can test wether the certificate is valid or not.
  4. Key Exchange: When TLS_RSA is used, the client generates a random Pre Master Secret (PMS) which is sent to the server encrypted with the public key of the server. The server is able to decrypt the encrypted PMS with its private Key. Both, server and client then derive a common secret from the PMS.
  5. The rest of the communication gets encrypted symmetrically with AES_256_CBC.

All in all, this mechanism seems to be quite secure. Authenticity is provided through the certificate and confidentiality is provided through the symmetric encryption. However, a closer look reveals that it’s not that secure after all:

In my opinion, one of the current major risks of SSL is making use of RSA for the encryption of the symmetric key. If a weak RSA key has been used, or some third know about the private key, all the traffic can be decrypted:

Decrypted

As mentioned above at the beginning of a TLS communication, SSL uses RSA for authentication. But unfortunately, RSA is also used for Key Exchange. Actually RSA is only intended to be used for authentication and not for Key Exchange. There are much better protocols for that problem. Diffie-Hellman is a very common key exchange protocol. But Diffie-Hellman is not used by SSL by default. So the symmetric connection depends exclusivley on the secrecy of the private key.

If Diffie Hellman would be used, a third party is not able to decrypt the connection, even if he knows about the private key. The following picture shows a simple SSL connection – remember: Wireshark still knows my private key!
SSL_with_DH

Unfortunately Diffie-Hellman Key Exchange doesn’t get used very often, though all modern browser do support it.

Dear SSL developers… In future versions of SSL, please disallow Key Exchange without Diffie-Hellman or any other kind of perfect forward secrecy by default. Do not argue by backward compatibility. Argument with security. Disallow medium and weak ciphers.

Check your configuration using nice tools like SSL Test.

Maybe it’s generally time for a new secure protocol like SSL. Without all that inherited waste.

UPDATE 2012-07-02:
Nice article on this topic: SSL: Intercepted today, decrypted tomorrow

Authenticated block cipher mode of operation

Common symmetric block cipher mode of operation (such as CBC, OFB, CTR) only provide confidentiality. That means that your plaintext is not readable without the knowledge of a secret key. When ciphertext gets changed by unauthorized third parties, it is not replicable if that change happened intentionally by an authorized party or by an unauthorized one.

But there are several ways to provide confidentiality as well as authenticity. One possibility to guarantee confidentiallity and authenticity  is to use message authentication codes. MACs tag messages with additional data. Only authorized parties having information about the key which was used for the generation of the the MAC are able to generate and check the tag. If the tag or the message gets changed by an unauthorized party, one is able to recognize it.

Opinions are divided wether to tag plaintext or ciphertext data. Both opportunities have advantages and disadvantages: Another reason to MAC ciphertext, not plaintext , When authenticating ciphertexts, what should be HMACed?

As it is explained here, the correct usage of CBC-MAC is also a well-known issue 🙂 I personally prefer using HMAC for authenticating messages. It is quite easy to use and fool proofed. But all MAC’s have one big disadvantage: When decrypting or encrypting data, one has to iterate two times over the data, no matter if plaintext or ciphertext got tagged. One iteration is for de/encryption and one is for the generation of the MAC. This is convenient for small amounts of data but it leads to high loads when working with bulk data. So this method is inappropriate for hard disk encryption.

Therefor “authenticated encryption with associated data (AEAD)” or simpy “authenticated encryption (AE)” could be used. Data gets de/encrypted AND tagged simultaneously. Here are some examples for authenticated encryption modes. Those methods encrypt and authenticate a secret message m and also authenticates “additional authenticated data” a, which gets not encrypted (a can also stay empty). Unfortunatelly, those modes of operation are not very popular up to now. Some authenticated mode of operation are not able to finish decryption if some (authentication) error occurs during decryption. This could lead to problems in some cases, especially when it is necessary to recover faulty data.

Authenticated block cipher mode of operation could actually be used much more frequently instead of HMAC or other ways to provide authenticity. They are much more performant, elegant and straightforward. But even modern disk encryption software like TrueCrypt or Linux’s cryptsetup (LUKS) do not support authenticated encryption. I had a nice discussion on that topic on the
dm-crypt mailing list: [dm-crypt] Authenticated Encryption for dm-crypt