On Robust Key Agreement Based on Public Key Authentication (Short Paper) Feng Hao Thales E-Security, Cambridge, UK [email protected] Abstract. We describe two new attacks on the HMQV protocol. The rst attack raises a serious question on the basic denition of authentica- tion in HMQV, while the second attack is generally applicable to many other protocols. In addition, we present a new authenticated key agree- ment protocol called YAK. Our approach is to depend on well-established techniques such as Schnorr's signature. Among all the related protocols, YAK appears to be the simplest so far. We believe simplicity is an im- portant engineering principle. 1 Introduction There are two categories of authenticated two-party key agreement protocols: Password Authenticated Key Exchange (PAKE) and Authenticated Key Ex- change (AKE) [9]. The former realizes authentication based on a shared pass- word, while the latter based on public key certicates [1,2,46]. In this paper, we focus on discussing the second category. To better dierentiate it from the rst category, we will call it Public Key Authenticated Key Exchange (PK-AKE). 2 Past work Many PK-AKE protocols claim to be provably secure in a formal model. Among them, the HMQV scheme is perhaps the most well-known example [2]. In this section, we will show two new attacks on HMQV. The HMQV protocol is modied from MQV [6] with the primary aim for provable security [2]. The most signcant change is that HMQV drops some mandated verication steps in MQV, including the Proof of Possession (PoP) check during the CA registration and the prime-order validation check of the ephemeral public key. Dropping the public key validations is highly controversial, despite that HMQV has formal security proofs. In one attack, Menezes et al. demonstrated disclosing the user's private key without violating the HMQV model deni- tion [7, 8]. This attack indicates a aw in the original design of HMQV. In acknowledgement of the missing public key validation, Krawczyk revised HMQV in the submission to IEEE P1363 Standards committee [3]. He added the following validation: Alice checks the term YBe has the correct prime order 2 and Bob does the same for XAd (see [2], p. 548, for the denition of symbols.) This change prevents the small subgroup attack in [8], but decreases the claimed eciency. However, instead of validating the static and ephemeral public keys separately as in MQV, the revision chooses to optimize eciency by mixing the two operations together. This causes the problem as below. We now report a new invalid public key attack on HMQV. For illustration, we follow the same symbols used in the original description of HMQV (see [2], p. 548). In both the original and revised versions of HMQV, the CA is only required to check the submitted public key is not 0. The attack works as follows. Assume Bob (attacker) registers a small subgroup element s 2 Gw as the public z 0 key where wjp ¡ 1. Bob chooses an arbitrary value z 2 Zq. Let Y = g ¢ s 0 where s is an element in the same small subgroup Gw. Exhaustively, Bob tries 0 e z 0 e z every element s in Gw such that YB = g ¢ s ¢ s = g . In other words, the small subgroup elements s and s0 cancel each other out. Suppose H¹ works like a random oracle as assumed in HMQV. Then, for each try of s0, the probability of nding s0 ¢ se = 1 is 1=w. It will be almost certain to nd such s0 after searching all w elements in Gw (if not then change a dierent z and repeat the procedure). Following the HMQV protocol, Bob sends Y = gz ¢ s0 to Alice. Alice checks YBe has the correct prime order and computes the session key · = H((YBe)x+da) = H(gz¢(x+da)). Because Bob knows z, he can compute the same session key · and successfully authenticate himself to Alice. The fact that an obviously invalid public key is totally undetected by all ows in HMQV is unsettling. This raises a serious question on the basic denition of authentication in HMQV Bob does not even have a private key, yet he is able to successfully pass all authentication checks. In fact, anyone can do the same pre-computation as above and authenticate to Alice as Bob. In one attacking scenario, Bob (the attacker) may at any time suddenly repudiate all previous authenticated transactions with Alice by telling the judge that his public key is invalid, so anyone can impersonate him. (Bob's certicate is publicly available.) In comparison, MQV does not have this problem. The other attack on HMQV happens when two parties use the same certi- cate during self-communication [2]. Self-communication is a useful application in practice. For example, a mobile user and the desktop computer may hold the same static private key (registering two public key certicates costs more). Krawczyk formally proved that self-communication is secure in HMQV [2]. However, the formal model in [2] only considers the user talking to one copy of self, but neglects the possibility that the user may talk to multiple copies of self at the same time. This deciency is common among other formal models too [1, 4, 11]. The attack works as follows (also see Figure 1): 1. Alice initiates the connection to a copy of herself by sending gx. The connection is intercepted by Mallory who pretends to be Alice-1. 2. Mallory starts a separate session by pretending to be Alice-2. He initiates the connection by sending to Alice gx (this is possible because HMQV does not require the sender to know the exponent). 3. Alice responds to Alice-2 by sending gy. 3 Fig. 1. Wormhole attack on HMQV 4. Mallory replays gy to Alice as Alice-1. 5. Alice derives a session key and sends an encrypted message to Alice-1, say: Transfer to me $1m. 6. Mallory replays the encrypted message to Alice. (After receiving money from Alice, Mallory disconnects both connections.) In the above attack, we only demonstrated the attack against the two-pass HMQV (implicit authentication). For the three-pass HMQV (explicit authenti- cation), the attack works exactly the same. Also, we have omitted the identities in the message ows, because they are all identical according to the HMQV specication [2]. This attack is essentially an unknown key sharing attack. Alice thinks she is communicating to a mobile user with the same certicate, but she is actu- ally communicating to herself. The attacker does not hold the private key, but he manages to establish two fully authenticated channels with Alice (server). The same attack also applies to other PK-AKE schemes, including NAXOS [4], KEA+ [5], CMQV [11], MQV [6], and SIG-DH [1] etc, despite that many of them have formal security proofs. 3 The YAK protocol In this section, we propose a new PK-AKE protocol called YAK1. Let G denote a subgroup of ¤ with prime order in which the Computational Die-Hellman Zp q problem (CDH) is intractable. Let g be a generator in G. The two communicating parties, Alice and Bob, both agree on (G, g). 3.1 stage 1: public key registration In stage 1, Alice and Bob register static public keys from a Certicate Authority (CA). Alice selects a random secret a 2R Zq as her private key. Similarly, Bob selects b 2R Zq as his private key. 1 The yak lives in the Tibetan Plateau where environmental conditions are extremely adverse. 4 CA-Registration Alice sends to the CA ga with a knowledge proof for a. Similarly, Bob sends to the CA gb with a knowledge proof for b. The sender needs to produce a valid knowledge proof to demonstrate the Proof of Possession (PoP) of the private key. As an example, we can use Schnorr's signature, which is provably secure in the random oracle model [9]. Let H be a secure hash function. To prove the knowledge of the exponent for X = gx, one sends {SignerID, OtherInfo, V = gv, r = v ¡ x ¢ h} where SignerID is the unique user identier (also called Distinguished Name [10]), OtherInfo includes auxiliary information to indicate this is a request for certifying a static public key and may include other practical information such as the name of the algorithm etc, v 2R Zq and h = H(g; V; X; SignerID; OtherInfo). The CA checks that X has prime order q and veries that V = grXh (computing grXh requires roughly one exponentiation using the simultaneous computation technique [9]). 3.2 stage 2: key agreement Alice and Bob execute the following protocol to establish a session key. For simplicity of discussion, we explain the case that Alice and Bob have dierent certicates (a 6= b) and will cover self-communication later. x YAK-protocol Alice selects x 2R Zq and sends out g with a knowledge proof y for x. Similarly, Bob selects y 2 Zq and sends out g with a knowledge proof for y. When this round of communication nishes, Alice and Bob verify the received knowledge proof to ensure the other party possesses the ephemeral private key. They also need to ensure the identity (i.e., SignerID) in the knowledge proof must match the one in the public key certicate. Upon successful verication, Alice computes a session key · = H((gy ¢ gb)x+a) = H(g(x+a)(y+b)). And Bob computes the same session key: · = H((gx ¢ ga)y+b) = H(g(x+a)(y+b)). In YAK, Alice needs to perform the following exponentiations: one to com- pute an ephemeral public key (i.e., gx), one to compute the knowledge proof for x (i.e., gvx ), two to verify the knowledge proof for the exponent of Y = gy (i.e., Y q and gry Y hy ) and nally one to compute the session key (Y ¢ B)x+a.