Analysis of key establishment protocols
The main objective of this section is to highlight the delicate nature of authenticated key establishment protocols, and the subtlety of design flaws. Examples of flawed protocols are included to illustrate typical attack strategies, and to discourage protocol design by the novice.
Attack strategies and classic protocol flaws
The study of successful attacks which have uncovered flaws in protocols allows one to leant from previous design errors, understand general attack methods and strategies, and formulate design principles. This both motivates and allows an understanding of various design features of protocols. General attack strategies are discussed in §12.2.3. In the specific examples below, A and В are the legitimate parties, and E is an adversary (enemy). Two of the protocols discussed are, in fact, authentication-only protocols (i.e., do not involve key establishment), but are included in this discussion because common principles apply.
Attack 1: Intruder-in-the-middle
The classic “intruder-in-the-middle” attack on unauthenticated Diffie-Heilman key agreement is as follows.
A and В have private keys x and y, respectively. E creates keys x' and у . E intercepts /Ts exponential and replaces it by аж ; and intercepts B’s exponential, replacing it with ay'. A forms session key К a = axy', while В forms session key А'в = ax’y. E is able to compute both these keys. When A subsequently sends a message to В encrypted under К a, E deciphers it, re-enciphers under Kb, and forwards it to B. Similarly E deciphers messages encrypted by В (for A) under Kb, and re-enciphers them under К a- A and В believe they communicate securely, while E reads all traffic.
Attack 2: Reflection attack
Suppose A and В share a symmetric key K, and authenticate one another on the basis of demonstrating knowledge of this key by encrypting or decrypting a challenge as follows.
An adversary E can impersonate В as follows. Upon A sending (1), E intercepts it, and initiates a new protocol, sending the identical message гд back to A as message (1) purportedly from B. In this second protocol, A responds with message (2'): Ек(га, м'), which E again intercepts and simply replays back on A as the answer (2) in response to the challenge га in the original protocol. A then completes the first protocol, and believes it has successfully authenticated B, while in fact В has not been involved in any communications.
The attack can be prevented by using distinct keys К and K' for encryptions from A to В and В to A, respectively. An alternate solution is to avoid message symmetry, e.g., by including the identifier of the originating party within the encrypted portion of (2).
Attack 3: Interleaving attack
Consider the following (flawed) authentication protocol, where sa denotes the signature operation of party A, and it is assumed that all parties have authentic copies of all others’ public keys.
The intention is that the random numbers chosen by A and B, respectively, together with the signatures, provide a guarantee of freshness and entity authentication. However, an enemy E can initiate one protocol with В (pretending to be Л), and another with A (pretending to be B), as shown below, and use a message from the latter protocol to successfully complete the former, thereby deceiving В into believing E is A (and that A initiated the protocol).
This attack is possible due to the message symmetry of (2) and (3), and may be prevented by making their structures differ, securely binding an identifier to each message indicating a message number, or simply requiring the original rA take the place of rA in (3).
The implications of this attack depend on the specific objectives the protocol was assumed to provide. Such specific objectives are, however, (unfortunately) often not explicitly stated.
Attack 4: Misplaced trust in server
The Otway-Rees protocol (Protocol 12.29) has messages as follows:
Upon receiving message (2), the server must verify that the encrypted fields (M, A, В) in both pails of (2) match, and in addition that these fields match the cleartext (M, A,B). If the latter check is not carried out, the protocol is open to attack by an enemy E (who is another authorized system user) impersonating В as follows. E modifies (2), replacing cleartext В
by E (but leaving both enciphered versions of both identifiers A and В intact), replacing nonce N[j by its own nonce Ne, and using key Ket (which E shares a priori with T) in place of Kbt- Based on the cleartext identifier E, T then encrypts part of message (3) under Ket allowing E to recover k but A believes, as in the original protocol, that к is shared with B. The attack is summarized as follows.
The attack is possible due to the subtle manner by which A infers the identity of the other party to which к is made available: in (4), A has no direct indication of the other party to which T has made к available, but relies on the nonce Na in (4) and its association with the pair (Na- B) within the protected part of (1). Thus, A relies on (or delegates trust to) the server to make к available only to the party requested by /1, and this can be assured only by T making use of the protected fields (M, A, B).