**1. Introduction**

The Internet of things (IoT) means an environment or technology in which heterogeneous devices are connected to the Internet. The devices participating in the IoT environment can be connected to the Internet to provide various services to users. Thus, the services provided to users through such environments and technologies can also be called IoT. Servers process data collected by "things" (end devices), such as sensors and actuators, and users are provided with services through their smartphones. The most common IoT service structures are things and gateways, storage or servers, and consumers. It consists of things that collect data or perform commands, a gateway that is an intermediate that transmits data collected from things, a storage or server that stores and analyzes data in the form of data desired by users, and consumers who use it. Recently, with the advent of an IoT-based hyper-connected society, technological innovation is ongoing in various fields. In particular,

as the fifth-genereation (5G) telecommunications standard has recently attracted attention, the number of IoT devices connected to the Internet will increase rapidly, and various services can be provided [1–4].

With the development of communication technology, weight reduction and mass production of devices became possible. Since then, following smart homes, more devices are evolving into large-scale IoT services, such as smart buildings, factories, and cities that connect to the Internet. Objects participating in the IoT service environment are each connected to the Internet to communicate with other objects. The feature of the IoT environment is that all devices need to be connected to the Internet, so small devices, such as electrical outlets and gas valves in smart homes, need to include communication capabilities. Therefore, it is composed of ultra-light and low-power technologies, unlike the existing environment. It is also difficult to apply existing public key infrastructure (PKI) security technologies to IoT devices, so it is necessary to use lightweight cryptographic algorithms that work well in this new environment of ultra-light and low-power devices [5,6].

In particular, a technology for providing integrity for messages in an IoT environment is essential [7,8]. Figure 1 shows a scenario for the data signing and verification process in an IoT environment. Sensors create a message, create a signature, and place them in cloud-like storage through a gateway. Thereafter, the consumer (i.e., the verifier) who needs the message can secure the integrity of that message through the message and the signature. Since the IoT environment is composed of a wireless communication network, it is possible to provide a secure service only by providing integrity for commands sent by a user to a device or for data collected from a device. Of course, since the IoT is a lightweight environment, the signature must also be lightweight to be applied to that IoT environment. Therefore, in this paper, we analyze the certificateless (CL) signature (CLS) and CL aggregate signature (CL-AS), a signature scheme using the lightweight CL public key cryptography (PKC, hence CL-PKC), which is suitable for IoT environments. In addition, we propose a CL aggregate arbitrated signature (AAS, hence CL-AAS) that applies the gateway arbitrated signature technique to enhance its non-repudiation and the aggregate signature technique to enhance its efficiency. In particular, it is designed to be safe against the forgery of signatures, including against public key replacement attacks that occur in CL-PKC-based cryptographic technologies, and to be suitable for IoT environments by avoiding the use of a large number of computational pairing operations.

**Figure 1.** Data signing and verification scenario in an Internet of things (IoT) environment.

The contributions to the proposed scheme in this paper are as follows.


More details on CL-PKC and security threats are covered in Section 2 on related work. Section 3 introduces the security requirements for each item in the cryptosystem, and Section 4 introduces the proposed scheme that satisfies those security requirements. Section 5 gives a comparative analysis of the proposed scheme, with Section 6 giving the paper's conclusions.

#### **2. Background and Related Work**

In this section, we consider background and related work, before suggesting the CL-PKC-based CL-AAS scheme to satisfy security requirements and provide efficiency in an IoT environment. Even before wireless sensor networks had become common, research had been conducted on digital signatures to provide message integrity. Some cryptography schemes have been used recently in IoT environments, such as the CLS and CL-AS used in the signature process proposed in this paper; we now examine these, including their security threats.

#### *2.1. Elliptic Curve Cryptography and ECDLP*

The elliptic curve cryptography (ECC) is a public key cryptography based on the elliptic curve theory, and provides a similar level of security while using a shorter key than the existing public key cryptography. Therefore, it is applied to various cryptographic algorithms used in IoT environments. The definition of the elliptic curve cipher is as follows.

Let *Fq* denote a finite field with a large prime order *q*. Let *Eq* denote an elliptic curve on *Fq*, which is specified by the equation: *<sup>y</sup>*<sup>2</sup> <sup>=</sup> *<sup>x</sup>*<sup>3</sup> <sup>+</sup> *ax* <sup>+</sup> *<sup>b</sup>*(*mod p*), where *<sup>a</sup>*, *<sup>b</sup>* <sup>∈</sup> *Fq* and - 4*a*<sup>3</sup> + 27*b*<sup>2</sup> *mod p* - 0 . Let the notation *O* denote a point of infinity, form the additive cyclic group *G* of the elliptic curve under the computation of point addition *T* = *U* + *V* for *U*, *V* ∈ *G* defined on the basis of a chord-and-tangent rule. Suppose *P* is a generator of the cyclic group *G*, and the order of *G* is *q*. Let *x* ∈ *Z*<sup>∗</sup> *<sup>q</sup>*, and scalar multiplication is defined by the equation: *x* × *P* = (*P* + *P* + ... + *P*) (*x* times).

The ECC was designed based on the elliptic curve discrete logarithm problem (ECDLP). Given two random points *P*, *Q* ∈ *G*, the ECDLP is to find the integer *x* ∈ *Z*<sup>∗</sup> *<sup>q</sup>*, where *Q* = *x* × *P*.

#### *2.2. Digital Signature*

Digital signature is a security technology in which a signature has been changed into a digital form; it serves as proof of the identity of a digital electronic document's author. Digital signature is a cryptographic technology created by PKI-based public key cryptography (PKC) technology, starting with the authentication of messages [9–11]. Authentication can be divided into that of the user and that of the message. The former confirms the identity of a valid user and is a basic element for ensuring the responsibility of users. The latter may, for instance, provide assurance that the received message has not been tampered with. Digital signature consists of a signature using a private key, a verification using a public key, and provides a non-repudiation function, to ensure that it was sent from the sender. For digital signatures, the following five items must be satisfied:


Digital signatures began with PKC and various other types have been developed, including blind, arbitrated, group, multi-, and one-time signatures, and a variety of AS schemes that aggregate multiple signatures into one [9,11–18].

#### *2.3. Certificateless PKC (CL-PKC)*

There is a problem with PKC in that it is difficult to apply in an environment requiring ultra-light and low-power devices, such as the IoT. In particular, PKI, upon which PKC is based, uses a certificate, to verify the public key for authentication of the user, and the user's public key. For this reason, the computational overhead is exceptionally large for managing keys, signatures, and certificates and their distribution, verification, and revocation.

To solve these problems of PKC, identity-based cryptography (IBC) was developed [19]. Since IBC uses a public key based on a known user's identifier, it can solve the problems of key distribution, certificate verification, and memory overhead by eliminating the public key verification process. However, identity-based encryption has a problem with key escrow [20,21]. In IBC, there is a key generation center (KGC) that receives a user's identifier to generate a private key based on it and returns this to the user. The direct generation of the user's private key in this way can expose the user's key to the KGC afterwards: The key escrow problem.

One proposed scheme to solve the key escrow problem in IBC is CL-PKC [22], in which the KGC does not generate all public and private keys but only partially generates them and returns them to the user. This "partial" key is called a partial secret key (PSK), and the user creates his or her full key pair using this. Since the full key pair is not generated by the KGC but by the user, CL-PKC can solve the key escrow problem, uses a smaller key than the existing PKI, and does not incur the overhead for public key verification; it is thus suitable for ultra-light and low-power environments. Research has been conducted on various aspects of CL-PKC, such as authentication and key agreement [23,24], signatures [25,26], and encryption [27,28]. The main difference between the structures of CL-PKC and its predecessor, PKC, is that there is no certificate for public key verification in the former and, in this sense, the term "certificateless" is used.

#### *2.4. Certificateless Aggregate Signature (CL-AS)*

Before explaining CL-AS, we describe CLS, which is the basis for it. CLS is a signature technique using CL-PKC: The signature for a message is generated using the private key of the signer, generated via CL-PKC, and the verifier verifies it using the public key and identifier of the signer and the public key of the KGC. CLS and CL-PKC are currently active research topics [22,25,26].

CLS is a scheme for signing a single message, whereas CL-AS is a scheme for creating an aggregated signature for multiple messages. If there are multiple senders, the signature on the generated messages will generate the signature of each sender. That is, N signatures are generated for N messages generated by N senders. The verifier must perform verification of N messages individually, using N public keys of N senders. Thus, the number of individual verifications will, likewise, be N. CL-AS aggregates these N signatures into one signature. N public keys are used for verification, but the advantage of being able to verify all of the signatures for N messages in one step is that only one verification process is required. This can reduce the computational overhead on the verifier side and, on the storage side (messages and signatures must be stored), only one signature, not N of them, needs to be stored, thereby reducing memory overhead. The CL-AS scheme was proposed based on a pairing operation, but, recently, pairing-free schemes to reduce the number of operations have been proposed [29–34]. Figure 2 shows the structure of CL-AS.

The basic CL-AS schemes include a CL-PKC-based signature that receives a PSK after registering a user with a KGC. In general, the CL-based AS technique consists of the following eight steps. Among them, the setup and partial-private-key-extract steps are performed by the KGC, and the set-secret-value and set-public-key steps are performed by the user who generates the key. Thereafter, the signer who wants to generate the signature does so for the message with his key through the CL-sign step and can verify the message and signature through the CL-verify step. Signatures generated from multiple signers are sent to the aggregator through the CL-aggregate step, which aggregates them into one signature, and then on to the verifier. The verifier can acquire and verify messages through the CL-aggregate-verify step.

• Setup: The KGC generates public parameters and a master secret key using a security parameter as input.


**Figure 2.** Structure of the general certificateless aggregate signature process. KGC: key generation center.

#### *2.5. Security Threat of CL-AS*

CL-AS has several advantages, but it also has problems with the forgery of messages and signatures. The public key used in CL-PKC does not use a certificate, so the user's identifier and public key cannot be authenticated. Because of this, CLS has a weaker non-repudiation function than PKI, and a malicious attacker can conduct an attack in which another user's public key is replaced. This CLS public key replacement attack is a method of forging the signature transmitted by device A to device B and replacing the public key of user A with a public key generated by the attacker to verify that forged signature. This is an attack that occurs because it is not possible to authenticate whether the public key, which can bypass the verification of the signature generated using A's private key, is that of A or that of the attacker. It can be verified that the signature using the public key of device A, but the function of non-repudiation to verify the signature is actually signed by A is weak. The act of being able to verify by replacing the public key itself is an infringement of non-repudiation, and in order to prevent this, CL-PKC must be considered for a public key replacement attack. Additionally, unlike IBC, there is no problem of key escrow for the device's secret key; however another problem may also occur: The KGC can generate the partial key of A and forge user A's signature using a partial key generated by itself.

Therefore, the security model for CL-AS can be roughly divided into two types of attack model [29–34]. Each model is of a game by an attacker (*AI* or *AII*) communicating with a challenger to successfully forge a signature. *AI* has the ability to arbitrarily replace the public key of a legitimate user without the system's master key. *AII* cannot replace the public key of users but knows the master secret key of the KGC. Thus, each of them can perform different types of attacks.

#### *2.6. Analysis of Existing CL-AS Schemes*

CLS was first proposed by Al-Riyami et al. in 2003 [21]. Based on this, the recently proposed CL-AS has had many implementations published that are more efficient because they do not use pairing operations. Table 1 summarizes some of these variants and their security threats.

Qu et al. [29] proposed an efficient CL-AS scheme that does not use a pairing operation. Most commonly, CL-AS structures are based on the elliptic curve discrete logarithm problem (ECDLP). This scheme is one such and adds the user-generated key and PSK to the signature. However, since the identifier is not bound to the public key, there is a risk that the public key can be replaced.

Deng el al. [30] proposed a CL-AS scheme that prevents forgery of signatures by adding two kinds of signatures in one signature statement, by adding an RSA signature along with an ECDLP-based Schnorr signature. However, the size of the signature statement for the message is exceptionally large, and the signature verification overhead is disadvantageous because two types of signatures must be verified. In particular, the former signature is based on an exponential operation, unlike the latter signature, which uses an elliptic curve, so it has a large overhead compared to other schemes.

Cui et al. [31] proposed a scheme to prevent the transmission of a forged signature due to the replacement of the public key by adding a timestamp when sending the signature and message. However, since the identifier is not actually bound to the public key, it does not provide direct defense against a public key replacement attack.

Du et al. [32] proposed a scheme that was safe against public key replacement attacks by binding an identifier and a verification key to a public key, but there is a risk of key leakage and subsequent signature forgery.

Gayathri et al. [33] proposed a scheme to aggregate public parameters for signature verification. Previous schemes required N public parameters to verify N signatures, but Gayathri et al. could reduce the memory overhead by using a scheme that reduces the verification parameters. However, there is a risk of a public key replacement attack because the identifier is not bound to the public key.

Zhao et al. [34] proposed a scheme to prevent signature forgery by adding a value for verifying the signature directly to the overall transmitted value of the message and the aggregated signature. However, the message that is transmitted is exceptionally large, and there is still a risk of a public key replacement attack.

The above schemes suggest CL-AS for various environments. The security analysis and efficiency comparison of existing schemes are summarized in Sections 5 and 6. In general, the risk of public key replacement attack occurs when the user, identifier, and verifiable value are not bound to the PSK received via the KGC. In other words, the signature can be verified with the public key of the device A, but it occurs when the public key used to verify the signature cannot verify whether the public key generated by the object with the actual identifier A is correct. This means that the existing problem is related to non-repudiation, and this problem can be solved if the public key can verify the identity of the identifier A. To solve this, in recent CL-PKC schemes, the partial key is received from the KGC first, and the user does not generate the full key but, instead, first generates the verification key pair and sends the identifier and public key for verification to the KGC. Using this, the KGC binds the user's identifier, the public key, for verification, and the verification tag to the PSK, and then enables verification of the user's public key [35,36]. Additionally, in the existing CL-AS schemes, the aggregator that aggregates the signatures of the signer's messages serves solely to aggregate these signatures. The aggregator can be one of the signers or a third entity, depending on the environment. If it is a third entity, the problem of trusting it may occur, which can make the AS unreliable. Therefore, it is necessary that the aggregator in CL-AS has non-repudiation.

#### **3. Security Requirements**

• Integrity: The most important requirement for digital signatures, including CLSs, is integrity. In particular, in the IoT environment, since data are transmitted and received using a wireless communication network, it is particularly important to ensure integrity by signing important

messages. In the existing CL-AS schemes, since the aggregator only aggregates the signature, the entity that verifies the signer's signature first is that aggregator. The integrity of the aggregate signature itself must be ensured, as it can also be an attack point.


#### **4. Proposed Scheme**

In this paper, we propose CL-AAS, a scheme with an aggregated and arbitrated signature, for IoT environments. Figure 3 shows the proposed scenario. In the IoT environment, sensor devices act as signers to generate messages and directly generate signatures. Sensor devices gather to form a sensor cluster, and each cluster has a gateway. A message is generated from the sensor device, and each device signs the message through the private key generated by CL-PKC and sends it to the gateway, which simultaneously acts as an arbitrator and an aggregator.

As a feature of the proposed scheme, it is possible to strengthen the non-repudiation of the signature of the sensor device through the arbitrated signature of the gateway, and reduce both the size of the signature stored in storage and the verification overhead of the verifier through the AS. In the existing CLS scheme [37,38], an entity, such as an external time server or "helper", synchronizes with the signer to strengthen non-repudiation for the signature. In the IoT scenario proposed in this paper, the messages generated by the sensor device are aggregated and transmitted through the gateway, so we do not use other external entities but try to strengthen the non-repudiation by using the gateway itself. In other words, the gateway does not merely act as an aggregator for combining multiple signatures into a single one but also makes it an arbitrated signature.

The system parameters of the proposed scheme are as follows.


• *<sup>H</sup>*3(·): Cryptographic hash function - {0, 1} <sup>∗</sup> × {0, 1} <sup>∗</sup> × *Z*<sup>∗</sup> *<sup>q</sup>* × *G* × *G* → *Z*<sup>∗</sup> *q* .

The proposed CL-AAS scheme consists of four phases: Setup, individual signing and verifying, aggregated arbitrated signing, and aggregated verifying. In the setup phase, the KGC sets the public parameters and distributes the participants' partial keys. In the individual signing and verifying phase, the participants (such as devices) use their partial keys to generate individual signatures and the aggregator verifies them. In the aggregated arbitrated signing phase, the messages and signatures of all the signer devices are turned into one signature and the gateway adds its arbitrated signature.

**Figure 3.** Scenario and advantages of the proposed scheme. KGC: key generation center.

Finally, in the aggregate verify phase, the signatures of the devices and the signature of the gateway's arbitrated signature are verified at once.

Each phase of the proposed scheme is modified from the eight algorithms described in Section 2.3. The set-secret-value and set-public-key algorithms are replaced with set-device-key and set-full-key ones, respectively. This is because the verification key pair of the user is generated first, not the partial key. Additionally, the AS (aggregated signature) and verification algorithms are replaced by CL-AA-sign to generate the AAS (aggregate arbitrated signature) and CL-AA-verify for aggregate verification. Therefore, this proposed scheme consists of the following eight algorithms for the KGC; A; gateway, G, acting as an aggregator and arbitrator; and verifier, V:


Figure 4 shows the four phases and eight algorithms of the proposed scheme.

**Figure 4.** The relationship between the phases and algorithms of the proposed scheme. CL: certificateless, AA: aggregate arbitrated.

#### *4.1. Setup Phase*

In the setup phase, KGC first performs the setup algorithm using *k* (the security parameter) to generate the initial parameters, *msk* (the master secret key), and a master public key, *PPub*. The KGC is responsible for generating the partial keys of the devices after generating *params* (the public parameters). Subsequently, a verification key pair for each device is generated through the set-device-key algorithm; then, a partial key is generated for each by performing the partial-private-key-extract algorithm by sending information to the KGC. A device that receives a PSK generates its own full key pair through the set-full-key algorithm. Figure 5 shows the sequence diagram of the setup phase.

**Figure 5.** Sequence diagram of setup phase.

Step 1. The KGC selects k and generates *msk*. After that, *Ppub* = *msk* × *P* and params are generated as follows, through the setup(k) algorithm:

$$params = \{G, q, E, P, P\_{pub}, H\_1, H\_2, H\_3\}.\tag{1}$$

Step 2. A, which needs to receive a partial key from KGC, first creates its own verification public and private key pair, *puA*,*svA*, through the set-device-key (*params, ID*) algorithm. A selects *xA* ∈*<sup>R</sup> Z*<sup>∗</sup> *q* and computes *puA*,*svA* as follows:

$$
\mu u\_A = \mathbf{x}\_A \times \mathbf{P}, \\
\text{sv}\_A = \mathbf{x}\_A. \tag{2}
$$

Step 3. A sends *IDA* and *puA* (its verification public key) to the KGC, which performs the partial-private-key-extract (*params*, *msk*, *IDA*, *puA*) algorithm to generate *DA* (the partial key). The KGC selects *rA* ∈*<sup>R</sup> Z*<sup>∗</sup> *<sup>q</sup>* and calculates the result of Equation (3). Then, the result of Equation (4) is calculated to generate a signature for the public key. The KGC transmits *DA* = (*RA*, *zA*) to A over a secure channel:

$$R\_A = r\_A \times P\_\prime \tag{3}$$

$$z\_A = r\_A + msk \times H\_1(ID\_{A\prime}pu\_{A\prime}R\_A). \tag{4}$$

Step 4. A, which has received *DA*, creates *PRA* (its full private key) and *PUA* (its full public key) through set-full-key (*params*, *IDA*, *DA*, *puA*,*svA*) as follows:

$$Z\_A = z\_A \times P\_\prime \tag{5}$$

$$PR\_A = s\upsilon\_A + z\_{A\prime}\ PIL\_A = (p u\_A, R\_A, Z\_A). \tag{6}$$

#### *4.2. Individual Signing and Verifying Phase*

The individual signing and verifying phase use the CL-sign and CL-verify algorithms. A, which needs to generate a signature, becomes a signer and signs a message using its own key. Figure 6 shows the sequence diagram of the individual signing and verifying phase.

**Figure 6.** Sequence diagram of individual signing and verifying phase.

Step 1. A selects an ephemeral secret key, *tA* ∈*<sup>R</sup> Z*<sup>∗</sup> *<sup>q</sup>*, and calculates an ephemeral public key, *TA* = *tA* × *P*.

Step 2. A needs to send a signed message to the arbitrator, G, to send the message and signature to V, to communicate. A calculates *hA* and τ*<sup>A</sup>* as follows, to generate the signature for *mA* (the message):

$$h\_A = H\_2(m\_{A\prime}ID\_{A\prime}T\_{A\prime}pu\_A),\tag{7}$$

$$
\pi\_A = t\_A + h\_A \times PR\_A.\tag{8}
$$

Step 3. A sends *mA*, σ*<sup>A</sup>* = (τ*A*, *TA*) (the signature for *mA*), and *IDA* to G.

Step 4. G receives σ*A*, *IDA*, and *mA* and performs the process of verifying σ*A*. G calculates *h <sup>A</sup>* as in Equation (9), using the information from the message and that has been published by A, and verifies the validity of τ*<sup>A</sup>* via Equation (10). If the validity of τ*<sup>A</sup>* is verified, G completes verification of the individual message and its signature for A. G performs the signature not only for A but also for the messages and signatures of the other devices that will form the aggregate of signatures, as in Equations (9) and (10):

$$h\_A' = H\_2(m\_{A\prime}ID\_{A\prime}T\_{A\prime}pu\_A),\tag{9}$$

$$
\pi\_A \times P = T\_A + h\_A' \times (p u\_A + Z\_A). \tag{10}
$$

The validity of the verified contents can be confirmed as follows:

$$\begin{aligned} \tau\_A \times P &= (t\_A + h\_A \times PR\_A) \times P \\ &= t\_A \times P + h\_A \times PR\_A \times P \\ &= T\_A + h\_A \times (pu\_A + Z\_A) .\end{aligned} \tag{11}$$

#### *4.3. Aggregated Arbitrated Signing Phase*

In the aggregated arbitrated signing phase, G aggregates signatures on messages and signatures received from N devices, and creates an arbitrated signature that has been verified, and adds it to the aggregated signature. An arbitrated signature is not simply a signature but is also the means of confirming that G has completed verification for the messages and signatures received from each included device; it is generated using G's own private key. Thus, an aggregated signature is generated, including the devices' signatures and the gateway-generated arbitrated signature. The aggregated arbitrated signing phase includes the CL-AA-sign algorithm. Figure 7 shows the sequence diagram of the aggregated arbitrated signing phase.

**Figure 7.** Sequence diagram of aggregated arbitrated signing phase.

Step 1. Each device sends the content of the message and signature created by itself (*mi*, *IDi*, and σ*i*, where these relate to the *i*th device) to G, for which G collected and verified each signature during the signing and verifying phase.

Step 2. G selects an ephemeral secret key, *tG* ∈*<sup>R</sup> Z*<sup>∗</sup> *<sup>q</sup>*, and generates an ephemeral public key, *TG* = *tG* × *P*, to generate the signature of the collected message, *m* = (*m*1, ... , *mN*).

Step 3. G calculates the following to perform aggregation on the actual signature, τ*i*, constituting the signature, σ*i*, and the verification value, *Ti*:

$$
\pi = \left(\sum\_{t=1}^{N} \tau\_t\right) T = \left(\sum\_{t=1}^{N} T\_t\right). \tag{12}
$$

Step 4. G calculates the results of Equations (13) and (14) using its private key, *PRG*, to generate the elements of the arbitrated signature to indicate that it has completed verification of each message. Then, the results of Equation (15) are calculated to generate τ*AS* and *TAS*:

$$\text{Ind}\_{\mathbb{G}} = H\_{\mathbb{G}}(\mathfrak{m}, ID\_{\mathbb{G}}, \mathfrak{r}, T, \mathfrak{p}\mathfrak{u}\_{\mathbb{G}}), \tag{13}$$

$$
\tau\_G = t\_G + h\_G \times PR\_{G\prime} \tag{14}
$$

$$
\pi\_{AS} = \pi + \pi\_{G\prime} T\_{AS} = T + T\_G. \tag{15}
$$

Step 5. Finally, G creates an AAS (aggregate arbitrated signature), σ*AS* = (τ*AS*, *TAS*), that aggregates the arbitrated signature of G and all the signatures of the devices.

Step 6. To verify σ*AS*, *m*,(*ID*1, ... , *IDN*, *IDG*), σ*AS*,(*PU*1, ... , *PUN*, *PUG*) must be used. *PUi* is the published public key of the *i*th device. Therefore, the gateway then sends *m*,(*ID*1, ... , *IDN*, *IDG*), σ*AS* to V (the verifier requesting the message).

#### *4.4. Aggregated Verifying Phase*

In the aggregated verifying phase, V verifies the signature and message received from G, and verifies the signer's signature and G's arbitrated signature together. During this process, the initial signer and the arbitrator are verified simultaneously, strengthening the non-repudiation function. This involves the final algorithm, CL-AA-verify, of the eight in this scheme. Figure 8 shows the sequence diagram of the aggregated verifying phase.

**Figure 8.** Sequence diagram of aggregated verifying phase.

Step 1. G can store the generated σ*AS* and the message in a repository or send it directly to V. V performing the verification receives *m*,(*ID*1, ... , *IDN*, *IDG*), σ*AS* from G and confirms the identifiers of the devices to obtain the public keys, *PUi* = (*pui*,*Ri*,*Zi*).

Step 2. V calculates the value *h <sup>G</sup>* for the arbitrated signature verification of G as follows:

$$h\_{\mathcal{G}}' = H\_3(m, ID\_{\mathcal{G}\prime}\tau, T, pu\_{\mathcal{G}}).\tag{16}$$

Step 3. V can verify the validity of σ*AS* by calculating the result of Equation (17). If valid, V has completed verification of the N signer devices and G's arbitrated signature in one step:

$$
\pi\_{AS} \times P = T\_{AS} + h\_G \times (p u\_G + Z\_G) + \sum\_{t=1}^{N} h\_t \times (p u\_t + Z\_t). \tag{17}
$$

The validity of the verified contents can be confirmed as follows:

$$\begin{split} \pi\_{AS} \times P &= \left( \pi\_1 \times P + \dots \pi\_N \times P + \pi\_G \times P \right) \\ &= \left( \mathfrak{h} + h\_1 \times PR\_1 \right) \times P + \dots + \left( h\_N + h\_N \times PR\_N \right) \times P + \left( h\_G + h\_G \times PR\_G \right) \times P \\ &= \left( T\_1 + h\_1 \times (pu\_1 + Z\_1) \right) + \dots + \left( T\_N + h\_N \times (pu\_N + Z\_N) \right) + \left( T\_G + h\_G \times (pu\_G + Z\_G) \right) \\ &= \left( T\_1 + \dots + T\_N + T\_G \right) + \left( h\_1 \times (pu\_1 + Z\_1) \right) + \dots + \left( h\_N \times (pu\_N + Z\_N) \right) + \left( h\_G \times (pu\_G + Z\_G) \right) \\ &= T\_{AS} + h\_G \times (pu\_G + Z\_G) + \sum\_{l=1}^N h\_l \times (pu\_l + Z\_l) . \end{split} \tag{18}$$

#### **5. Security Analysis**

This section describes how the proposed scheme satisfies the security requirements presented in Section 3, including the requirements regarding integrity, key leakage, and forgery.

#### *5.1. Integrity*

In CLS or CL-AS, an existing CL-PKC-based signature scheme, a Schnorr signature, is used. In the proposed scheme, the individual signature value, τ*<sup>A</sup>* in σ*A*, of A is in the same form as the Schnorr signature, and the tag for verifying this is *TA*. τ*<sup>A</sup>* is created using A's private key, *PRA*, and the tag's secret value (its ephemeral secret key), *tA*, and can be verified through *PUA*. Here, the value that is actually verified is the content of the hashed value, *hA*. The values hashed from *hA* are the message, *mA*; the identifier, *IDA*, of the device, A, that was the signer; the verification public key, *puA*; and the verification tag, *TA*. Eventually, *hA* is signed using *PRA* to provide the integrity of the message and can be verified using *puA* and the partial public key, *ZA*, which are elements of *PUA* for verification. Therefore, it indicates that the signature, σ*A*, was generated by A and was not forged in "the middle", between A and V.

In addition, the aggregated signature, σ*AS*, generated by the gateway, G, using the individual signatures is added to the τ*<sup>i</sup>* and *Ti* of the signers who generated the message, and to τ*<sup>G</sup>* and *TG*, the arbitrated signature values generated by G with the private key, *PRG*. G's signature takes the form of a Schnorr signature, just like for the messages generated by the other devices, and can be verified in the same way. However, there is one difference: The content of the arbitrated signature being verified, *hG*, is the message set, m, and the identifier, *IDG*, of G and the aggregated devices' signature elements, τ and T. G can ultimately provide the integrity by signing the signature set itself of messages received from devices via σ*AS*, and can be verified using the public key, *PUG*, of G. If the message of the device is forged, the verification of the individual signature or AAS will fail, and only the normal message can be verified.

#### *5.2. Prevention of Key Leakage*

The signing key (full private key) and verification key (full public key) used in the proposed scheme are CL-PKC-based key pairs generated by the KGC and the device itself. It is assumed that when a device is first issued a partial key by the KGC, this is transmitted through a secure channel. In addition, all other messages and signatures that are transmitted are transmitted through a public channel. In the individual signing and verifying phase, the message sent to the public channel is the entire message, *mA*, *IDA*, and σ*A*, and if they can derive the signing key, the attacker will succeed in leaking the key. In the aggregated arbitrated signing phase, the entire message transmitted to the public channel is *m*,(*ID*1, ... , *IDN*, *IDG*), and σ*AS*, and if σ*AS* can derive the signing key, the key can be successfully leaked.

First, σ*<sup>A</sup>* is composed of τ*<sup>A</sup>* = *tA* + *hA* × *PRA* and *TA* = *tA* × *P*. The public key, *PUA*, of A consists of *puA*, *RA*, and *ZA*, the values used in the verification of σ*<sup>A</sup>* are *puA* and *ZA*, and *RA* is used to verify the validity of the PSK, *zA*, generated by the KGC. Furthermore, it can be verified that the public key, *ZA*, was made by A and the KGC.

The signature is verified as in Equation (10) and, even if the attacker knows the public key and other published information, obtaining the signature key from the signature is the same as the difficulty of solving the ECDLP in (*puA* + *ZA*) = (*svA* + *zA*) × *P*. Therefore, it is difficult for an attacker to derive a public key using disclosed information. In particular, in the proposed method, since each value in the form of the signature key, (*svA* + *zA*), is used as a single value by adding them together, rather than independently using *svA* and *zA* as in many existing schemes, this helps against leaking keys: There are fewer threats. Similarly, in σ*AS*, calculating the private keys of each signature using τ*AS* and *TAS* is the same as solving the ECDLP problem, so it is difficult to leak or derive the signature key from the proposed scheme.

#### *5.3. Unforgeability*

As described in Section 3, the attack that can occur in a CL-PKC-based signature protocol is, in fact, an attack on unforgeability. A signature protocol is insecure if a tampered signature on any message can be verified (as if it were legitimate). Attacks on unforgeability can be divided into those by *AI* and those by *AII*.

### 5.3.1. Unforgeability from Adversary AI

The adversary *AI* has the ability to replace the public keys of other users with one generated by themselves. Due to the safety of the ECDLP, a private key corresponding to the public key of a user

cannot be generated, but validation can be bypassed by replacing the public key alone. The public key replacement attack is mainly possible in existing schemes because the partial key, *DA* = (*RA*, *zA*), generated by the KGC is not related to the public key of the device. In short, it is a CL scheme, and thus lacks a certificate that can authenticate the public key of the signing device. By using this, it is possible to bypass the verification process of the signature, so that the forged signature will be verified by the verifier as if it were proper.

To solve the public key replacement attack, since it is a CL-PKC-based protocol (i.e., without a certificate), the binding between the public key and the identifier must be strengthened. When verifying a public key or verifying a signature signed with a private key, it is only necessary to confirm whether the user has used a public key or a signature made with a key created using a partial key received from the KGC. In summary, the partial public key, *RA*, in the partial key, *DA*, received from device A from the KGC is a tag for verifying the PSK, *zA*, and if the public key, *ZA*, of A created using *zA* can be confirmed to belong to A, it can be said to be safe against key replacement attacks. In generating *zA*, the value hashed from Equation (4) to *H*<sup>1</sup> later serves to verify the public key. If the public key is replaced, it is said that it is safe against public key replacement attacks if the verification of the signature cannot be bypassed using the public key replaced thus. On the other hand, when A's public key, *PUA*, is replaced by the attacker's public key, *PU <sup>A</sup>*, the public key replacement attack is successful if the verifier successfully verifies the forged signature, σ *<sup>A</sup>*, for the message, *mA*.

In the proposed scheme, the form of the individual signature is σ*<sup>A</sup>* = (τ*A*, *TA*) and the message can be verified normally using the forged public key, *PU <sup>A</sup>* <sup>=</sup> - *pu A*,*R A*,*Z A* , associated with the identifier of *AI*. However, it should not be possible to generate the forged signature, σ *<sup>A</sup>* <sup>=</sup> - τ *<sup>A</sup>*, *T A* . The signature generation for *mA* is according to Equation (8) and, since *AI* cannot know *tA* and *PRA*, a valid τ*<sup>A</sup>* cannot be generated. The signature verification is according to Equation (10) and can be generated using Equation (9) and *PUA*. The published information is *TA*, *puA*, and *RA* and an attacker who wants to forge it can perform an attack by replacing the public key with *pu <sup>A</sup>*, *R <sup>A</sup>*, and *Z <sup>A</sup>*, and the attacker will try to bypass the verification of *hA* by generating the same value as *pu <sup>A</sup>* + *Z <sup>A</sup>* <sup>=</sup> *<sup>h</sup>*−<sup>1</sup> *<sup>A</sup>* × *P*. However, the verifier can confirm that the public key *Z <sup>A</sup>* has not been properly generated using *Z <sup>A</sup>* = *R <sup>A</sup>* + *H*1(*IDA*, *puA*,*RA*) × *Ppub*, which can be verified using the public key of the KGC. As for the σ*AS* = (τ*AS*, *TAS*), which is an AAS (aggregate arbitrated signature), it has the same form as the individual signature in Equation (14), so the verifier can correctly verify this even if *AI* replaces G's public key. Therefore, *AI* cannot forge the signature.
