Optimizing Group Multi-Factor Authentication for Secure and Efficient IoT Device Communications

Abstract

As more Internet of Things (IoT) devices are being used, more sensitive data and services are also being hosted by, or accessed via, IoT devices. This leads to a need for a stronger authentication solution for the IoT context, and a stronger authentication solution tends to be based on several authentication factors. Existing multi-factor authentication solutions are mostly used for user-to-system identity verification scenarios, whereas, in the IoT context, there are device-to-device communication scenarios. Therefore, more work is necessary to investigate how to facilitate multi-factor authentication for device-to-device interactions. As part of our ongoing work on the design of the M2I (Multi-factor Multilevel and Interaction-based) framework to facilitate multi-factor authentication in IoT, this paper reports an extension to an authentication framework published previously that supports the multi-factor authentication of devices in device-to-device and device-to-multidevice interactions. In this extended framework, four authentication protocols are added to facilitate multi-factor group authentication between IoT devices. Analysis results show that the protocols satisfy the specified security requirements and are resilient against authentication-related attacks. The communication and computation overheads of the protocols are also analyzed and compared with those of IoT group authentication solutions and Kerberos. The results show that the symmetric-key-based version of the proposed protocols cut the communication and computational costs, respectively, by 70∼74% and 89∼92% in comparison with those of Kerberos.

1. Introduction

IoT is a dynamic environment in which things, e.g., physical objects, can communicate and interact with each other (send, receive, and process information) [1]. It can be seen as a bridge that links the physical world to the digital one [2]. IoT applications, e.g., Industrial IoT, smart health, and smart city, minimize user involvement through task automation. Hence, IoT interactions are typically between devices, e.g., sensors and actuators [3].

IoT devices are typically equipped with sensors and/or actuators and can operate autonomously [4], i.e., without user involvement. Although the use of IoT applications may bring convenience and real-time feedback, it also introduces several security challenges, e.g., how to authenticate a group of heterogeneous devices securely [5].

Authentication, which is about verifying a claimed identity (ID), is essential for many electronic systems. This is because without reliable authentication, several security services, e.g., access control and intrusion detection, will be at risk. Although a number of authentication solutions, e.g., [6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32], have been introduced to secure identity verification in IoT environments, they mainly provide single-level protection. Existing multilevel solutions are typically for user authentication [33].

As single-factor authentication solutions may not be efficient since they rely on a single credential to secure authentication for different interactions regardless of the risks associated with each interaction, we proposed the M2I framework to facilitate multi-factor authentication in IoT environments [34]. This paper extends the M2I framework to support multidevice-to-device authentication in IoT environments. The key contributions of this work are as follows:

• Comprehensive evaluation of existing IoT group authentication mechanisms, identifying critical limitations in supporting secure and efficient authentication, particularly in the context of multidevice-to-device communication scenarios.
• Design and specification of four novel protocols, HGAKA (Hybrid Group Authentication and Key Acquisition), HGA (Hybrid Group Access), SGAKA (Symmetric-Key-based Group Authentication and Key Acquisition), and SGA (Symmetric-Key-based Group Access), that extend the M2I framework to enable group-based multi-factor authentication tailored for this context.
• Comprehensive security evaluation combining the following:

  –

  Informal analysis to validate security requirements and threat resilience.

  –

  Work factor evaluation to assess the computational effort required for attacks.

  –

  Formal verification using the AVISPA (Automated Validation of Internet Security Protocols and Applications) tool, ensuring confidentiality, authentication, and robustness against a wide range of potential attacks, including replay, impersonation, and man-in-the-middle attacks.

• Detailed performance evaluation and comparative analysis of the proposed protocols against existing state-of-the-art solutions, thoroughly examining both computational and communication overhead to assess their efficiency.
• Experimental and comparative evaluation of communication and computation costs, showing that the symmetric-key-based version of our protocols reduces these costs by 70∼74% and 89∼92%, respectively, compared to Kerberos.

Section 2 analyzes existing solutions. Section 3 presents the high-level ideas used to design and evaluate the M2O (Many-to-One) protocols, design preliminaries, and building blocks. Section 4 introduces the protocols. Section 5 analyzes the security of the protocols. Section 6 compares the protocols with existing IoT group authentication solutions in terms of security requirements and computational costs. Section 7 evaluates the protocols based on experiments, and Section 8 compares the protocols’ costs with those of Kerberos version 5 to evaluate their efficiency. Lastly, Section 9 summarizes research findings and highlights future research directions.

2. Related Work

To address device authentication in IoT environments, Chuang et al. [35] introduced a lightweight device-to-device authentication protocol that uses a hash function, HMAC (Hashed Message Authentication Code), and the XOR (exclusive OR) operation to facilitate continuous authentication. Shah et al. [36] claimed the protocol is not reliable as it assumes that all devices are battery-powered. To overcome this issue, Shah et al. [36] designed a similar lightweight protocol. In addition to the methods employed in [35], the protocol utilizes communication channel properties to generate dynamic session keys. Mahalat et al. [17] proposed a protocol that uses hash, XOR and PUF (Physical Unclonable Function) operations to verify identities. However, their protocol cannot withstand DoS (Denial of Service) attacks, as the protocol starts upon the receipt of a plaintext message received over a public channel. Hence, an attacker can overwhelm the service provider with many requests [33]. Roy et al. proposed several lightweight PUF-based protocols [18,19,20] to secure authentication and reduce authentication overheads. Although PUF-based protocols may reduce authentication overheads, they require the devices involved to be equipped with PUF circuits [34]. To provide confidentiality, symmetric- and asymmetric-key-based solutions have been proposed. Fan et al. [22] proposed a Radio Frequency Identification (RFID) protocol that uses symmetric encryption, XOR, rotation, and permutation to secure authentication. However, their protocol is open to replay attacks [37]. Naeem et al. [29] introduced another RFID-based protocol that uses ECC (Elliptic Curve Cryptography) [38] and a hash function to secure authentication. Izza et al. [30] revealed that Naeem’s protocol cannot withstand impersonation attacks.

To facilitate group authentication, Yildiz et al. [39] presented a lightweight PUF group authentication and key distribution protocol that uses hash, HMAC, XOR, and symmetric encryption to secure authentication. A number of group authentication methods that use secret-sharing schemes, e.g., [40,41], have also been proposed [42]. Chien [40] proposed a scheme that uses bilinear pairing and ECC to facilitate group authentication. Xia et al. [43] show that the scheme is insecure. To address this limitation, Aydin et al. [41] designed a group authentication protocol that uses the ECC algorithm and Shamir’s secret-sharing scheme [44]. Although Aydin et al.’s protocol [41] reduces energy consumption, Xu et al. [42] show that both solutions, refs. [40,41], are vulnerable to impersonation attacks.

Jiang et al. [45] introduced an EAP (Extensible Authentication Protocol)- and ECDH (Elliptic Curve Diffie Hellman)-based protocol to facilitate group authentication. However, their protocol cannot withstand several attacks [46]. To optimize efficiency, Choi et al. [47] proposed a symmetric protocol that aggregates group authentication requests into a single request. Although the protocol reduces authentication overheads, it is vulnerable to DoS attacks [48].

Several Message Authentication Code (MAC) aggregation-based protocols, e.g., [49,50], have been proposed. In addition to MAC aggregation, Fu et al.’s [49] protocol uses pairing-free identity-based encryption to verify group member identities. However, Singh and Shrimankar [51] show that the protocol is insecure. A similar protocol as in [49] was also presented by Parne et al. [50]. However, the authors used symmetric encryption, instead of identity-based encryption. Gupta et al. [52] revealed that the protocol cannot withstand impersonation attacks.

Several 5G (Fifth Generation)-based protocols, e.g., [53,54,55], have been proposed. Ouaissa et al. [53] introduced a 5G-AKA (Authentication and Key Agreement) [56]-based protocol that applies ECDH to secure group authentication. Gharsallah et al. [54] proposed another 5G-based protocol to facilitate group authentication. However, both protocols, refs. [53,54], are vulnerable to replay attacks [57]. Miao et al. [55] presented a protocol that uses the Chinese remainder theorem and the extended chaotic mapping algorithm to facilitate group authentication in 5G networks.

To enhance security, a number of blockchain-based solutions have been proposed. Zhang and Lee [58] proposed a blockchain-based group authentication scheme. The scheme uses a modified group signature to validate blockchain blocks in Blockchain-based Mobile Edge Computing (BMEC) systems and secure authentication. Khalid et al. [59] introduced another blockchain authentication scheme that uses fog computing to reduce authentication delay. Kumar and Sharma [60] show that the scheme may not be suitable for IoT environments due to its high energy consumption. The main limitation of blockchain-based authentication solutions is the high computational overheads triggered by the use of blockchain technology [61].

A comprehensive analysis of IoT authentication solutions designed for different authentication scenarios is provided in [33]. Based on the analysis, it was discovered that they mainly provide single-level protection. Existing multi-factor authentication solutions are typically for user authentication. As a result, we introduced the M2I framework to enable multilevel and interaction-based authentication in IoT environments [34]. This paper extends the M2I framework to handle multidevice-to-device authentication scenarios.

3. High-Level Ideas, Design Preliminaries, and Building Blocks

3.1. High-Level Ideas

The ideas used to minimize authentication costs are as follows:

• Authenticate devices according to their mode of interaction, e.g., device-to-device or multidevice-to-device interactions, to reduce the number of tokens used to facilitate identity verification.
• Use HMAC to aggregate clients’ tokens into a single group token when an authentication instance has more than one client.
• Use the Homomorphic Encryption property to reduce the number of verifications when asymmetric-key ciphers are used.
• Use a secret sharing scheme in symmetric-key-based multidevice-to-device authentication to enable clients to use their tokens (i.e., session key shares) to compute the session key.

3.2. Assumptions

The following assumptions are used in the protocol design:

• Devices have two symmetric keys.
• Devices of classes $C_2$ and $C_{2+}$ each have an additional pair of asymmetric keys ${\mathrm{\{PU}}_{Di}$, ${\mathrm{PR}}_{Di}$} to support asymmetric authentication as they have higher capabilities [33].
• In the case of group authentication, client devices involved in an authentication instance can communicate with each other during the authentication process.
• One of the client devices will be selected as a group leader, and the selection can be based on the computational capabilities of the devices.
• The target device, $D1$, has a strong level of security, including the security of the long-term key ($K_{D1}$) and the private key ($P{R}_{D1}$). In other words, it is assumed that $D1$ and its keys are secure as $D1$ hosts a high or very high value asset, and it should be equipped with a strong level of security protection.

3.3. Performance Metrics

Theoretical analysis and experimental evaluation methods are used to assess the performance of the proposed protocols.

Theoretical Analysis:

• Communication costs are calculated based on the number and size of messages exchanged between protocol participants during execution.
• Computation costs are evaluated according to the number of cryptographic operations performed and the algorithms used to carry out these operations.

Experimental evaluation: PCC (Protocol Crypto Computational) costs are measured by the time required to execute all resource-intensive operations (i.e., cryptographic operations) during protocol execution.

3.4. Building Blocks

3.4.1. Homomorphic Encryption

Homomorphic Encryption (HE) algorithms support computational operations on encrypted data without decrypting them [62]. The results, when decrypted, produce the same output as if the operations were performed on plaintext [63]. Depending on the number and types of operations supported, HE algorithms are often grouped into three categories: (i) Partially Homomorphic Encryption (PHE), which enables the repetition of a single operation, e.g., addition or multiplication, indefinitely; (ii) Somewhat Homomorphic Encryption (SHE), which restricts the number of allowed operations; and (iii) Fully Homomorphic Encryption (FHE), which supports an unrestricted number of operations on encrypted data [64]. The RSA algorithm is an example of a PHE algorithm. This is because it supports a single HE operation, i.e., multiplication, as shown in Figure 1, where $(n,e)$ represents the public key in the RSA encryption scheme [65].

3.4.2. Shamir’s Secret Sharing

Shamir’s secret sharing is a threshold-based $(k,n)$ scheme, where k is the minimum number of shares required to reconstruct the secret, and n is the total number of shares. The scheme splits a secret into n shares. These shares can be distributed among participants. Any subset of the shares can then be used to compute the secret, provided the subset contains at least the threshold number of shares. The scheme provides secrecy, flexibility, and recoverability [44]:

• Secrecy: Given a secret share, $s_i$, it is hard to learn anything about the secret.
• Flexibility: Given a set of secret shares, S, it is easy to add or delete shares without changing the secret, as long as the $length\left(S\right)\ge k$.
• Recoverability: Given a subset of secret shares, $SS$, it is easy to compute the secret if $length\left(SS\right)\ge k$.

The scheme uses polynomial interpolation to facilitate secret share construction and reconstruction operations, respectively. Given a secret, e.g., 679, these operations are explained below [66].

(i)

Secret share construction

• Specify k (e.g., k = 3) and n (e.g., n = 5).
• Choose $k-1$ random numbers, e.g., 50 and 11.
• Build a polynomial of degree $k-1$ using Equation (1), where $a_0$ is the secret and $a_1$ to $a_{k-1}$, the coefficients of the polynomial, are the random numbers chosen in the previous step.

  $$f\left(x\right)=a_0+a_{1}x+.....+a_{k-1}{x}^{k-1}$$

  (1)

  $$\begin{array}{c}\downarrow \end{array}$$

  $$f\left(x\right)=679+50x+11x^2$$
• Construct n shares using the polynomial function, where each share is defined as $(x_i,f\left(x_i\right))$. Given n points, e.g., 1 to 5, the shares are {(1, 740), (2, 823), (3, 928), (4, 1055), (5, 1204)}.

(ii)

Secret recovery

Given any k shares, e.g., (1,740), (3,928), and (5,1204), the polynomial can be reconstructed.

• Calculate the Lagrange polynomials for the x points (i.e., 1, 3, and 5) using Equation (2) [67].

  $$l_i\left(x\right)=\prod _{\begin{array}{c}j=0\\ j\ne i\end{array}}^{k-1}{\displaystyle \frac{x-x_j}{x_i-x_j}}$$

  (2)

  $$\begin{array}{c}\downarrow \end{array}$$

  $$l_0\left(x\right)={\displaystyle \frac{(x-3)}{(1-3)}}{\displaystyle \frac{(x-5)}{(1-5)}}={\displaystyle \frac{x^2-8x+15}{8}}$$

  $$l_1\left(x\right)={\displaystyle \frac{(x-1)}{(3-1)}}{\displaystyle \frac{(x-5)}{(3-5)}}={\displaystyle \frac{x^2-6x+5}{-4}}$$

  $$l_2\left(x\right)={\displaystyle \frac{(x-1)}{(5-1)}}{\displaystyle \frac{(x-3)}{(5-3)}}={\displaystyle \frac{x^2-4x+3}{8}}$$
• Compute the interpolating polynomial using Equation (3) [67].

  $$f\left(x\right)=\sum _{i=0}^{k-1}{y}_i{l}_i\left(x\right)=\sum _{i=0}^{k-1}{y}_i\prod _{\begin{array}{c}j=0\\ j\ne i\end{array}}^{k-1}{\displaystyle \frac{x-x_j}{x_i-x_j}}$$

  (3)

  $$\begin{array}{c}\downarrow \end{array}$$

  $$f\left(x\right)=740\left({\displaystyle \frac{x^2-8x+15}{8}}\right)+928\left({\displaystyle \frac{x^2-6x+5}{-4}}\right)+1204\left({\displaystyle \frac{x^2-4x+3}{8}}\right)$$

  $$f\left(x\right)=679+50x+11x^2$$

  $$\begin{array}{c}\downarrow \\ \mathrm{The} \mathrm{secret} \mathrm{is} 679\\ \end{array}$$

4. The Many-to-One (M2O) Protocols for Multidevice-to-Device Authentication

In certain scenarios, a group of devices may need to access a target device. To address this, we introduce multi-factor hybrid and symmetric-key-based protocols. These protocols enable group authentication using different methods and are divided into two sub-protocols: (1) Group Authentication and Key Acquisition (GAKA) and (2) Group Access (GA). Before discussing the details, we first outline the assumptions used in evaluating the performance of the protocols.

4.1. Performance Evaluation Assumptions

• Identifiers and timestamps are 32 bits long [68].
• Nonces are 128 bits long [69].
• AES-128 is used as the symmetric-key cipher. Hence, the output size is a multiple of 128 bits [70].
• SHA-256 and HMAC-SHA256 are used for hashing, producing 256-bit message digests [71].
• RSA-3072 is used as the asymmetric-key cipher. Although the RSA block size is variable, the maximum input length of the most expensive RSA implementation is defined as the modulus (i.e., $length\left(key\right)$)$-(2\times length(hash\left)\right)-2bytes$ [72]. Hence, the input size is a multiple of 318 bytes = 2544 bits.

4.2. The M2O Hybrid Protocols

M2O hybrid protocols are designed to facilitate group authentication using symmetric- and asymmetric-key-based methods. At first, clients verify their identities to the Authentication Server (AS) by demonstrating knowledge of their long-term keys to obtain access credentials in the hybrid GAKA protocol. Then, they use the credentials to verify their identities to the target device in the hybrid GA protocol.

4.2.1. The Hybrid Group Authentication and Key Acquisition (HGAKA) Protocol

The HGAKA protocol performs two functions: (1) group authentication to the server, using a nested HMAC value that has been computed using clients’ long-term keys to verify their identities, and (2) the distribution of the authorization nonces (OrNonces) that are freshly generated by the server for all the devices in the group. The OrNonces are then used to authenticate the clients to the target device in the HGA protocol.

Messages

The protocol has $3+(2\times NC)$ messages, where NC represents the number of clients, as shown in Figure 2 and Figure 3.

Operation Description

Step1-HGAKA:

The group leader, C3, constructs and sends $Msg1$, which contains a fresh timestamp and EnNonce, to the server. If no response is received within a specific amount of time, the leader resends the message or terminates the session.

Step2-HGAKA:

The server decrypts $E{K}_{C3}[I{D}_{C-List},I{D}_{D1},EnNonce{1}_{C3}^{HGAKA},T{s}_{C3}^{HGAKA}]$ using $K_{C3}$ to verify $T{s}_{C3}^{HGAKA}$ freshness. If fresh, the server verifies the C3 identity and then generates $EnNonce{2}_{AS}^{HGAKA}$ to construct and send $Msg2$ to C3.

Step3-HGAKA:

C3 decrypts $E{K}_{C3}[EnNonce{1}_{C3}^{HGAKA},EnNonce{2}_{AS}^{HGAKA}]$ using $K_{C3}$ to verify $EnNonce{1}_{C3}^{HGAKA}$. Then, it uses $EnNonce{2}_{AS}^{HGAKA}$ as a seed to compute $HM3$, where $HM3=HMAC(K_{C3},EnNonce{2}_{AS}^{HGAKA})$. Then, C3 sends $Msg3$ to C2, a non-leader client.

Step4-HGAKA:

C2 uses the received $HM$ value (i.e., $HM3$) as a seed to compute $HM2$, where $HM2=HMAC(K_{C2},HM3)$. $Msg4$, which contains $HM2$, is then sent to C1, another non-leader client in the group.

Step5-HGAKA:

C1 uses $HM2$ as a seed to compute $HM1$, where $HM1=HMAC(K_{C1},HM2)$.

Step6-HGAKA:

When the last $HM$ value (i.e., $HM1$) is received, C3 generates

$EnNonce{3}_{C3}^{HGAKA}$ and uses it to construct and send $Msg6$ to the server.

Step7-HGAKA:

The server decrypts $E{K}_{C3}[EnNonce{2}_{AS}^{HGAKA},EnNonce{3}_{C3}^{HGAKA}]$ using $K_{C3}$ to verify $EnNonce{2}_{AS}^{HGAKA}$. Then, it verifies $HM1$, and if $HM1$ is verified, mutual authentication is achieved between the group leader and the server. The server then generates $EnNonce{4}_{AS}^{HGAKA}$, $EnNonce{5}_{AS}^{HGAKA}$, n $OrNonces$ (where n is the number of clients involved), and a session key $\left(SK\right)$. Then, it computes an Encrypted Authorization Verification Token (where $EncAuthVeriToken=EP{U}_{D1}[OrNonc{e}_{C1}\left|\right|OrNonc{e}_{C2}\left|\right|OrNonc{e}_{C3}\left]\right)$. $Msg7$ is then sent to the group leader, C3.

Step8-HGAKA:

C3 decrypts $E{K}_{C3}\left[SK\right||OrNonc{e}_{C3}\left|\right|EnNonce{3}_{C3}^{HGAKA}]$ using $K_{C3}$ to verify $EnNonce{3}_{C3}^{HGAKA}$. If verified, C3 obtains its OrNonce value (i.e., $OrNonc{e}_{C3}$) and $SK$. Then, it sends $Msg8$ and $Msg9$ to distribute the rest of the OrNonce values to their intended recipients. Once these messages are sent, the protocol is then terminated.

Performance Evaluation

• Communication cost

The HGAKA communication cost is $\left(256\right(3NC-2)+128[(32\times NC)+192]+128[2544[128\times NC]]+1536)$ bits, as shown in

Table 1. HGAKA communication cost.

Entities	Messages	Items	Length (bits)
Client devices leader	Msg1	$E{K}_{C3}[I{D}_{C-List},I{D}_{D1},EnNonce{1}_{C3}^{HGAKA},T{s}_{C3}^{HGAKA}]$	$128\left[\right(32\times NC)+192]$
AS	Msg2	$E{K}_{C3}[EnNonce{1}_{C3}^{HGAKA},EnNonce{2}_{AS}^{HGAKA}]$	256
Client device	Msg3	$HMi$	$256\times NC$
Client devices leader	Msg4	$HM1,E{K}_{C3}[EnNonce{2}_{AS}^{HGAKA},EnNonce{3}_{C3}^{HGAKA}]$	512
AS	Msg5	$E{K}_{C1}[OrNonc{e}_{C1}\left|\right|EnNonce{4}_{AS}^{HGAKA}\left]\right||$ $E{K}_{C2}[OrNonc{e}_{C2}\left|\right|EnNonce{5}_{AS}^{HGAKA}\left]\right||$ $E{K}_{C3}\left[SK\right||OrNonc{e}_{C3}\left|\right|EnNonce{3}_{C3}^{HGAKA}\left]\right||$ $E{K}_{D1}[E{K}_{GD1}\left[SK\right],EP{U}_{D1}[OrNonc{e}_{C1}\left|\right|$ $OrNonc{e}_{C2}\left|\right|OrNonc{e}_{C3}\left]\right]\left|\right|H(E{K}_{GD1}\left[SK\right],$ $EP{U}_{D1}[OrNonc{e}_{C1}\left|\right|OrNonc{e}_{C2}\left|\right|OrNonc{e}_{C3}\left]\right)$	$256\times (NC-1)+$ $128\left[2544\right[128\times NC\left]\right]+768$
Client devices leader	Msg6	$E{K}_{Ci}[OrNonc{e}_{Ci}\left|\right|EnNonce{i}_{AS}^{HGAKA}]$	$256\times (NC-1)$
Communication cost			$256(3NC-2)+$ $128\left[\right(32\times NC)+192]+$ $128\left[2544\right[128\times NC\left]\right]+1536$

. The third message, $Msg3$, is sent to all client devices. The last message, $Msg6$, is sent to all non-leader client devices. For example, if three client devices acquire a group access credential through the HGAKA protocol, the communication cost is $\left(256\right(3\times 3-2)+128[(32\times 3)+192]+128[2544[128\times 3]]+1536)$ bits = 784 bytes.

• Computation cost

The HGAKA computation cost is $(8T_{SE}+T_{AE}+2NC(T_{SE}+T_{HMAC})+T_H)$, as presented in

Table 2. HGAKA computation cost.

Protocol	Entities			Total Cost
	Client Devices		AS
	Leader	Non-Leader
HGAKA	$4T_{SE}+T_{HMAC}$	$(NC-1)\times$ $(T_{SE}+T_{HMAC})$	$(5+NC)T_{SE}+$ $T_{AE}+NC\times$ $T_{HMAC}+T_H$	$8T_{SE}+T_{AE}+$ $2NC(T_{SE}+T_{HMAC})+T_H$
	$3T_{SE}+NC(T_{SE}+T_{HMAC})$

. For example, if three client devices acquire a group access credential through the HGAKA protocol, the computation cost is $(8T_{SE}+T_{AE}+2\times 3(T_{SE}+T_{HMAC})+T_H)=(14T_{SE}+T_{AE}+6T_{HMAC}+T_H)$.

4.2.2. The Hybrid Group Access (HGA) Protocol

The HGA protocol performs one function, i.e., allowing the group to access a target device. The protocol uses clients’ verification tokens (i.e., $OrNonce$ values encrypted with the public key of the target device) to verify their identities to the target device.

Messages

The protocol has $2\times NC$ messages, as shown in Figure 4 and Figure 5.

Operation Description

Step1-HGA:

Clients generate their verification tokens by encrypting their $OrNonce$ values using the target device, D1, public key (i.e., $EP{U}_{D1}\left[OrNonc{e}_{Ci}\right]$). Once generated, each client constructs a pre-protocol message (PreHGA-Msg) and sends it to the group leader C3.

Step2-HGA:

Once clients’ verification tokens are all received, C3 generates its token (i.e., $EP{U}_{D1}\left[OrNonc{e}_{C3}\right]$) to compute the Encrypted Group Authenticator (EncGroupAuthenticator), where $EncGroupAuthenticator$ = $EP{U}_{D1}\left[OrNonc{e}_{C1}\right]\left|\right|EP{U}_{D1}\left[OrNonc{e}_{C2}\right]\left|\right|EP{U}_{D1}\left[OrNonc{e}_{C3}\right]$. Once computed, C3 generates a fresh timestamp and EnNonce and sends $Msg1$ to D1. If no response is received within a specific amount of time, C3 resends the message or terminates the session.

Step3-HGA:

D1 performs the following operations:

• It decrypts $E{K}_{D1}[E{K}_{GD1}\left[SK\right],EP{U}_{D1}[OrNonc{e}_{C1}\left|\right|OrNonc{e}_{C2}\left|\right|OrNonc{e}_{C3}\left]\right]$ using $K_{D1}$ and $K_{GD1}$ to obtain SK. Then, it uses SK to decrypt $ESK[I{D}_{C-List},I{D}_{D1},EnNonce{1}_{C3}^{HGA},T{s}_{C3}^{HGA}]$ to verify $T{s}_{C3}^{HGA}$ freshness. If fresh, D1 generates a fresh $H’$ value and compares it to $H(E{K}_{GD1}\left[SK\right],EP{U}_{D1}[OrNonc{e}_{C1}\left|\right|OrNonc{e}_{C2}\left|\right|OrNonc{e}_{C3}\left]\right)$ to verify its integrity before decrypting it using its private key $P{R}_{D1}$ to obtain $AuthVeriToken$. This is to counter $DoS$ attacks since a hashing operation is much faster than RSA operations.
• If the verification is positive, D1 decrypts $EncAuthVeriToken(EP{U}_{D1}[OrNonc{e}_{C1}\left|\right|OrNonc{e}_{C2}\left|\right|OrNonc{e}_{C3}\left]\right)$ using $P{R}_{D1}$ to obtain $OrNonc{e}_{C1}$, $OrNonc{e}_{C2},$ and $OrNonc{e}_{C3},$ then it computes $EP{U}_{D1}[OrNonc{e}_{C1}\times OrNonc{e}_{C2}\times OrNonc{e}_{C3}]=X$. D1 then uses the $EncGroupAuthenticator$ to obtain clients’ verification tokens to compute Y, where $Y=EP{U}_{D1}\left[OrNonc{e}_{C1}\right]\times EP{U}_{D1}\left[OrNonc{e}_{C2}\right]\times EP{U}_{D1}[OrNonc{e}_{C3}]$. Then, it compares X to Y, where $X=EP{U}_{D1}[OrNonc{e}_{C1}\times OrNonc{e}_{C2}\times OrNonc{e}_{C3}]$ and $Y=EP{U}_{D1}\left[OrNonc{e}_{C1}\right]\times EP{U}_{D1}[OrNonc{e}_{C2}]\times EP{U}_{D1}\left[OrNonc{e}_{C3}\right]$ to verify the integrity of the received tokens. Owing to the Homomorphic Encryption property, D1 can perform this verification without the need of accessing plaintexts of the clients’ verification tokens. If this comparison produces a positive outcome, the group authentication for D1 access is successful. As a result, D1 generates $EnNonce{2}_{D1}^{HGA}$ and, $EnNonce{3}_{D1}^{HGA}$, and sends $Msg2$ to achieve mutual authentication with the group leader.

Step4-HGA:

C3 decrypts $ESK\left[EnNonce{1}_{C3}^{HGA}\right]$ using $SK$ to verify $EnNonce{1}_{C3}^{HGA}$, and upon successful verification, mutual authentication is achieved between the group leader and the target device. C3 then sends $Msg3$ and $Msg4$ to distribute $SK$ to the clients involved. Once these messages are sent, the protocol is then terminated.

Performance Evaluation

• Communication cost

The HGA communication cost is ($3056(NC-1)+2544\times NC+128\left[\right(32\times NC)+192]+128\left[2544\right[128\times NC\left]\right]+512$) bits, as presented in

Table 3. HGA communication cost.

Entities	Messages	Items	Length (bits)
Non-leader client device	PreHGA-Msgi	$EP{U}_{D1}\left[OrNonc{e}_{Ci}\right]$	$2544\times (NC-1)$
Client device leader	Msg1	$ESK[I{D}_{C-List},I{D}_{D1},EnNonce{1}_{C3}^{HGA},$ $T{s}_{C3}^{HGA}],EP{U}_{D1}\left[OrNonc{e}_{C1}\right]\left|\right|$ $EP{U}_{D1}\left[OrNonc{e}_{C2}\right]\left|\right|EP{U}_{D1}\left[OrNonc{e}_{C3}\right],$ $E{K}_{D1}[E{K}_{GD1}\left[SK\right],EP{U}_{D1}[OrNonc{e}_{C1}\left|\right|$ $OrNonc{e}_{C2}\left|\right|OrNonc{e}_{C3}\left]\right]\left|\right|H(E{K}_{GD1}\left[SK\right],$ $EP{U}_{D1}[OrNonc{e}_{C1}\left|\right|OrNonc{e}_{C2}\left|\right|$ $OrNonc{e}_{C3}\left]\right)$	$128\left[\right(32\times NC)+$ $192]+2544\times$ $NC+128\left[2544\right[$ $128\times NC\left]\right]+384$
Target device	Msg2	$ESK\left[EnNonce{1}_{C3}^{HGA}\right],EOrNonc{e}_{C1}\left[SK\right||$ $EnNonce{2}_{D1}^{HGA}],EOrNonc{e}_{C2}\left[SK\right||$ $EnNonce{3}_{D1}^{HGA}]$	$256\times (NC-1)+$ 128
Client device leader	Msg3	$EOrNonc{e}_{Ci}\left[SK\right||EnNonce{i}_{D1}^{HGA}]$	$256\times (NC-1)$
Communication cost			$3056(NC-1)+$ $2544\times NC+$ $128\left[\right(32\times NC)+$ $192]+128[2544[$ $128\times NC\left]\right]+512$

. The initial message, $PreHGA-Msg$, is sent by all non-leader client devices. The third message, $Msg3$, is sent to all non-leader client devices. For example, if three client devices authenticate themselves through the HGA protocol, the communication cost is $\left(3056\right(3-1)+2544\times 3+128[(32\times 3)+192]+128[2544[128\times 3]]+512)$ bits = 2150 bytes.

• Computation cost

The HGA computation cost is $((4+2NC)T_{SE}+(1+NC)T_{AE}+T_{AD}+T_H)$, as illustrated in

Table 4. HGA computation cost.

Protocol	Entities			Total Cost
	Client Devices		Target Device
	Leader	Non-Leader
HGA	$2T_{SE}+T_{AE}$	$(NC-1)\times$ $(T_{SE}+T_{AE})$	$(3+NC)T_{SE}+$ $T_{AE}+T_{AD}+T_H$	$(4+2NC)T_{SE}+$ $(1+NC)T_{AE}+T_{AD}+T_H$
	$T_{SE}+NC(T_{SE}+T_{AE})$

. For instance, if three devices authenticate themselves to a target device through the HGA protocol, the computation cost is $((4+2\times 3)T_{SE}+(1+3)T_{AE}+T_{AD}+T_H)$ = $(10T_{SE}+4T_{AE}+T_{AD}+T_H)$.

4.3. The M2O Symmetric-Key-Based Protocols

While the M2O hybrid protocols present a reliable group authentication solution, it may not be suitable in some cases as it requires the target device to support asymmetric cryptography. Asymmetric cryptography is typically not suitable for $C_0$ and $C_1$ devices as it could be too demanding for their capabilities. To address this issue, this section presents an enhanced version of the protocols that employs only symmetric cryptographic primitives. At first, clients verify their identities to the server by demonstrating knowledge of their long-term keys to obtain session key shares in the symmetric-key-based GAKA protocol. Then, they use the shares to verify their identities to the target device in the symmetric-key-based GA protocol.

4.3.1. The Symmetric-Key-Based Group Authentication and Key Acquisition (SGAKA) Protocol

The SGAKA protocol performs two functions: (1) group authentication to the server and (2) the distribution of the group session key shares that are freshly generated by the server for all the devices in the group. The shares are then used in the SGA protocol to verify the clients’ identities to the target device and compute the session key. Similar to HGAKA, SGAKA uses a nested HMAC value that has been computed using the clients’ long-term keys to verify their identities to the server.

Messages

The protocol consists of the same number of messages as the HGAKA protocol, i.e., $3+(2\times NC)$ messages. However, as presented in Figure 6 and Figure 7, the items in the last three messages, i.e., Msg7 to Msg9, are different.

Operation Description

The first six steps of the SGAKA protocol are identical to the HGAKA protocol, discussed in Section 4.2.1. The rest of the steps are as follows:

Step7-SGAKA:

The server decrypts $E{K}_{C3}[EnNonce{2}_{AS}^{SGAKA},EnNonce{3}_{C3}^{SGAKA}]$ to verify $EnNonce{2}_{AS}^{SGAKA}$. Then, it verifies $HM1$, and if $HM1$ is verified, the AS generates $EnNonce{4}_{AS}^{SGAKA}$, $EnNonce{5}_{AS}^{SGAKA}$, $EnNonce{6}_{AS}^{SGAKA}$, n shares of the session key (i.e., $SK1$, $SK2$, …$SKn$), and an encrypted shares token, where the $EncSharesToken=(E{K}_{D1}\left[SK1\right|\left|SK2\right||E{K}_{GD1}\left[SK3\right]\left|\right|EnNonce{6}_{AS}^{SGAKA}\left]\right)$. Then, it constructs and sends Msg7.

Step8-SGAKA:

C3 decrypts $E{K}_{C3}\left[SK3\right||EnNonce{3}_{C3}^{SGAKA}]$ using $K_{C3}$ to verify $EnNonce{3}_{C3}^{SGAKA}$. If verified, C3 obtains its $SK$ share (i.e., $SK3$). Then, it constructs and sends Msg8 and Msg9 to distribute the rest of the session key shares to their intended recipients. Once these messages are sent, the protocol is terminated.

At this stage, each client has one share of the session key. However, not a single device could reconstruct $SK$ and not a single device could gain access to D1.

Performance Evaluation

• Communication cost

The SGAKA communication cost is $(256\times (3NC-1)+128[(32\times NC)+192]+128[(128\times NC)+128]+768)$ bits as shown in

Table 5. SGAKA communication cost.

Entities	Messages	Items	Length (bits)
Client device leader	Msg1	$E{K}_{C3}[I{D}_{C-List},I{D}_{D1},EnNonce{1}_{C3}^{SGAKA},T{s}_{C3}^{SGAKA}]$	$128\left[\right(32\times NC)+$ $192]$
AS	Msg2	$E{K}_{C3}[EnNonce{1}_{C3}^{SGAKA},EnNonce{2}_{AS}^{SGAKA}]$	256
Client device	Msg3	$HMi$	$256\times NC$
Client device leader	Msg4	$HM1,E{K}_{C3}[EnNonce{2}_{AS}^{SGAKA},EnNonce{3}_{C3}^{SGAKA}]$	512
AS	Msg5	$E{K}_{C1}\left[SK1\right||EnNonce{4}_{AS}^{SGAKA}],E{K}_{C2}\left[SK2\right]\left|\right|$ $EnNonce{5}_{AS}^{SGAKA}],E{K}_{C3}\left[SK3\right||EnNonce{3}_{C3}^{SGAKA}],$ $E{K}_{D1}\left[SK1\right|\left|SK2\right||E{K}_{GD1}\left[SK3\right]\left|\right|EnNonce{6}_{AS}^{SGAKA}]$	$(256\times NC)+$ $128\left[\right(128\times NC)+$ $128]$
Client device leader	Msg6	$E{K}_{Ci}\left[SKi\right||EnNonc{e}_{AS}^{SGAKA}]$	$256\times (NC-1)$
Communication cost			$256\times (3NC-1)+$ $128\left[\right(32\times NC)+$ $192]+128[(128\times$ $NC)+128]+768$

. Similar to the HGAKA protocol, Msg3 and Msg6 are sent to all client devices and non-leader client devices, respectively. For example, if three client devices acquire a group access credential through the SGAKA protocol, the communication cost is $(256\times (3\times 3-1)+128[(32\times 3)+192]+128[(128\times 3)+128]+768)$ bits = 464 bytes.

• Computation cost

The SGAKA computation cost is $((8+2NC)T_{SE}+2NC\times T_{HMAC})$, as shown in

Table 6. SGAKA computation cost.

Protocol	Entities			Total Cost
	Client Devices		AS
	Leader	Non-Leader
SGAKA	$4T_{SE}+T_{HMAC}$	$(NC-1)\times$ $(T_{SE}+T_{HMAC})$	$(5+NC)T_{SE}$ + $NC\times T_{HMAC}$	$(8+2NC)T_{SE}$ + $2NC\times T_{HMAC}$
	$3T_{SE}+NC(T_{SE}+T_{HMAC})$

. For instance, if three devices acquire a group access credential through the SGAKA protocol, the computation cost is $((8+2\times 3)T_{SE}+2\times 3T_{HMAC})$ = $(14T_{SE}+6T_{HMAC})$.

4.3.2. The Symmetric-Key-Based Group Access (SGA) Protocol

The SGA protocol uses clients’ verification tokens (i.e., $ESKi[I{D}_{Ci},EnNonce]$) to verify their identities to the target device. The protocol is invoked by the group leader, C3, upon receiving the clients’ verification tokens.

Messages

SGA protocol contains $1+NC$ messages, as shown in Figure 8 and Figure 9.

Operation Description

Step1-SGA:

Clients generate their verification tokens using their $SK$ shares (i.e., $ESKi[I{D}_{Ci},$

$EnNonce]$). Once generated, each client constructs a pre-protocol message (PreSGA-Msg) and sends it to the group leader C3.

Step2-SGA:

Upon the receipt of the clients’ verification tokens, C3 generates a fresh $EnNonce$ and timestamp to compute the Encrypted Group Verification Token (EncGroupVeriToken), where $EncGroupVeriToken=ESK1[I{D}_{C1},EnNonce{1}_{C1}^{SGA}],$

$ESK2[I{D}_{C2},EnNonce{2}_{C2}^{SGA}],ESK3[I{D}_{C-List},I{D}_{D1},EnNonce{3}_{C3}^{SGA},T{s}_{C3}^{SGA}]$). Then, it constructs and sends Msg1. If no response is received within a specific amount of time, the leader resends the message or terminates the session.

Step3-SGA:

Upon the receipt of Msg1, D1 performs the following operations:

• It decrypts $EncSharesToken(E{K}_{D1}\left[SK1\right|\left|SK2\right||E{K}_{GD1}\left[SK3\right]\left|\right|EnNonce{6}_{AS}^{SGAKA}\left]\right)$ using $K_{D1}$ and $K_{GD1}$ to obtain the session key shares. Then, it decrypts $ESK3[I{D}_{C-List},I{D}_{D1},EnNonce{3}_{C3}^{SGA},T{s}_{C3}^{SGA}]$ using $SK3$ to verify $T{s}_{C3}^{SGA}$ freshness.
• If fresh, D1 decrypts the clients’ verification tokens using their $SK$ shares. Then, it uses these tokens with $I{D}_{C-List}$ to verify their identities.
• If verified, the group authentication for D1 access is successful. Therefore, D1 computes $SK$ using the session key shares. Then, it generates $EnNonce{4}_{D1}^{SGA}$ and sends Msg2.

Step4-SGA:

C3 decrypts $ESK3\left[EnNonce{3}_{C3}^{SGA}\right]$ using $SK3$ to verify $EnNonce{3}_{C3}^{SGA}$. After verification, mutual authentication is achieved between C3 and D1. As a result, C3 collaborates with the clients involved to compute the session key. Once computed, C3 decrypts $ESK\left[SK\right|\left|EnNonce{4}_{D1}^{SGA}\right]$ to verify the integrity of the computed SK.

Performance Evaluation

• Communication cost

The SGA communication cost is $(512\times (NC-1)+128[(32\times NC)+192]+128[(128\times NC)]+512)$ bits, as presented in

Table 7. SGA communication cost.

Entities	Messages	Items	Length (bits)
Non-leader client device	PreSGA- Msgi	$ESKi[I{D}_{Ci},EnNonc{e}_{Ci}^{SGA}]$	$256\times (NC-1)$
Client device leader	Msg1	$ESK1[I{D}_{C1},EnNonce{1}_{C1}^{SGA}],ESK2[I{D}_{C2},$ $EnNonce{2}_{C2}^{SGA}],ESK3[I{D}_{C-List},I{D}_{D1},$ $EnNonce{3}_{C3}^{SGA},T{s}_{C3}^{SGA}],E{K}_{D1}\left[SK1\right|\left|SK2\right||$ $E{K}_{GD1}\left[SK3\right]\left|\right|EnNonce{6}_{AS}^{SGAKA}]$	$256\times (NC-1)+$ $128\left[\right(32\times NC)+$ $192]+128[(128\times$ $NC\left)\right]+128$
Target device	Msg2	$ESK3\left[EnNonce{3}_{C3}^{SGA}\right]\left|\right|ESK\left[SK\right||$ $EnNonce{4}_{D1}^{SGA}]$	384
Communication cost			$512\times (NC-1)+$ $128\left[\right(32\times NC)+$ $192]+128[(128\times$ $NC\left)\right]+512$

. Similar to the HGA protocol, the initial message (i.e., PreSGA-Msg) is sent by all non-leader client devices. For example, if three client devices authenticate to a device using the SGA protocol, the communication cost is $(512\times (3-1)+128[(32\times 3)+192]+128[(128\times 3)]+512)$ bits = 288 bytes.

• Computation cost

The SGA computation cost is $\left((6+2NC)T_{SE}\right)$, as illustrated in

Table 8. SGA computation cost.

Protocol	Entities			Total Cost
	Client Devices		Target Device
	Leader	Non-Leader
SGA	$3T_{SE}$	$(NC-1)T_{SE}$	$(4+NC)T_{SE}$	$(6+2NC)T_{SE}$
	$(2+NC)T_{SE}$

. For instance, if three client devices authenticate to a device, the computation cost is $\left((6+2\times 3)T_{SE}\right)$ = $12T_{SE}$.

5. Security Analyses

Protocol security is assessed through informal analysis, work factor evaluation, and formal verification conducted via the AVISPA tool.

5.1. Informal Analysis

The protocols are analyzed against the requirements for a secure entity authentication service and threats that should be countered by the service [34].

5.1.1. Requirement Analysis

• R1: Mutual authentication: The challenge–response authentication method is used between a group leader and external entities, such as authentication servers or target devices, to establish mutual authentication. An invalid response results in the immediate termination of the protocol execution.
• R2: Freshness: This is verified using timestamps and random numbers.
• R3: Confidentiality: Symmetric- and asymmetric-key cryptosystems are used to protect secret message items, e.g., credentials.
• R4: Authorization: The authentication server checks the authorization status of clients involved in the GAKA protocols before issuing access credentials. Furthermore, in the HGA protocol, the target device uses the clients’ authorization tokens (i.e., $OrNonces$) to verify their access rights.
• R5: Availability: The protocols are designed to withstand DoS attacks. Receiving an invalid request or response will result in protocol termination, allowing the service provider to serve legitimate users.

5.1.2. Threat Analysis

• Impersonation attacks

  (i)

  Client impersonation: In the GAKA protocols, adversaries cannot compute a client $HM$ value without the client’s long-term key, nor can they forge an access request without the group leader’s long-term key and the group $HM$ value. In other words, forging access requests successfully requires compromising all clients. In the HGA protocol, adversaries cannot impersonate a client without knowing the client’s authorization nonce ($OrNonce$) value or forge access requests without compromising the $session key$, $EncGroupAuthenticator$, and $EncAuthVeriToken$. Lastly, adversaries cannot impersonate a client in the SGA protocol without the client’s session key share or forge a successful device access request without knowing the session key shares of all clients involved and the $EncSharesToken$. As a result, the protocols can withstand client impersonation attacks.

  (ii)

  Authentication server impersonation: It is not possible to impersonate the authentication server without compromising the group leader’s long-term key.

  (iii)

  Target impersonation: Adversaries cannot impersonate a target device without compromising at least two keys, e.g., the session key and the target’s private key ($P{R}_{Di}$), in the HGA protocol. As for the SGA protocol, they will not be able to impersonate the target device without either its long-term key and group key, or its long-term key and the session key shares of all clients involved. Thus, the protocols are also resilient to target impersonation.

• Eavesdropping: As secret message components (e.g., authentication information) are always encrypted, intercepted messages cannot be used to compromise authentication.
• Replay: Replayed messages can be detected as all protocols use a combination of random numbers and timestamps to provide message freshness.
• Denial of service: An adversary cannot forge legitimate access requests to occupy clients, target devices, or the authentication server without compromising the keys involved. As a result, illegitimate access requests and messages are discarded in all protocols.

5.2. Work Factor Evaluation

The computational complexity required to breach security using brute force is determined by the security strength of a solution [73]. To ensure security beyond 2030, the security strength of a solution should not be less than 128 bits [74]. In other words, the work factor to breach the solution should not be less than $2^{128}$.

Table 9. Work factor evaluation.

Protocol	Work Factor
HGAKA	$NC\times 2^{128}$
HGA	$2^{128}+2^{128}$
SGAKA	$NC\times 2^{128}$
SGA	$2^{128}+2^{128}$

shows the work factor evaluation of the proposed protocols. In the GAKA protocols, successfully forging access requests requires the long-term keys of all participating clients (i.e., $K_{C-List}$), and hence, their work factor is $NC\times 2^{128}$, where $NC$ is the number of clients. As for the GA protocols, at least two keys have to be compromised (e.g., $K_{Di}$ and $K_{GDi}$). Thus, the work factor is $2^{128}+2^{128}$.

5.3. Formal Security Verification

Protocol correctness evaluation is carried out using AVISPA [75]. Two AVISPA back-end verification tools are used: CL-AtSe, a tool that applies constraint logic for attack exploration, and OFMC, which performs model checking in an on-the-fly manner [76]. Both tools use several automatic techniques to perform their functions. In this study, AVISPA was employed to assess confidentiality, authentication, and robustness against potential attacks [77]. The formal security verification results are presented in Figure 10, Figure 11, Figure 12 and Figure 13. The figures clearly indicate that all protocols meet the specified requirements—namely, authentication and confidentiality—and are resilient to known attacks.

6. Performance Analysis and Comparison Study

To assess protocol performance, this section presents a comparative analysis of our protocols and existing IoT group authentication solutions in terms of security requirements, communication, and computational overheads.

Table 10. IoT group authentication solution security analysis.

IoT Group Authentication Solutions	R1	R2	R3	R4	R5	MA
Yildiz et al. [39]	✓	✓	✓	x	✓	x
Chien [40]	o	✓	o	x	x	x
Aydin et al. [41]	o	x	✓	x	x	x
Zhang et al. [58]	✓	o	✓	x	✓	x
Khalid et al. [59]	✓	✓	✓	✓	o	x
Jiang et al. [45]	✓	✓	o	x	x	x
Choi et al. [47]	✓	x	o	x	x	x
Fu et al. [49]	✓	o	✓	x	x	x
Singh and Shrimankar [51]	✓	✓	✓	x	✓	x
Parne et al. [50]	✓	✓	✓	x	x	x
5G-AKA [56]	✓	x	✓	✓	o	x
Ouaissa et al. [53]	✓	o	✓	x	x	x
Gharsallah et al. [54]	✓	x	o	x	x	x
Miao et al. [55]	✓	✓	✓	x	✓	x
The M2O hybrid protocols	✓	✓	✓	✓	✓	✓
The M2O symmetric-key-based protocols	✓	✓	✓	✓	✓	✓

✓: supported; x: not supported; o: partially supported. R1: mutual authentication; R2: message freshness; R3: confidentiality; R4: authorization; R5: availability; MA: multi-factor authentication.

analyzes the protocols in terms of the security requirements discussed in Section 5.1.1.

Table 11. IoT group authentication solution communication costs.

IoT Group Authentication Solutions	Communication Cost (bits)
Jiang et al. [45]	$NC\times 1600+1088$
Choi et al. [47]	$NC\times 1200+1408$
Fu et al. [49]	$NC\times 2112$
Singh and Shrimankar [51]	$NC\times 544+1264$
Parne et al. [50]	$NC\times 1600+1912$
5G-AKA [56]	$NC\times 1920$
Ouaissa et al. [53]	$NC\times 960+1344$
Gharsallah et al. [54]	$NC\times 848+656$
Miao et al. [55]	$NC\times 1760+1472$
M2O hybrid protocols	$256(3NC-2)+128\left[\right(32\times NC)+192]+$ $128\left[2544\right[128\times NC\left]\right]+1536+3056(NC-1)+$ $2544\times NC+128\left[\right(32\times NC)+192]+$ $128\left[2544\right[128\times NC\left]\right]+512$
M2O symmetric-key-based protocols	$256\times (3NC-1)+128\left[\right(32\times NC)+192]+$ $128\left[\right(128\times NC)+128]+768$ + $512\times (NC-1)+$ $128\left[\right(32\times NC)+192]+128\left[\right(128\times NC\left)\right]+512$

and

Table 12. IoT group authentication solution computation costs.

IoT Group Authentication Solutions	Computation Cost
Jiang et al. [45]	$NC\times (10T_H+2T_{rand}+3T_{mul}+2T_{AE})+$ $8T_H+2T_{rand}+3T_{mul}+2T_{AE}$
Choi et al. [47]	$NC\times (6T_H+2T_{mod}+2T_{SE}+T_{xor})+$ $4T_H+T_{rand}+T_{xor}$
Fu et al. [49]	$NC\times (11T_H+3T_{rand}+4T_{mul}+6T_{xor})+$ $(4T_H+2T_{rand}+2T_{mul}+T_{xor})$
Singh and Shrimankar [51]	$NC\times (7T_H+4T_{SE}+2T_{xor})+2T_H+T_{rand}$
Parne et al. [50]	$NC\times (7T_H+4T_{SE})+4T_H$
5G-AKA [56]	$NC\times (2T_{AE}+17T_H)$
Ouaissa et al. [53]	$(12NC+6)T_H+NC\times (2T_{xor}+T_{rand})+2T_{mul}$
Gharsallah et al. [54]	$NC\times (15T_H+2T_{xor}+2T_{mul})+(NC+2)T_{rand}$
Miao et al. [55]	$NC\times (6T_{ccm}+13T_H+7T_{xor})+4T_{ccm}+8T_H+2T_{xor}$
M2O hybrid protocols	$12T_{SE}+2T_{AE}+2NC(2T_{SE}+T_{HMAC})+NC{T}_{AE}+$ $T_{AD}+2T_H$
M2O symmetric-key-based protocols	$(14+4NC)T_{SE}+2NC\times T_{HMAC}$

compare the communication and computation costs of our protocols with those of IoT group authentication solutions [57], respectively. The tables highlight the following findings.

First, the communication and computational costs of all protocols increase as the device count rises. This is expected, as the number of messages and tokens typically increases with the involvement of more devices.

Second, the costs imposed by the M2O hybrid protocols are higher than those of IoT group authentication solutions. This is because our protocols use multi-factor authentication, whereas other solutions use single-factor authentication, and the former approach incurs higher communication and computation overheads. Although these costs can be justified when a high level of protection is needed, they have been reduced significantly in the symmetric-key-based version of the M2O protocols.

Finally, to provide a fair performance comparison, the M2O protocols should be compared to a benchmark solution that supports multi-factor authentication between devices. To address this issue, the next section evaluates the communication and computation costs experimentally and then compares them to those of Kerberos [34] to assess their performance.

7. Experimental Evaluation

7.1. Cryptographic Algorithms

In our protocols, the following algorithms are used:

• The AES-CBC-128 algorithm is used for symmetric encryption and decryption.
• The RSA-3072 algorithm is used for asymmetric encryption and decryption.
• The SHA-256 algorithm is utilized to compute hash values.
• The HMAC-SHA256 algorithm is used to generate HMAC values.

In Kerberos, the AES-CTS-128 algorithm is employed to handle symmetric encryption and decryption tasks.

7.2. Experimental Setup and Iteration Count

The experiments were carried out using a one-machine setup with a laptop running Windows 10 (64-bit), equipped with an Intel Core i5-8265U processor and 12 GB of RAM. To reduce variations and maintain statistical significance, the results were collected when the number of iterations was 7000. The reliability of the results was assessed using the Standard Error of the Mean (SEM), which is computed by dividing the sample’s standard deviation by the square root of the iteration count [78]. The SEM value of the experimental results is 0.007.

7.3. Experiment Results

Table 13. Computational costs of cryptographic operations.

Cryptographic Operation	Average Execution Time (Milliseconds)
SHA256	0.0096
HMAC- SHA256	0.0300
AES-CBC-128 encryption	0.0181
AES-CBC-128 decryption	0.0184
AES-CTS-128 encryption	0.055
AES-CTS-128 decryption	0.080
RSA-3072 encryption	2.096
RSA-3072 decryption	16.459

illustrates the average time to execute cryptographic operations.

Figure 14 shows the PCC costs of the two M2O hybrid protocols, the HGAKA protocol and the HGA protocol, with different numbers of client devices. The figure indicates that the cost associated with the HGAKA protocol rises modestly, in contrast to the HGA protocol, which demonstrates a steady increase as the device count rises. For instance, increasing the number of client devices from 5 to 400 results in a PCC cost increase for the HGAKA protocol, from 3 ms to 41 ms. In contrast, the HGA protocol shows a much steeper rise, going from 29 ms to 871 ms, which is approximately 22 times higher. This is due to how the group tokens are constructed in the two protocols. In the HGAKA protocol, the group token employs a symmetric-key cipher, whereas the HGA protocol uses an asymmetric-key cipher, which is significantly more computationally expensive.

Figure 15 presents the PCC costs of the two M2O symmetric-key-based protocols, SGAKA and SGA. As the number of devices increases, the SGAKA protocol demonstrates a steady cost increase, while the SGA protocol shows only a slight rise at a significantly reduced pace. For instance, as the device count increases from 5 to 400, the PCC cost of the SGAKA protocol rises from 0.6 ms to 39 ms, whereas the corresponding cost for the SGA protocol increases from 0.3 ms to 15 ms, which is approximately $60\%$ lower. This difference stems from the number of tokens each protocol uses; SGAKA uses more tokens, while SGA employs a secret-sharing scheme to reduce token count and establish a session key, resulting in lower computational overhead.

Figure 16 presents a comparative evaluation of the PCC costs associated with the HGAKA and SGAKA protocols. The results indicate that both protocols exhibit a similar upward trend in cost as the number of client devices increases. This behavior is primarily due to their reliance on comparable group authentication mechanisms for establishing trust with the authentication server. However, the SGAKA protocol demonstrates improved cost efficiency, as its rate of cost increase remains lower than that of the HGAKA protocol. Notably, the additional overhead in HGAKA is largely independent of the number of client devices, further highlighting SGAKA’s scalability. Overall, SGAKA achieves a cost reduction ranging from 5∼77% relative to HGAKA. Specifically, when the number of client devices is less than 11, SGAKA reduces the PCC cost by approximately 65∼77%, whereas for cases involving more than 99 devices, the reduction ranges from 5∼18%. This difference arises from the token generation mechanisms employed by the two protocols. In HGAKA, token construction relies on either symmetric or asymmetric cryptographic techniques, with the latter introducing considerable computational overhead. In contrast, SGAKA exclusively utilizes symmetric-key cryptography, resulting in a more efficient token generation process.

Figure 17 presents the PCC cost trends for the HGA and SGA protocols. As shown, the cost associated with HGA increases consistently as the device count increases, while SGA incurs only a marginal rise, remaining comparatively stable. The SGA protocol proves to be significantly more cost-effective, offering a reduction in overhead ranging from 98∼99% relative to HGA. This substantial difference stems from both the fewer tokens required and the specific method used for their construction, as previously outlined.

The M2O protocols based on symmetric-key cryptography, specifically SGAKA and SGA, are significantly more cost-efficient than their hybrid counterparts, HGAKA and HGA. These symmetric-key protocols reduce overall PCC costs by approximately 94∼97% when compared to the hybrid M2O protocols.

8. The M2O Protocols Versus a Benchmark Solution

As previously mentioned, numerous solutions have been proposed to secure authentication between devices in IoT applications, including those examined in this paper as well as in prior research efforts (e.g., [33,79,80]). However, these solutions predominantly rely on single-factor authentication, and therefore generally incur lower communication and computational overhead compared to multi-factor approaches, such as the protocols proposed in this paper. Existing multi-factor authentication schemes are typically designed for user authentication rather than for software-to-software or device-to-device scenarios. To ensure a fair performance comparison, the benchmark used must also support multi-factor authentication. Kerberos is a widely recognized and extensively adopted authentication protocol that can be configured to enable multi-factor authentication between devices [34]. For this reason, it was selected as the benchmark to evaluate the efficiency of the proposed protocols.

8.1. Kerberos

Kerberos is a popular authentication solution that uses two symmetric-key-based tickets (a ticket-granting ticket and a service ticket) to authenticate a client to a service provider (e.g., a target device). In [34], we analyzed the communication and computation costs of Kerberos version 5 using the same performance evaluation assumptions presented in Section 4.1. Next, we compare these costs with those of the M2O protocols.

8.2. Communication Costs

The total communication costs of the M2O hybrid protocols (i.e., the HGAKA and the HGA protocol) and Kerberos are presented in

Table 14. M2O hybrid protocols versus Kerberos communication costs.

Authentication Type	Two-Factor
Protocol	M2O Hybrid		Kerberos
	HGAKA	HGA
Communication cost (bits)	$256(3NC-2)+$ $128\left[\right(32\times NC)+192]+$ $128\left[2544\right[128\times NC\left]\right]+$ 1536	$3056(NC-1)+$ $2544\times NC+$ $128\left[\right(32\times NC)+192]+$ $128\left[2544\right[128\times NC\left]\right]+512$	$6080\times NC$

. Figure 18 shows the cost of the M2O hybrid protocols increasing steadily, whereas the cost of Kerberos increases at a lower rate, with the number of devices. The M2O hybrid protocols increase the communication cost by $10\%\sim 19\%$ in comparison with that of Kerberos. This is due to the way by which the tokens used in the protocols are constructed. In the M2O hybrid protocols, the tokens are constructed based on a symmetric-key and/or asymmetric-key cipher, whereas the tokens in Kerberos are based only on a symmetric-key cipher, and the former is much more computationally expensive.

The total communication costs of the M2O symmetric-key-based protocols (i.e., the SGAKA protocol and the SGA protocol) and Kerberos are presented in

Table 15. M2O symmetric-key-based protocols versus Kerberos communication costs.

Authentication Type	Two-Factor
Protocol	M2O Symmetric-Key-Based		Kerberos
	SGAKA	SGA
Communication cost (bits)	$256\times (3NC-1)+$ $128\left[\right(32\times NC)+192]+$ $128\left[\right(128\times NC)+128]+$ 768	$512\times (NC-1)+$ $128\left[\right(32\times NC)+192]+$ $128\left[\right(128\times NC\left)\right]+512$	$6080\times NC$

. Figure 19 shows the communication costs of the protocols. From the figure, it can be seen that the total cost of the M2O symmetric-key-based protocols increases slightly, whereas the cost of the Kerberos increases steadily, at a much higher rate, with the increase in the number of devices. The M2O symmetric-key-based protocols reduce the communication cost by $70\%\sim 74\%$ in comparison with that of Kerberos. This is because the number of messages exchanged in the M2O symmetric-key-based protocols is lower than that of Kerberos when two or more client devices are involved.

8.3. Computation Costs

The PCC costs of the M2O hybrid protocols and Kerberos are presented in

Table 16. M2O hybrid protocols versus Kerberos PCC costs.

Authentication Type	Two-Factor
Protocol	M2O Hybrid		Kerberos
	HGAKA	HGA
Cryptographic operations	$8T_{SE}+T_{AE}+$ $2NC(T_{SE}+T_{HMAC})+$ $T_H$	$(4+2NC)T_{SE}+$ $(1+NC)T_{AE}+$ $T_{AD}+T_H$	$(2T_{KSE}+T_{KSD}+$ $2(5T_{KSE}+6T_{KSD}))\times$ $NC$
PCC cost (ms)	$0.096\times NC$ + $2.248$	$2.131\times NC$ + $18.636$	$1.7\times NC$

. Similar to the communication costs, Figure 20 illustrates that the PCC cost of the M2O hybrid protocols increases at a higher rate than that of Kerberos as the device count rises. For instance, when the device count exceeds 99, the PCC cost associated with the M2O hybrid protocols is approximately 34∼43% higher compared to Kerberos. This difference is attributed to the same factors discussed in Section 8.2.

The PCC costs of the M2O symmetric-key-based protocols and Kerberos are shown in

Table 17. M2O symmetric-key-based protocols versus Kerberos PCC costs.

Authentication Type	Two-Factor
Protocol	M2O Symmetric-Key-Based		Kerberos
	SGAKA	SGA
Cryptographic operations	$(8+2NC)T_{SE}+$ $2NC\times T_{HMAC}$	$(6+2NC)T_{SE}$	$(2T_{KSE}+T_{KSD}+$ $2(5T_{KSE}+6T_{KSD}))\times NC$
PCC cost (ms)	$0.096\times NC$ + $0.144$	$0.036\times NC$ + $0.108$	$1.7\times NC$

. Figure 21 presents the PCC costs of the protocols. Similar to the communication costs of the protocols, the rate of increase in the PCC cost of the M2O symmetric-key-based protocols is significantly lower than that of Kerberos. The M2O symmetric-key-based protocols reduce the PCC cost by 89∼92% in comparison with Kerberos. The difference between the protocols can be attributed to two reasons. The first is that the number of messages exchanged in the M2O symmetric-key-based protocols is lower than that of Kerberos as discussed earlier. The second reason is that our protocols use a number of cost-cutting measures (e.g., a secret-sharing scheme in the SGA protocol) to reduce their computation costs.

9. Conclusions and Future Work

As group access and interaction scenarios often involve a larger number of entities compared to traditional one-to-one interactions (e.g., device-to-device), they may pose greater security risks. Therefore, stronger authentication mechanisms with higher assurance levels are required to ensure adequate protection in such environments. This paper proposed four multi-factor authentication protocols, HGAKA, HGA, SGAKA, and SGA, all specifically designed for IoT group communication scenarios, particularly in multidevice-to-device interaction modes. Security analyses demonstrated that all the protocols satisfy the security requirements and are resilient against attacks.

From a performance perspective, while the homomorphic encryption property helps reduce the computational overhead introduced by the RSA algorithm, the M2O hybrid protocols still incur higher costs compared to the Kerberos protocol. Additionally, the availability of homomorphic encryption capabilities may vary depending on the implementation of RSA. In contrast, the M2O symmetric-key-based protocols offer substantial performance improvements, reducing communication costs by approximately 70∼74% and computational costs by 89∼92% compared with Kerberos.

Future work can focus on extending the M2I framework to incorporate additional Homomorphic Encryption schemes and lightweight cryptographic algorithms newly approved by the National Institute of Standards and Technology (NIST) [81]. These enhancements can further improve flexibility and scalability, enabling more robust and efficient multi-factor authentication for diverse IoT group communication environments.