1. Introduction
Internet of Things is becoming more and more widespread with the use of sensor networks and the so-called wearables that allow for the exchange of information in real-time—information that is used on many occasions in order to make decisions or control any system in a remote way. Thus, the prevalence of traditional human-to-human or human-to-machine communications is being progressively substituted by the exponential increase in machine-to-machine communications [
1]. Therefore, a conventional security architecture, where there exists an authority in charge of safeguarding and/or generating session keys, does not address all security issues appearing in this paradigm given that it does not take into account patterns where machines communicate directly to machines and distributed computing forms are gaining importance in the communication processes [
2]. Due to the open characteristics of these systems, the privacy of the transmitted data is becoming a major concern [
3,
4]. Therefore, a key to solving this issue is Group Key Management using a distributed solution, i.e., users (that could be machines) collaborate to build a common session key that is used to encrypt communications among members of the group. Examples of this type of protocol can be found in [
5,
6,
7,
8] [Chapter 9] and references therein.
Probably one of the best-known protocols for distributed Group Key Management is CLIQUES. This protocol, proposed by Steiner et al. in [
9], belongs to the so-called generic Group Diffie–Hellman (GDH) key agreements. In this paper, the authors introduce a series of protocols on an algebraic cyclic group
G of order
q that the communicating parties
agree on, as well as a generator of the group
. Each party holds a private element
,
. All these protocols are based on distributively computing a subset of
and each party
,
, from
can easily obtain
. In these protocols, one of the members, namely,
has a greater computing load and, in order to equalize it for every party, the authors consider a detached protocol where every party has almost the same workload. However, it is precisely the nature of this protocol that allowed Schnyder et al. in [
10] to provide an active attack on it based on the well-known man-in-the-middle attack for the case of an attacker that is able to control communications of the users with a special role in the group, namely
and
during the set-up phase. The authors show that an attacker can forge
and
activity in order to make every party think that they are exchanging the necessary information to build a common key only known by themselves, but that, in fact, it is also known and constructed with the collaboration of their own attacker without knowing the existence of this malicious activity. Thus, the attacker becomes a legal member that is unknown by the other parties of the communication group, and it can obtain all the data transmitted using the common secret they have collaboratively built. They also show that it is possible to use a strategy so that the attacker can leave the group without letting the group members know about the attack.
The traditional method of avoiding an impersonation attack is to use some additional information that provides authentication. Public key infrastructure (PKI) provides the basis of authentication and access control in most networked systems. 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
is assured that no party
can learn the key
(unless he is aided by a dishonest
). In this protocol, named A-GDH, the last user,
, shares a distinct secret
with every user
, for
. 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
for every
. 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 be prime integers and G the unique subgroup of order q of the multiplicative group , and let be a generator of G.
In the first stage, let and be two integers such that , let and be two parties wishing to share a key, and let and be the secret and public keys of and , respectively. Thus, the public values of the system are . The A-DH protocol is as follows:
sends to , for .
selects and computes , where is given by in case and if .
sends to .
computes
and computes
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 and .
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
and
. 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. Now, in this paper, we are providing a proof using a widely-known cryptographic model that better describes the algebraic computations and the algorithms or oracles that the attacker has to access.
Moreover, very recently, in [
14] [Section 1.1], NIST warns of the vulnerability of cryptographic protocols whose security lies on algebraic problems based on integer factorization or the discrete logarithm problem against an adversary in possession of a large-scale fault-tolerant quantum computer. The protocol introduced in [
12] bases its security precisely on the difficulty of the discrete logarithm problem in the chosen group. However, in [
15], the authors introduce a new algebraic setting to extend all these key management protocols, as is later shown in [
16] for the case of the protocols introduced in [
9], and there is no known algorithm that solves the underlying algebraic problem even with the use of a quantum computer. Using similar developments to those in [
16], we could also use the protocols introduced in [
12] for the new algebraic setting, but, as we will show, our attack proves the vulnerability of the authenticated Group Key Management given that it uses the nature of its own protocol and not the algebraic setting.
The structure of the paper is as follows. In
Section 2 , we provide all the methods and terminology that are used throughout the paper. We start by recalling the authenticated initial group key agreement, as it is introduced in [
12], where the underlying security is based on the so-called decisional DDH. Then, we establish the security model that will be followed to cryptanalyze the protocol and recall a well-known and widespread setting to use this protocol, i.e., the case of elliptic curves, which allows us to analyze a case study. In
Section 3, the reader can find a detailed explanation of the active attack, which shows that Ateniese et al.’s proposal for GDH2 [
12] (denoted by A-GDH2) fails against it, and, as a particular case, Steiner et al.’s original CLIQUES IKA.2 implementation introduced in [
9]. In
Section 4, we provide a case study using elliptic curves and propose strategies in the auxiliary key agreement, i.e., in the rekeying protocol, in order to take total control of the group or the possibility for the attacker to leave the group without letting the users know that the attacker was listening to all communications for a period of time. We conclude the paper with some final considerations.
2. Material and Methods
Throughout this section, we will review all the cryptographic notions and methods that we have used in our research. Firstly, we will recall the general group key agreement that was introduced in [
12]. This protocol describes a way for a group of users to agree on a common secret that allows the building of a common session key in a distributed way, i.e., all users contribute to obtaining such a secret by means of some private personal information that everyone holds and that allow the recovery of such a secret from a broadcast message. This particular method is a natural extension of the foundational work by Diffie and Hellman [
13], and it is a generalization of the proposal [
9] that uses a pre-distributed set of secrets that allow the participants to authenticate the key that is recovered after the protocol.
The second part of this section describes the security model that is used in order to analyze the security of the protocol. We introduce the notation and the oracles used by an adversary that successfully attacks the protocol and can join the group, without letting the participants know it, as another illegal member of the communication group that also contributes to building the common key.
Finally, in the last subsection, we will recall the mathematical concepts related to elliptic curves that allow for applying these structures to cryptography and, in particular, to the cryptanalyzed protocol. The use of elliptic curves is nowadays very extended given the light storage and computing requirements, which make them very appropriate for physically limited devices as is the case of those used in the Internet of Things and the high level of security offered. In the discussion section, we will give an example of how an adversary can access the system that uses the cryptanalyzed protocol in the case of elliptic curves.
2.1. The Group Key Agreement
The following protocol describes the A-GDH2 Key Agreement protocol introduced in [
12]. When the keys
shared by
and
equal 1, then we obtain the Initial Key Agreement of CLIQUES, named IKA.2 in [
9].
Suppose we have n users who wish to agree upon a common key. Let p be a prime and q a prime divisor of . Let G be the unique cyclic subgroup of of order q and let be a generator of G. Then, for each , the user selects a secret element . Let be a common key shared in advanced by and for every .
The protocol proceeds as follows:
For sends to the message , where .
broadcasts to the other users .
computes the shared key .
For , sends to .
broadcasts to , .
For , computes the shared key .
2.2. The Security Model
We will use the security model of [
17], developed from [
18] in order to formalize the cryptanalysis that we are introducing in the next section. These models are widely known and used to show the security of a group key exchange. To this end, we fix the notation and definitions necessary to such a formalization.
The (potential) participants in the protocol are modeled as probabilistic polynomial time (ppt) Turing machines (basically, a model of computation consisting of a finite state machine controller, a read-write head, and an unbounded sequential tape. Depending on the current state and symbol read on the tape, the machine can change its state and move the head to the left or right. This is said to be probabilistic when transitions are random choices among a finite number of alternatives. cf. [
19]) in the finite set
and every participant
,
in the set
can run a polynomial amount of protocol instances in parallel.
The instance of participant will be denoted as , and we assign it the following variables:
: stores the identities of the party users (including ) and aims at establishing a session key with variables assigned.
: is a variable that is initialized with a distinguished NULL value and will store the session key.
: is a variable that stores a non-secret session identifier to the session key stored in .
: is a variable that indicates whether the session key in was accepted or not.
: is a variable that indicates whether the protocol execution has finished.
: is a variable that indicates whether this instance is taking part in a protocol run.
Concerning the communication network and the adversarial capabilities, we fix the following conditions. We will assume that there exist arbitrary point-to-point connections among users and that the network is non-private, fully asynchronous and that the adversary
has absolute control. This can eavesdrop, delay, delete, modify or insert messages. Thus the adversary’s capabilities are given by the following oracles (basically, a system that can be viewed in terms of its inputs and outputs, without any knowledge of its internal functioning and that produces a solution for any instance of a given computational problem. cf [
19]).
Send(): by querying this oracle, the message M is sent to instance of user of . The output will be the protocol message that the instance outputs after receiving message M. The adversary can use this protocol to initialize a protocol execution by using the special message to an unused instance . This oracle initializes a protocol run among users . After such a query, sets , :=TRUE, and processes the first step of the protocol.
Execute(): in case the instances have not yet been used, this oracle will return a transcript of complete execution of the protocol among the specified instances.
Reveal(): this oracle returns the session key stored in if =TRUE and, otherwise, a NULL value.
Corrupt(): this query returns ’s long-term secret key.
If the adversary can access all of the preceding oracles, then it is called an active adversary and, in the case that is not granted access to any of the Send oracles, it is referred to as a passive adversary. Thus, the attack we are introducing through this work is developed by an active adversary.
2.3. Elliptic Curves
As previously noted, we are going to show an example of how the attack is developed in a specific and very extended case through cryptography on elliptic curves. Thus, let us briefly reiterate some mathematical and cryptographic topics regarding elliptic curves. The reader is referred to [
20] for an extended study on the structure and cryptographic applications of this important mathematical concept.
Let
be a field. Let us consider the set of points
, verifying the equation with coefficients in
that when the characteristic of the field, Char(
)
, then it can be simplified to
which is the classical formula widely extended. In this case, we say that
defines an elliptic curve if and only if
.
The set of points of an elliptic curve over , can be endowed with an internal operation, usually known as point addition and, given a point of an elliptic curve, we denote the multiple as the point that is the result of adding P with itself k times.
In [
21,
22], the authors suggested that the group of points of an elliptic curve is suitable for developing secure cryptographic methods. The so-called Elliptic Logarithm Problem or Elliptic Curve Discrete Logarithm Problem is of such complexity that we could reduce the requirements on the key length significantly, offering high levels of security. This problem is defined in the following way. Given two points
P and
Q of an elliptic curve and such that
, the problem is finding the integer
x. Therefore, it is necessary to immediately define a Diffie–Hellman key exchange using this problem as support:
Two users and agree on a point of an elliptic curve with n points, say G.
Both users choose, respectively, and as private integer values in the rank .
They both exchange the values and .
recovers while computes , and both values result in the same point .
This is exactly a special case of the protocol introduced in [
12] and described in
Section 2.1 for the case of the group of points of an elliptic curve, with only two users,
and
and where
.
3. Results
The aim of the attack that we are introducing in this section is that the adversary, , and the users agree on a shared key, as it is obtained after running the protocol, but will know the key as well and can listen and send messages using that common key, exactly the same as another group member. However, , will not know anything about the existence of . Contrary to other attacks of this type, the adversary does not share a specific key with the attacked group member in order to decrypt the information sent among the other group members and then, using this second special key, encrypt the information for the hacked group member and vice versa when it wants to send a message to the rest of the group members.
As assumed in the security model [
17],
has absolute control of the whole group’s communications. However, in practice,
needs to have full control over the communication of a single user
,
only during the pre-setup stage, when this user exchanges a key with
,
, and during the key exchange protocol, i.e., the cryptographic model is more restrictive than is actually necessary to develop the attack in a real situation. Moreover, unlike in a regular man-in-the-middle attack,
does not need to maintain this control after the key exchange is completed. We are assuming that
. The case where
controls the communications of
or
will be followed in an analogous way as is given in [
10], as we will explain later. As we can observe below, unlike what it is assumed in that case, the attacker just needs to execute control over the communications of a single user and not necessarily these two detached users simultaneously.
Given that the protocol requires that both users and to have shared a key previously, let us assume that the attack starts by executing a typical man-in-the-middle attack on the key exchange among and by means of a query Send(), which provokes the Diffie–Hellman key-exchange among these two users, and then both users’ public keys are obtained and used by to share a common key with , say and a second common key with , say . After that, the authenticated group key exchange starts. In our security model, we are assuming that the adversary has access to the oracles Reveal and Corrupt, so we can even consider the case where this previous exchange among and is made through a secure channel that avoids the man-in-the-middle attack. In those cases, an instance Reveal(), where denotes the previous session to the session where the group key is to be built by all users, outputs the session key agreed by and , and even Corrupt() would reveal the secret key used by , which simplifies clearly the attack.
Thus, let us start explaining the attack once shares two keys with both and : and .
In the beginning, chooses a secret group element . Then, proceeds as follows:
- a
The adversary queries Send() to initiate a protocol instance. After this query, the first step of the protocol is executed.
- b
Step (1) is carried out as usual until sends to . At this point, is sitting in step (1) waiting for the broadcast of .
- c
stops this message, deletes and queries Send(.
- d
broadcasts to the other users . At this point computes the key .
- e
stops this message for and queries Send().
- f
broadcasts
to
,
.
stops this message for
.
- g
computes , which is the common key computed by all the remaining users.
- h
chooses and queries Send() as if it was the message that broadcasts in (2).
- i
sends to .
- j
stops this message, deletes it and computes
using
. Then
queries
- k
recovers .
The remaining case, i.e., controls communications of and , will require that exchanges private values with each , for and values , with user .
Analogously to the previous case, in the beginning, is a secret group element, and . Then, proceeds as follows:
- a
Step (1) is carried out as usual.
- b
intercepts the broadcast of during step (2) and remembers the value . At this point, all users except for are sitting in step (2), waiting for the broadcast that was halted.
- c
proceeds to step (4), where he sends to . This is also intercepted by . is now waiting in step (5).
- d
makes believe that he received the broadcast of step (2), but actually queries Send(). At this point, computes the shared key and waits in step (4).
- e
now queries Send() for , superseding the others users in step (4). The are random elements of the subgroup generated by for , whereas and .
- f
In step (5), broadcasts, among others, the value , which intercepts. The user is now finished, and can compute the shared key .
- g
Until now, have been waiting for the broadcast in step (2), which now provides by making the queries Send(), .
- h
, , go to step (4) and sends back , which intercepts.
- i
In step (5),
queries Send(
), being
- j
queries Send(
) with
- k
The users now all compute the shared key .
We also note that the case
and
as well for every
,
is exactly the CLIQUES protocol in the case of IKA.2 introduced in [
9]. Thus, the preceding attack covers all the cases that were not considered in [
10].
4. Discussion
We now give a detailed explanation in a particular case on how the attack can be developed. As we previously pointed out, cryptography on elliptic curves is highly recommended for group key management, especially in those cases where the communication system is composed of light devices with limited computing and storage capabilities. Although actual recommendations suggest the use of elliptic curves over a field whose elements have a 256-bit length, we will use much shorter elements in order to make the explanation easy to read. At the end of this section, we will make some considerations concerning aspects that are not considered in the original work on the rekeying process.
Let us start by recreating the group key exchange without any external intervention. Therefore, let , and assume that every user has made a secure exchange with , so the shared keys used for authentication are , and , and that they agree on the curve over , which is a curve that contains exactly 103 points, and on , a point of this curve.
Now, every user chooses a private key in the rank , so let , , and . They start a protocol execution and thus:
- 1.
computes and sends it to . After receiving , computes , which is sent to . Then, computes .
- 2.
broadcasts the point .
- 3.
Now is able to compute what will be the group-shared secret and from which the group-shared key might be derived somehow, for instance, considering the result of applying some pre-agreed function to the coordinates of the shared point.
- 4.
Every user computes , , which is sent to . Thus, , and send, respectively, , and to .
- 5.
After receiving these messages,
makes use of the private information
and the corresponding shared keys with the other users
,
to broadcast the following message:
- 6.
Finally, every user recovers the shared secret by computing . Thus, computes . Analogously, computes and recovers .
Let us now observe how an adversary
with the capabilities described in
Section 2.2 affects the result of the protocol and the consequences. We are going to show an example where the attacked participant is
. Therefore, the first task that
has to carry out is to share a secret with this user as if
was
in order to properly run the attack we are introducing. Therefore, we will start by showing a classical man-in-the-middle attack during a classical Diffie–Hellman key exchange, as depicted in
Section 2.3 among users
and
through an insecure channel in order to establish a secret shared value
. At this point, we again note that even if this exchange is developed through a secure channel, we are considering that
has access to the oracle Reveal, which would provide
with this secret value, and the attack can be developed in the same way.
- 1.
Let us assume, without loss of generality, that both users and are using the same elliptic curve and the same point .
- 2.
Then and choose and as private values.
- 3.
Both users exchange and . At this point, stops these messages and accesses the exchanged values by means of the oracle and substitutes them by the message .
- 4.
Finally, recovers and computes , obtaining what they think is a point from they can derive , but they are, in fact, two points that will give them, respectively, and .
- 5.
On the other hand computes and
If we assume, for simplicity, that the function used on a point to derive a secret value is the projection on the first coordinate, we thus obtain that and .
Therefore, let us start with the attack on the group key agreement protocol. At this point, we have to recall that the secret keys of every user , i=1,2,3,4, are, respectively, , , and . On his side, chooses . Let us recall as well that and could successfully exchange a secret with , namely, and . Then, we have the following steps:
- a
sends to , who computes .
- b
stops when this is sent to
- c
replaces by .
- d
computes , which is broadcasted to every participant, and computes the point .
- e
Now stops the broadcasted message for and gives , . In the meantime, receives the points and from the other users.
- f
Thus,
broadcasts the message
- g
computes , which results in the same point computed by in step d.
At this step, computes , which is the same point previously computed by and . In the same way, computes , which also coincides with the previously computed points, and thus, , , and are sharing the same point, so needs to provide the corresponding information to in so that this participant also obtains the same value.
- h
chooses and provides , , which was the message that broadcasted in step d.
- i
sends .
- j
stops this message and computes
and forges the message that was broadcasted by
in step f, but only
receives this message:
- k
Finally, to recover the common point, computes .
We remark that in the classical man-in-the-middle attack of the Diffie–Hellman key exchange for two participants, shares two different keys for both users, and when some information is sent from one of them to the other one, has to decrypt it using one of these keys and then, if the attacker decides to allow the information to reach the destination, then has to encrypt the information with the corresponding second key before sending it. In this case, the adversary forms part of the communication group as a legal participant and shares the same key with the rest of the participants, so can forge a message from one party to another without the intermediate encryption–decryption process mentioned above in the classical case.
We end this section by introducing a strategy for
to leave the group without the attack being noticed. We first point out that there is not any explanation on how rekeying operations are developed using the key authentication mode in [
12]. Let us suppose that any member of the group can send a rekeying message similarly to in the CLIQUES protocol [
9]. We can distinguish two different cases:
Case 1. The private values are not used in the rekeying messages. In this case, does not obtain authentication of any rekeying message. for any chooses and computes a new key and queries In this situation,
, after carrying out the attack on
, can choose
and compute a new key
. Then,
will query
Thus,
could repeat this as long as desired, taking control of the group, and leave it at any time without letting the users notice the attack.
Case 2. The private values are used in the rekeying messages. In this case, can use these values to obtain authentication as in [12] for the initial key agreement. Then, for any chooses and computes a new key and queries In this situation
, after carrying out the attack on
, can choose
and compute a new key
. Then,
will query
can repeat this strategy, taking control of the group as previously done or stay as another group member until any other user
,
rekeys the group. In that case, the attack will not be discovered until either
or
send a rekeying message, since they will use
or
, respectively, which are not shared by
and
.
Remark 1. In the case of CLIQUES, as was noted above, the values for every , and there is no possibility of discovering the attack since only Case 1 is applied.
Remark 2. In [12], a strongly authenticated protocol, SA-GDH is proposed too. In this case, any two users and share a private value . Then, the above arguments are also applicable for attacking the SA-GDH protocol in the previously considered case of GDH2 ([9]). Remark 3. In [15], the authors introduced a Diffie–Hellman key exchange in a more general setting, i.e., using semigroup actions on an arbitrary set, and later, López-Ramos et al. extended the protocol from two users to an arbitrary finite group of users [16], following the ideas of [9]. Ateniese et al.’s protocol [12] can also be extended to this setting, but instead of using semigroups, given that we need the existence of inverses, these actions have to be defined by groups. In [12], we have a group acting on a second group, so the setting considered by Maze et al. is much more general. However, under the same cryptographic model, the same attack runs as well, so this could be used only in an authenticated links mode, i.e., there must exist some kind of public key infrastructure or any other method to allow participants to authenticate both information and the source of such information. Let us now explain some implications of this attack in a real situation. When this attack is developed on a traditional model of human-to-human or human-to-machine communication, the essential implication is the lack of confidentiality, which in some cases, is a crucial point. In the case of a multiconference among humans in a group, the attacker could stay in the meeting, receiving the transmitted information at the exact same time as the legal group members, and if the attacker, as assumed in the cryptographic model, has control ove the communications not only during the key exchange, then this could send false information to some (or perhaps the rest of the group members), possibly causing misunderstandings in the communication. If the communication is human-to-machines, the consequences can be even worse. Let us assume that, in a medical situation, several machines are sending the vital signs of one or more patients to a medical doctor who has to control the values and decide the appropriate treatment. Firstly, this information must be kept confidential by law, but the real serious situation is when the attacker can, as before, manipulate the transmitted data and cause the doctor to make wrong decisions that could seriously affect the patient’s health condition.
Therefore, this absence of privacy affects the confidentiality and integrity of the transmitted data. However, in a machine-to-machine communication case, as is the case of an IoT network, there is another important property that can be affected: availability.
Let us consider a basic IoT network that is formed by a server, a channel, and a set of devices that send petitions and receive orders. A very common attack is the so-called Denial of Service (DoS), which consists of the impossibility, for instance, of the server to process and attend to the devices’ requests. Given that the communication in this case is among machines, every determined request is given by a different code. Thus, the device encrypts the corresponding code by determining its request and sends it to the server. Then, the server decrypts the received message, and if the code is correct, the request is attended. Otherwise, the message is simply discarded in order to maintain efficiency. Thus, knowing the appropriate session key is crucial in order to correctly encrypt and decrypt the information. In the case of an IoT network, launching a DoS attack from a single malicious device is very difficult due to the very low capacity of the devices and the high quantity of energy that this attack would use. However, in this setting, what is more common are the so-called DDoS attacks, where a set of devices sends this malicious traffic. It is very often that these devices are part of a botnet, i.e., a set of devices that have been infected with malware and that can be controlled by a specific attacker. Thus, if the attacker knows the session key of an IoT network, then it is possible to create a botnet and make them send false requests, which are encrypted properly with the corresponding code and make the server collapse due to the impossibility of meeting so many requests.
However, we can also attack the devices from the infected server in the following manner, producing a different type of attack. The server often sends commands to make the devices in its network execute some code. Then, the attacker could make the servers execute, for instance, ransomware that hijacks the information stored in the devices, making it impossible to access it when this ransomware, or any other type of malware that produces a harmful effect on the devices, is sent to the server.
Other consequences of a lack of privacy in IoT environments can be found in [
3] or [
4] and references therein.
One of the key issues nowadays in cybersecurity is authentication, which is the underlying problem in the protocol we are introducing in this paper. If there is a system that makes it possible to authenticate the source of the received messages, then an attacker will fail in this aim given that, when the incoming messages cannot be certified to be received from a trusted source, then they are simply discarded and so, this attack cannot be developed. In a network where the actors dispose of devices with enough computing and storage resources, the natural solution is to use the standard protocols for authentication. This means deploying a PKI in our network that uses certificates issued by a trusted entity that allows the receiver of any message to authenticate its source. Thus, the source will add some additional authenticating information to the message that can be verified by using the certificate issued by the trusted entity. However, this is not the case for environments such as an IoT network. As we have previously noted, these are composed mostly of light devices with very limited capabilities and that may even be powered by a battery [
1]. Regarding computational capabilities, public key cryptography algorithms consume a lot of resources, and thus, this constitutes a challenge for this type of network [
23]. Concerning storage capabilities, authentication protocols also require storing a list of revoked certificates and this is, again, a challenge given that the RAM is often in the order of tens of kilobytes in these light devices [
11]. Alternatives to classical public key cryptography in IoT can be found in [
4,
23,
24], both from a technology and algorithmic point of view. Thus, the use of the cryptanalyzed protocol would require a joint deployment of one of these emerging technologies (or others) in order to obtain authentication. Another alternative is the use of other group Key Management Protocols that have been shown to be secure in this cryptographic model, cf. [
8].
From the cryptographic point of view, it has been noted previously in this paper that the emergence of quantum computers represents a major challenge for most cryptographic algorithms that nowadays are mainly based on mathematical problems that are difficult to solve from a computational point of view. However, this new generation of computers increases the computational power exponentially and represents one of the major challenges in cybersecurity, given that they overcome all these mathematical problems that underlie the security of the most-used cryptographic algorithms. To address this challenge, in 2017, the NIST called for a contest to select new cryptographic primitives that allowed to obtain secure algorithms against the attack of a quantum computer. In 2023, four algorithms were selected, one for key encapsulation and three others for digital signature. Very recently, two digital signatures and a key encapsulation method were officially standardized [
14]. These algorithms address, on the one hand, the problem of authentication and, on the other hand, the problem of sending a secret through an insecure channel, but as of yet, there is no algorithm showing an alternative to quantum computers that allows establishing a secret collaboratively among two or more parties through such insecure channels. This does not mean, in principle, that Diffie–Hellman [
13] or Group Key Management protocols, such as [
5] or [
9], will be obsolete in the next few years. The problem is finding algebraic structures that can offer a mathematical problem that is difficult to solve even for quantum computers. In [
15,
16], it is shown that we can extend these protocols to more general mathematical settings, so one current challenge is finding a suitable mathematical environment to apply these Group Key Exchange protocols. At the same time, it is also crucial to continue studying methods that test the security of these protocols in determined cryptographic models in order to know the requirements that have to be fulfilled and to keep using them in a secure manner. The discussion in this paper is proof of that.