Design Principles of Secure Certificateless Signature and Aggregate Signature Schemes for IoT Environments

Certificateless cryptography resolves the certificate management problem of public-key cryptography and the key-escrow problem of identity-based cryptography. An aggregate signature scheme which allows to aggregate <inline-formula> <tex-math notation="LaTeX">$k$ </tex-math></inline-formula> distinct signatures on <inline-formula> <tex-math notation="LaTeX">$k$ </tex-math></inline-formula> distinct messages of <inline-formula> <tex-math notation="LaTeX">$k$ </tex-math></inline-formula> distinct signers into a single signature reduces communication overhead and computational cost. Due to the suitability of certificateless signature (CLS) and certificateless aggregate signature (CLAS) schemes for IoT environments, similar CLS and CLAS schemes have been proposed for a long time and, despite their security proofs, they have been attacked and modified to prevent the attacks. Even now, similar design methods and similar attacks on the schemes are being repeated. In order to prevent the similar attacks on the schemes, it is necessary to analyze their causes and vulnerabilities. In this paper, we first show that recently proposed five CLS and CLAS schemes are insecure against universal forgery attacks, type I attacks, type II attacks or malicious-but-passive-KGC attacks. We discuss their security flaws, causes and countermeasures. We then present design principles to prevent various algebraic attacks including our attacks. The design principles will help in the construction of secure CLS and CLAS schemes against the previous attacks and potential attacks.


I. INTRODUCTION
To ensure integrity, authenticity and non-repudiation, several kinds of public-key cryptography have been proposed. Al-Riyami and Paterson [1] proposed certificateless public-key cryptography to resolve the certificate management problem of public-key cryptography [2] and the keyescrow problem of identity (ID)-based cryptography [3]. In certificateless public-key cryptography, a user private key is computed by combining a partial private key generated by Key Generate Center (KGC) with a user-chosen secret. Certificateless public-key cryptography does not require publickey certificates and ciphertext/signatures are transmitted with users' public keys. With these advantages, certificateless The associate editor coordinating the review of this manuscript and approving it for publication was Mehdi Sookhak . signature (CLS) schemes seem to be suitable for achieving authenticity and integrity of transmitted data in IoT environments [4], [5].
Since Al-Riyami and Paterson constructed the first certificateless scheme [1], there have been proposed many CLS schemes. Most of them turned out to be insecure against type I or type II attacks. In [6], Au et al. presented maliciousbut-passive KGC attacks on several CLS schemes, in which the KGC could control the system parameters dishonestly to forge users' valid signatures. Also, almost of the proposed CLS schemes are secure in the random oracle model. It is known that the schemes may not be secure [7], [8] when random oracles are instantiated with concrete hash functions in real applications. There are some attempts for constructing CLS scheme probably secure in the standard model by using the idea of Paterson-Schuldt's ID-based signature scheme [9]. However, the schemes turned out to be insecure against the malicious-but-passive-KGC attacks, the type I attacks or type II attacks.
An aggregate signature scheme allows to aggregate k distinct signatures on k distinct messages of k distinct signers into a single signature which reduces communication overhead and computational cost. In particular, the aggregation of multiple signatures is an indispensable technique to save channel bandwidth in IoT environments. Also, the verification of an aggregate signature of k signatures is more efficient than the verifications of k individual signatures. Since smart devices used in IoT environments are resource, energy and storage-constrained, and wireless, it is a challenging task to propose a compact aggregate signature scheme whose aggregate signature length is independent of the number of signers. Many provably secure certificateless aggregate signature (CLAS) schemes have been constructed [10], [11], [12], [13], [14], [15], [16], but most of them were broken or cryptanalyzed and then modified [17], [18], [19]. Recently, Deng et al. [20] and Tseng et al.'s scheme [21] proposed new efficient CLS and CLAS schemes provable secure in the standard model under the hardness assumptions of the mathematical problems.
Gentry [22] proposed a new concept of certificate-based cryptography (CBC) by combining the advantages of both public-key cryptography [2] and identity-based cryptography [3]. In the CBC scheme, a user computes a secret/public key pair and a Trust Authority (TA) issues the user's certificate of the identity-public key pair by signing on the pair. To decrypt/sign a ciphertext/message, the user utilizes the certificate signed by the TA in an implicit manner together with its secret key. This implicit use of certificate solve the certificate management problem in the public-key cryptography and the key-escrow problem in the identity-based cryptography. Recently, Verma et al. [23] proposed the first pairing-free compact certificate-based aggregate signature (CB-AS) scheme, CB-CAS, using a fixed state information. They showed that the scheme was secure against two types of adversaries under the intractability assumption of the mathematical problem.
Since Al-Riyami and Paterson's scheme, a number of CLS and CLAS schemes have been proposed, but most of them were broken or cryptanalyzed. Some of them look similar since the schemes have been reproduced with minor modifications of the existing ones. In this paper, we show that recently proposed four CLS and CLAS schemes [16], [20], [21], and one CB-signature [23] scheme are insecure against universal forgery attacks, type I attacks, type II attacks or malicious-but-passive-KGC attacks. We then present design principles for construction secure CLS and CLAS schemes to prevent various algebraic attacks including our attacks.
Organization. We review four CLS and CLAS schemes, and one CB-signature scheme in Section II. In Section III, we show that the five schemes are insecure against universal forgery attacks, type I attacks, type II attacks or maliciousbut-passive-KGC attacks. We provide design principles for construction secure CLS and CLAS schemes to prevent our attacks in Section IV. Section V concludes this paper.

A. CLS AND CLAS SCHEMES IN STANDARD MODEL
We review Deng et al.'s scheme [20] and Tseng et al.'s scheme [21] proven secure in the standard model.

Deng et al.'s CLAS Scheme
• Setup. To generate system parameters, the KGC performs the followings: -Choose two groups, G 1 and G 2 , with a prime order q > 2ν, and a bilinear map e : -Choose three generators P, Q, Y of G 1 and x ∈ R Z * q , calculate P pub = xP, and set msk = x as a master secret.
-Publish the public system parameters • PPK-Extract. For the generation of a partial-private key of ID i , the KGC performs the followings: -Pick r i ∈ R Z * q and calculate a partial private key, -Send D i to the user in a secure way.
• SV-Set. A user with ID i chooses a secret value t i ∈ R Z * q . • UPK-Set. A user with ID i calculates T i = t i P and sets PK i = (R i , T i ) as a public key.
• Sign. A user with ID i generates a signature of a message m i as: -Check the equality If the equality holds then accept it. VOLUME 10, 2022 • Aggregate. For a tuple (σ 1 , · · · , σ n ) on , an aggregator computes V = n i=1 V i and outputs σ = (V , U 1 , · · · , U n ) as an aggregate signature.
• Agg-Verify. For an aggregate signature σ of , a verifier performs the followings: -Calculate -Check the equality If the equality holds, accept σ . In 1991, Girault [24] introduced Trusted Third Party's three security levels: the stronger system security, the higher level of the KGC. Tseng et al. [21] designed a new CLS scheme based on bilinear parings achieving the level-3 security.

Tseng et al.'s CLS Scheme
• Setup. To generate system parameters, the KGC does the followings: -Choose two secure hash functions, H m : {0, 1} * → {0, 1} n m and H u : {0, 1} * → {0, 1} n u , for some n m , n u ∈ Z. The hash functions are utilized to get identities and messages of the fixed lengths.
-Select a cryptographic hash function H : m ) as the system parameters and g α 2 is a master secret. • Set-Secret Key. A user chooses x ∈ R Z * p and sets r ID = x as a secret key.
• Set-Public Key. A user with a secret key x computes (pk 1 , pk 2 ) = (g x , g x 1 ) as a public key. -Choose r u , r v ∈ R Z * p and calculate a partial private key d ID as , where U PK = v i∈Vv i and U ID = u i∈Uû i . -At last, the KGC transmits d ID to the user through a secure way.
• Set-Private Key. A full private key of ID is sk ID = (r ID , d ID ).
If the equalities hold then output Valid. Otherwise, output Invalid.

B. CLAS SCHEMES IN RANDOM ORACLE MODEL
Mei et al. [16] constructed a CLAS scheme for conditional privacy preservation in IoV.

Mei et al.'s CLAS Scheme
• Setup: The TRA and the KGC perform the followings: -The KGC selects two groups, G and G T , with order p, and a bilinear map e : The KGC chooses a generator P ∈ R G 1 and s ∈ R Z * p , calculates MPK = sP, and keeps s as a master secret.
-The TRA picks k ∈ R Z * p , calculates T pub = kP, and keeps k as a tracking secret key. -Publish the system parameters • Pseudonym-Gen: After a vehicle V i joins VANET, the TRA generates a set of m pseudonyms as: Then, V i sends (ID i , PID i,1 ) to the TRA in a secure manner, where ID i is V i 's real identity.
-After checking ID i , the TRA calculates where TP i is a valid period of the pseudonym and outputs a set of the vehicle pseudonyms • Partial-Key-Gen: The KGC calculates and outputs a set of the vehicle partial private keys • Vehicle-Key-Gen: A vehicle V i chooses a secret key vesk i = x i ∈ R Z * p and calculates a public key vepk i = x i P.
• Sign: After meeting a new RSU, a vehicle V i performs the followings: -For RSU's identity ID Rs , calculate I s = H 2 (0, ID Rs ), J s = H 2 (1, ID Rs ), sample a pseudo identity PSUID i,j from PSUID i and find the associated secret key psk i from psk i .
-Calculate E i = psk i + vesk i I s and stores E i in a tamperproof device. -To sign a message msg i , V i selects t i as the timestamp, chooses u i ∈ Z * p and calculates U i = u i P, Then V i outputs a signature on msg i ||t i , sig i = (U i , T i ) and sends and checks the equality If the equality holds, accept sig i .
• Aggregate: Given a set of signatures and returns an aggregate signature sig = (U , T ). At last, the RSU sends to a TMC.
• Aggregate-Verify: For an aggregate signature sig of the messages , the TMC does the followings: -Check the validity of t s for s = 1, · · · , n. If they are valid, compute -Check the equality If the equality holds, accept sig. • Setup: The TA does the followings: -Select a prime number p, a cyclic group G T with order p and a generator P ∈ R G T . -Choose s ∈ R Z * p , compute sP and set p k TA = sP and s k TA = s as the TA's public key and secret key, respectively.
-Choose secure hash functions and ∈ {0, 1} * as a random state information. -Finally, the TA publishes as the security parameters.
• UserKeyExtract: A user U i with an identity ID i extracts a secret/public key pair as -Choose s ID i ∈ R Z * p as a secret key and calculate p k ID i = s ID i P as a public key. • CertExtract: Through this interactive phase, a user receives a certificate from the TA.
-The user can verify the validity of the certificate by checking , an aggregator verifies the validity of all the signatures by checking For an aggregate signature (R, Z ), the end user verifies its validity by checking the following equality If the equality holds, accept the aggregate signature.

III. CRYPTANALYSIS OF FOUR CLS AND CLAS SCHEMES, AND ONE CBS SCHEME
Now, we show that the four CLS (CLAS) schemes and one CBS schemes are insecure against universal forgery attacks, type I attacks, type II attacks or malicious-but-passive-KGC attacks.

A. MALICIOUS-BUT-PASSIVE-KGC ATTACKS
In Then, the KGC publishes params = (p, G 1 , G 2 , e, g, g 1 , g 2 , u , U , v , V , m , M , H u , H v , H m ) as the public parameters.
• Then the KGC who knows β can obtain g 2αx 2 from a user public key PK = (pk 1 , pk 2 ) = (g x , g x 1 ) by computing (pk 2 ) 2β = (g x 1 ) 2β = (g 2 ) 2αx without using the user secret key x associated to PK .
• Using the value g 2αx 2 , the KGC can produce a signature of any message m under ID as follows: -Select r 1 , r 2 , r 3 ∈ R Z * p and calculate U ID , U PK , M and a signature cateless signature of m under {ID, PK }: it passes the following verification equations e(pk 1 , g 1 ) = e(pk 2 , g), . This attack illustrates how the malicious KGC manipulates the system parameters to generate users' valid signatures on any messages.
-Security of Tseng et al.'s scheme relies on the intractability of computing (g 2 ) αx from (g 1 ) x and g 2 (it is the Computational Diffie-Hellman problem), but it becomes easy if one knows the discrete logarithm of g 2 . -Thus, if the KGC chooses β ∈ R Z * p and calculates g 2 = g β as the system parameter then the KGC who knows the discrete logarithm β of g 2 can compute the core value (g 2 ) αx by computing (pk 2 ) β from its known value β of g 2 = g β without using the user secret key r ID = x of PK = (pk 1 , pk 2 ) = (g x , g x 1 ). -The KGC with the value g 2αx 2 can produce valid certificateless signatures on any messages for {ID, PK }.
-The KGC gets a signature σ = (σ 1 , σ 2 , R u , R v , R m ) of a message m under {ID, PK = (pk 1 , pk 2 ) = (g r ID , g r ID 1 )} from the signing oracle, where -Then the KGC can obtain (g α 2 ) r ID by computing -After getting the core value (g α 2 ) r ID , the KGC can generate valid signatures of a new message m under {ID, PK } as: pick r 1 , r 2 , r 3 ∈ R Z * p and calculate U ID , U PK , M and a signature . The signature is valid: it satisfies the following verification equation e(pk 1 , g 1 ) = e(pk 2 , g), e(σ 1 σ 2 , g) = e(g 2 , pk 2 2 ) · e(U ID , R m ). Finally, the KGC can produce valid signatures of any messages under {PK , ID} without using the user secret key r ID of the public key PK = (g r ID , g r ID 1 ).

Malicious-but-passive KGC Attacks on Deng et al.'s Scheme
• In the Setup phase, a malicious KGC first picks β ∈ R Z * p and calculates Q = βP.
• The KGC who knows β can generate a valid certificate-  • Assume that an adversary A can get a signature, • Then A can generate a signature of a new message msg i ||t i for {vepk i , PSUID i , ID Rs } as follows: -Compute

C. FORGERY ATTACKS ON CB-CAS
In certificate-based schemes, there exist two types of adversaries, F 1 and F 2 as: -F 1 is a malicious TA with a master secret key.
-F 2 is a malicious signer who has its secret signing key. The CBS scheme are similar to the CLS schemes. The adversaries F 1 and F 2 in the CBS schemes correspond to the type II adversary and the type I adversary in the CLS schemes, respectively.
In [23], the authors proved that their scheme was secure against the two types of adversaries, F 1 and F 2 under the intractability assumption of the Elliptic Curve Discrete Logarithm problem. Here, we show that CB-CAS is insecure against the two types of adversaries, F 1 and F 2 in spite of their security proofs. We also show that, in the scheme, a user can generate valid certificates of the other users from its own certificate received by the TA.
The First Attack on CB-CAS (Type II Attack).
where R i = r 1i P and C i = r 1i + sH 0 (ID i ||p k ID i ). • First, F 1 with the master secret key s can calculate Then, using the two values, X and s, F 1 can generate a valid signature (R i , Z i ) of a new message m i under {ID i , PK i } as . Then (R i , Z i ) is valid: it satisfies the following verification equation • Finally, F 1 forges successfully a valid signature of any message m i ( = m i ) for ID i without using the user secret key s ID i corresponding to ID i . Therefore, F 1 can produce valid signatures of any messages.

The Second Attack on Verma et al.'s Scheme (Type I Attack).
• Let F 2 be a malicious signer who has the secret signing key s ID i for ID i .
• Assume that F 2 wants to generate a valid signature of a message under ID i . Since F 2 can access the signing oracle, it gets a valid signature (R i , Z i ) of the message m i for ID i , where Let Y = r 2i + C i . Then, using the two values, Y and s ID i , Then (R i , Z i ) is a valid signature of m i under ID i : it passes the following verification equation • Suppose a user U i with ID i received its own certificate • Then U i can generate valid certificates of other users U j with {ID j , p k ID j } for j = i: Then U i can compute U j 's certificate as -Then, Cert ID j = (R 1j , C j ) is a valid U j 's certificate since its passes the following equation • Thus, the user U i can generate other users' certificates Cert ID j from its certificate Cert ID i for j = i.
• If we set the user as the second type adversary who knows users' secret keys then the user using other users' certificates can produce any signatures on any messages for the users.

IV. HOW TO DESIGN SECURE CLS AND CLAS SCHEMES
In the previous section, we presented the several algebraic attacks on the four CLS and CLAS schemes, and one CBS scheme although security of all the schemes were proved under the intractability assumptions of the mathematical problems. Our attacks do not mean that a random instance of each hard problem is solved, but all the security proofs against the type I adversary or the type II adversary are flawed neglecting the various attacks due to the algebraic relations of the underlying group elements. Here, we provide design principles for the construction of secure CLS and CLAS schemes to prevent various algebraic attacks including our attacks.

Integrity of Random Values.
If one uses randomized probabilistic algorithms for the partial private key extract algorithm and the signing algorithm instead of deterministic algorithms (for example, BLS signature scheme [25]) then random values should be included in the input of a hash function to prevent forgery attacks mounted by modifying the random values. It guarantees the integrity of the random values.
-In particular, as in Mei et al.'s scheme, to design compact CLAS schemes whose signature lengths are constant, some CLAS schemes remove the random values from the input of the hash functions that causes the universal forgery attacks, the type I attacks and the type II attacks. Vulnerabilities of the schemes [16], [23] against our attacks are due that it does not use appropriate hash values including the random values in the partial private key extraction and signing for compactness. is replaced with where U i = u i P is a random value generated in signing algorithm then our attack can be prevented.
• In CertExtract of CB-CAS, a user U i 's certificate Cert ID i = (R 1i , C i ) is generated as R 1i = r 1i P, C i = r 1i + sH 0 (ID i ||p k ID i ). The authors in [23] removed the value R 1i from in the input of H 0 (ID i ||p k ID i ) not to include R 1i in the signatures for compactness. Our certificate forgery attack allows the user to generate the other users' certificates from its own certificate by modifying the value of R 1i to satisfy the certificate verification equation. To prevent the attack, the hash value H 0 (ID i ||p k ID i ) should be replaced with H 0 (ID i ||p k ID i ||R 1i ). Then, the user cannot modify R 1i as he intended, since R 1i and H 0 (ID i ||p k ID i ||R 1i ) should be computed at the same time. Thus, the random value R i = r 2i P + R 1i related to R 1i should be separated and R 1i should be included in the signature.
-To prevent the first attack on CB-CAS, the random values, R i and R 1i , should be included in the input of the hash function H 1 as , and R 1i should be also included in the input of H 0 as H 0 (ID i ||p k ID i ||R 1i ). These improvements can prevent the attacks by modifying R i or R 1i so that the forged signatures satisfy the verification equations.
-To prevent the second attack on CB-CAS, a new hash value H 2 (m i ||p k ID i ||ID i || ||R 1i ||R i ) should be multiplied by r 2i or C i . -These improvements can prevent the attacks by using the information obtained from the previous signature of a message m to forge a signature of a new message m . To design the compact CB-AS scheme, Verma et al. eliminated the random values, R 1i and R i , from the inputs of all the hash values which caused the vulnerabilities of their scheme against our attacks. Thus, any random values in the schemes should be guaranteed their integrity to prevent the forgery attacks by modifying the random values in partial private keys or signatures. The inclusion of the random values in the input of hash function can prevent the attacks, but makes the construction of compact CLAS schemes and compact CB-AS schemes impossible since the random values cannot be aggregated into a single value. It is difficult to design a secure compact AS scheme since the generations of users' certificates and random values in signatures should be contained in appropriate hash values. Therefore, it still remains an open problem to construct a secure compact AS scheme with the constant-size aggregate signatures.

Binding Identities, Public Keys, Random Values with Messages.
In signing algorithms, it needs to bind a user identity, a user public key, random values generated in the partial private key extract algorithm and the signing algorithm with a message being signed. It can prevent various forgery VOLUME  and adding the identity ID as v = H v (PK , ID).
Then the type I adversary cannot use the value for {ID, PK * } to forge a signature of the message under {ID * , PK * } since the value U PK * in σ 2 is computed from v = H v (PK * , ID), so it is not matched to the value from v = H v (PK * , ID * ). In this case, the hash value m = H m (m, PK , ID) plays a role in binding the message m with {ID, PK } and the identity with the user public key, respectively. Thus, the CLS schemes should be designed so that the previous signature on a message must not be used to forge signatures other messages.
3. Type I Attacks: The exposure of the user secret key does not lead to the exposure of the master key or its related information. To prevent the type I attacks, CLS schemes should be designed so that the user public key cannot be modified to remove the value associated to the master public key from the verification equation. Using algebraic relations in the group, if one can find an appropriate user public key that makes the master public key removable in the verification equation then the type I attack is successful: its forgery is possible without using the partial private keys.
• In the second attack on CB-CAS, some algebraic relations in the group make the adversary get a target value associated to the master secret by subtracting the user secret key from the previous signatures. Thus, the CLS scheme should be designed so that the useful information related to the master secret cannot be extracted from the replaced public keys and their arithmetics since an adversary with the useful information can forge users' signatures without using the users' secret keys.
4. Type II Attacks: The exposure of the master secret key does not lead to the exposure of the user secret key or its related information. To prevent type II attacks, CLS schemes should be designed so that the KGC with the master secret cannot compute the values associated to a user secret key from the signatures obtained by the signing oracle. As seen in the first attack on CB-CAS, even though the KGC does not get the user secret key itself, the attacks succeed in forging signatures from the values associated to user secret key.
• The first attack on CB-CAS, algebraic relations in the group make the attacker get the target values associated to the user secret key by subtracting the value related to the master secret from the previous signatures. Thus, the CLS scheme should be designed so that the useful information associated to the user secret key cannot be extracted from the master secret and their arithmetics.
5. Malicious-but-Passive Attacks: Destroy algebraic structure of the group elements in the system parameters.
To prevent the malicious-but-passive KGC attacks, the algebraic structure of every group element in system parameters except the generators should be destroyed. It can be possible by using the hash functions.
• In Tseng et al.'s scheme, the algebraic structure of g 2 , u , U , v , V , m and M except the generator g and the master public key g 1 should be hidden by the hash function to prevent the attacks. The first malicious-butpassive-KGC attack on Tseng et al.'s scheme is due that the KGC knows the discrete logarithm of g 2 by computing g 2 = g β for its own choice β. If we set g 2 as the output of the hash function, where H 4 : G 1 → G 1 is a secure hash function. Then the KGC cannot know the discrete logarithms of Q and Y which can prevent our malicious-but-passive KGC attacks. In reality, the KGC can manipulate the system parameters so that the KGC succeeds to forge any signature on behalf of the victim. Although the underlying mathematical problems are hard, the KGC's malicious behaviors make the specific cases of the problems resolved. Thus, secure CLS (CLAS) schemes should be secure against these malicious-but-passive KGC attacks.

V. CONCLUSION
Due to the suitability of CLS and CLAS schemes for IoT environments, similar CLS and CLAS schemes have been proposed for a long time and, despite their security proofs, they have been attacked and modified to prevent the attacks. Even now, similar design methods and similar attacks on the schemes are being repeated. We first showed that recent four CLS and CLAS schemes, and one CB-signature were insecure against the universal forgery attacks, the type I attacks, the type II attacks or the malicious-but-passive KGC attacks. We discuss their security flaws, causes and countermeasures. We then presented design principles to prevent various algebraic attacks including our attacks. The design principles will help in the construction of secure CLS and CLAS schemes against the previous and potential attacks. We focused on security analysis of the type I attacks, the type II attacks, the universal forger attacks and the malicious KGC. However, in the multi-user setting consisting of the KGC and multiple users, insider attacks and colluding attacks should be considered. Future research will include security against insider attacks and colluding attacks in the multi-user setting.