KCI attacks against TLS

In past 2 years or so, SSL/TLS protocol is under severe scrutiny and rightly so, as it is one of the most widely used cryptographic protocol on the Internet. How secure place Internet is directly or indirectly do depend on SSL/TLS protocl. In the past there have been many vulnerabilities discovered, ranging from design issues like POODLE, FREAK or LOGJAM to implementation bugs like HEARTBLEED and OpenSSL CCS. Recently in Usenix’15 conference, another attack on TLS was presented – Prying open Pandora’s box: KCI attacks against TLS. Where, KCI stands for Key Compromise Impersonation. Although, this attack is not as severe as other existing attacks, but still as per author’s claim, might affect a tiny part of the Internet. In this post, lets try to understand the how the attack works and what are the ways to protect against this attack.

TL;DR this attack is only possible when the communication is happening using non-ephemeral (EC)DH and client certificates are used for authenticating the clients, and some more conditions thrown in the mix. Use of non-ephemeral (EC)DH is very limited on the Internet and further use of client certificates is also rare, thus making this vulnerability less likely to occur.

Before getting into the details of this attack, it is presumed that readers know about the working of SSL/TLS protocol in general and how SSL/TLS work when non-ephemeral (EC)DH supporting cipher suits are used. Also, understanding how a typical MITM attack against a TLS session works will be helpful.

Before getting into the actual attack phase, there is pre-attack phase in which attacker needs to collect information to carry on the attack.

Pre-Attack Phase: The attacker should be able to get the possession of a client certificate and its corresponding private key that is or will be installed at the client. This might seem to be little unlikely to perform, but authors say it is possible in cases like a  software vendor shipping product with pre-installed client certificates or a malicious Android App installs one on the system etc.

Attack Phase: A client C  (e.g. a browser) initiates a TLS connection to a server S. The attacker M, attacking as Man-in-the-Middle, will block the traffic from C to S. For the ClientHello message sent by the client, M responds with a ServerHello message, choosing a non-ephemeral  cipher suit for communication.

In Certificate message, attacker M sends the original server’s certificate, unlike in a typical MITM attack, a new certificate (not of original servers) is sent. We will see shortly, how attacker derives the master secret, as he does not have the private key of the certificate sent.

The attacker asks for the client certificate by sending CertficateRequest message and requests for non-ephemeral (EC)DH client authentication. In the message, the attacker also asks for the client certificate to be of same type that of the server certificate it sent. In the CertificateRequest message by specifying the CA name, the attacker can ascertain that client uses the compromised pair of certificate and secret key to authenticate itself.

The client proceed to finish the handshake, oblivious of the attack being performed, as it would normally do. While the attacker does not know have the private key of the server’s certificate and hence cannot derive the master secret. But the he knows the secret key, and uses that to calculate the master secret and complete the handshake.

Lets summarize the pre-conditions to pull off this attack and then see how to prevent such attack:

  1. Client Support: The client must support a non-ephemeral (EC)DH cipher suites, i.e, by sending the (EC)DH protocols in the ClientHello message. Additionally, the client implementation must support any of the fixed (EC)DH client authentication options implied by the client certificate types: rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh.
  2. Server Support: The adversary attacking a server must get possession of certificate of the server that contains static (EC)DH values. There are further subtle details discussed in the paper, like why such attack is possible in case of DSS or ECDSA certificate.
  3. Compromised Client Cert: The adversary must have possession of a client certificate and the corresponding secret key that must both be installed at the client.

On server side:

  1. Disable non-ephemeral (EC)DH handshakes
  2. “Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and disable specifically the KeyAgreement flag.”

In the paper authors have went on to motivate why this attack at present might be unlikely but still possible in future scenarios. IMHO, this might not be the most sorted after attack vector, but surely such research ensure that TLS protocol will become more secure in the future.

Keep Hacking 😀