## 1 Introduction
However, the use of traditional certificates in the situations described above is usually difficult to implement due to the use of very light devices with limited capacities and/or the absence of a central trust entity that builds such certificates, and security has predominantly been based on pre-shared keys, which cannot be revoked and do not provide strong authentication. The prevalence of pre-shared keys in the IoT is due primarily to a lack of lightweight protocols for accessing PKI services. Principal among these services are digital certificate enrollment and revocation, the former of which is addressed in recent research and is being pushed for standardization in IETF. However, no protocol yet exists for retrieving certificate status information on constrained devices, and revocation is not possible unless such a service is available [11]. An example of a protocol for distributed Group Key Management making use of pre-shared keys is introduced in [12]. Here, the authors propose an alternative extension of CLIQUES providing an implicit key authentication, that is, each member \(\mathcal{U}_{i}\in\mathcal{U}\) is assured that no party \(\mathcal{U}_{i}\
otin\mathcal{U}\) can learn the key \(K_{n}\) (unless he is aided by a dishonest \(\mathcal{U}_{j}\in\mathcal{U}\)). In this protocol, named A-GDH, the last user, \(\mathcal{U}_{n}\), shares a distinct secret \(K_{i,n}\) with every user \(\mathcal{U}_{i}\), for \(i=1,\ldots,n-1\). They assert that this protocol provides authentication and shows its fortress in the DDH problem, as the original CLIQUES proposal. It can be observed that CLIQUES is a particular case of this protocol, where \(K_{i,n}=1\) for every \(i=1,\ldots,n-1\). The starting point is an authenticated version of the Diffie-Hellman key exchange protocol [13], which the reader can find in [12] [Protocol A-DH]:  
Let \(q\) and \(p=2q+1\) be prime integers and \(G\) the unique subgroup of order \(q\) of the multiplicative group \(\mathbb{Z}_{p}^{*}\), and let \(\alpha\) be a generator of \(G\). In the first stage, let \(x_{1}\) and \(x_{2}\) be two integers such that \(1\leq x_{1},x_{2}\leq q-1\), let \(\mathcal{U}_{1}\) and \(\mathcal{U}_{2}\) be two parties wishing to share a key, and let \((x_{1},\alpha^{x_{1}}\pmod{p})\) and \((x_{2},\alpha^{x_{2}}\pmod{p})\) be the secret and public keys of \(\mathcal{U}_{1}\) and \(\mathcal{U}_{2}\), respectively. Thus, the public values of the system are \((p,q,\alpha,\alpha^{x_{1}},\alpha^{x_{2}})\). The A-DH protocol is as follows:  
1. \(\mathcal{U}_{1}\) sends \(\alpha^{x_{1}}\pmod{p}\) to \(\mathcal{U}_{2}\), for \(r_{1}\in\mathbb{Z}_{q}^{*}\). 2. \(\mathcal{U}_{2}\) selects \(r_{2}\in\mathbb{Z}_{q}^{*}\) and computes \(K=F(\alpha^{x_{1}x_{2}}\pmod{p})\), where \(F(x)\) is given by \(x\pmod{p}\) in case \(x\leq q\) and \(p-x\pmod{p}\) if \(x>q\). 3. \(\mathcal{U}_{2}\) sends \(\alpha^{x_{2}K}\pmod{p}\) to \(\mathcal{U}_{1}\). \(\mathcal{U}_{1}\) computes \(K^{-1}\ (\text{mod q})\) and computes  
\[(\alpha^{r_{2}K})^{r_{1}K^{-1}}\ (\text{mod p})=\alpha^{r_{1}r_{2}}\ (\text{mod p})\]  
which is the shared key. However, it is easily observable that this protocol does not avoid a classical man-in-the-middle attack that allows an attacker to share two keys with \(\mathcal{U}_{1}\) and \(\mathcal{U}_{2}\). Our aim in this work is to show that the authenticated Group Key Management protocol that extends the preceding A-DH protocol fails against an active attack and allows an adversary to share a common key with all the group members, without letting them know about the attack. In [10], the attack is developed under the assumption that the attacker controls the communications of the users \(\mathcal{U}_{n-1}\) and \(\mathcal{U}_{n}\). Now, we introduce a general attack where the attacker requires communications control of a single member of the group, which extends the attack introduced in [10] on CLIQUES. Moreover, the attack given in that paper is only described from an algebraic point of view by giving the operations and actions that the attacker should follow.