A cross-protocol attack on the TLS protocol

Abstract

This paper describes a cross-protocol attack on all versions of TLS; it can be seen as an extension of the Wagner and Schneier attack on SSL 3.0. The attack presents valid explicit elliptic curve Diffie-Hellman parameters signed by a server to a client that incorrectly interprets these parameters as valid plain Diffie-Hellman parameters. Our attack enables an adversary to successfully impersonate a server to a random client after obtaining 2 40 signed elliptic curve keys from the original server. While attacking a specific client is improbable due to the high number of signed keys required during the lifetime of one TLS handshake, it is not completely unrealistic for a setting where the server has high computational power and the attacker contents itself with recovering one out of many session keys. We remark that popular open-source server implementations are not susceptible to this attack, since they typically do not support the explicit curve option. Finally we propose a fix that renders the protocol immune to this family of cross-protocol attacks.

Proving the TLS Handshake Secure (As It Is)

“…As a second example, Mavrogiannopoulos et al [49] report an interesting cross-protocol attack between plain Diffie-Hellman (DH) and Elliptic-Curve Diffie-Hellman (ECDH) ciphersuites, due to a misinterpretation of the signed group description sent by the server. Each family of ciphersuites is (a priori) secure in isolation, but configurations enabling a DH client and an ECDH server are subject to their attack.…”

“…if the public keys of different KEM schemes can be confused, then an adversary can potentially impersonate the server without needing to know its private key. Wagner and Schneier [62] show how DHE public keys can be confused with ephemeral RSA, and Mavrogiannopoulos et al [49] show how ECDHE public keys can be confused with DHE. The success probability of these attacks depends on implementation details; in practice, this is small but not negligible.…”

“…In this presentation, we do not support both DHE and ECDHE simultaneously, so formally there is no risk of confusing their signed exponentials [48]; otherwise we would require that the honestly-signed payloads for DHE and ECDHE have disjoint formats and that clients in addition to verifying signatures check for these format differences.…”

Generic Forward-Secure Key Agreement Without Signatures

“…We note that this is not just a theoretical concern. Attacks against deployed cryptography that reuse keys in unintended ways have been previously reported [27,19,20].…”

Authenticated Key Exchange from Ideal Lattices

“…This includes several well-known protocols such as IKE [39,44], SIGMA [45], SSL [31], TLS [25,47,56,36,12], as well as the standard in German electronic identity cards, namely EAC [14,22], and the standardized protocols OPACITY [23] and PLAID [24]. Another line of designing AKEs follows the idea of MQV [57,41,46,68] (which has been standardized by ISO/IEC and IEEE, and recommended by NIST and NSA Suite B) by making good use of the algebraic structure of DH problems to achieve implicit authentication.…”