#### Abstract

Forward-secure revocation is a powerful cryptographic technique to alleviate key exposure attacks on identity-based cryptosystems. In recent years, quantum computers have made some breakthroughs, so in the foreseeable future, existing cryptographic systems will be subject to quantum attacks. However, known forward-secure revocable identity-based signature (FS-RIBS) schemes were designed over bilinear pairing groups and may suffer from quantum computing attacks. To address this issue, this paper proposes a generic method to construct FS-RIBS schemes, taking (hierarchical) IBS schemes as a basic component. By instantiating it with some post-quantum (hierarchical) IBS schemes, e.g., lattice-based (hierarchical) IBS, we immediately obtain six FS-RIBS schemes under the hardness of the small integer solution problem, which is secure against quantum computing attacks.

#### 1. Introduction

In 1984, Adi [1] first introduced an identity-based mechanism. The core idea is to use the user’s identity as a public key for encryption or a public key for verifying signatures and give the first identity-based signature (IBS). Compared with PKI, it does not need to issue public key certificates and other related complex steps, which improves efficiency. However, it was not until 2001 that Boneh [2] proposed an identity-based encryption scheme for the first time. Boneh’s [2] revocable mechanism has huge computational overhead. To reduce the runtime of revocable user computations, Ge and Wei [3] proposed a binary tree method in 2008 with a logarithmic increase in computational cost. However, it cannot resist key exposure attacks.

In 2013, Seo and Emura [4] proposed a stronger definition and security model of RIBE (revocable identity-based encryption), which can resist decryption key exposure attacks. In 2014, they [5] also gave a new security definition of RIBS (revocable identity-based signature) scheme that can resist signing key exposure attacks and introduced a scalable RIBS scheme. In 2013, Tsai et al. [6] proposed a bilinear pair-based RIBS scheme under the standard model. All RIBS schemes before Tsai were constructed by the random oracle model. All subsequent RIBS schemes [7, 8] refer to Tasi’s security model and definition, where scheme [8] achieves the SU-CMA security under the standard model. However, the previous RIBS schemes cannot guarantee both efficient revocation and strong unforgeability simultaneously. In 2016, Liu et al. [9] proposed a strong unforgeable RIBS scheme that solves the above problems in the standard model. However, these RIBS schemes [6–8] cannot resist signing key exposure attacks. In 2018, Yang et al. [10] performed some optimizations based on [8]. Zhao et al. [11] also proposed an efficient communication scheme based on multi-linear mapping in 2019. With the imminent advent of quantum computers, the need for cryptographic schemes to resist quantum attacks is increasingly urgent. In 2015, Xiang [12] introduced the first lattice-based RIBS scheme using a complete subtree structure, which can prevent signing key exposure but requires a secret channel. In 2020, Xie et al. [13] proposed the RIBS scheme under the standard model on the lattice. Later in the same year, Xie et al. [14] proposed a scheme that can resist the exposure of the signature key. As recently as 2022, Xie et al. [15] proposed a fully homomorphic RIBS (RIBFHS) scheme, which is homomorphic and is the first RIBFHS scheme that considers signature key exposure on lattices. However, its security only is sID-EU-CMA and forward security cannot be guaranteed.

Furthermore, forward security has also become a hot research topic. Its original intention is to ensure that the adversary cannot decrypt the ciphertext of the user’s last period or forge the signature of the previous period after the private key of the current period is leaked. At present, few works research on the forward security of revocable signatures; only Wei et al. [16] studied forward security of revocable IBS. However, their construction security is based on traditional difficult problems and cannot resist quantum attacks. Qin et al. [17] proposed the general structure of revocable forward security encryption in 2021. Its main idea combines a node selection algorithm and identity-based hierarchical encryption. As far as we know, there is no revocable forward-secure identity-based signature scheme on the lattice. So, in this work, we propose a generic method to construct a forward-secure revocable identity-based signature (FS-RIBS) and introduce two methods to improve its verification efficiency.

##### 1.1. Our Contributions

This article is mainly inspired by Qin et al.’s work [17]. In this work, we research on FS-RIBS and its instantiations on lattices. In a FS-RIBS system (see Figure 1), we split each user’s private key into two parts: the first part is the secret key held by the user for a long time, and the second part is the signing key that is only available to sign messages signed within *t* time period. Any user’s “long-term” (this long-term secret key is not immutable, and it evolves once in each time period) secret key is also closely related to the time period and will change with the time period, while the verification key does not change. At the start of all time periods, KGC publishes the update key on the public channel to ensure that users who have not been revoked can sign typically.(i)Firstly, we introduce the formal definition and security model for the FS-RIBS system. The system captures signing key exposure resistance, forward security, and user revocation.(ii)Secondly, we give a generic construction of the FS-RIBS scheme. A forward-secure RIBS scheme is built on a hierarchical IBS scheme and a standard IBS scheme. The HIBS scheme was used to obtain the signing key of the user’s initial time period, and this initial signature key can deduce the signature key of the following time period. Then, a time-based update key is generated through IBS and a complete binary tree.(iii)Thirdly, we further make two improvements to our proposed generic construction; although it will increase some signature overhead, both improvements can greatly improve the efficiency of verifying signatures and have tight security.(iv)Finally, an instance of our generic construction on the lattice is given, which is secure against signing key exposure (SKE) attacks and is forward secure, and has scalability, as in the generic construction. We also present a comparison of our example with other related RIBS schemes, including classical and recent schemes, both bilinear map-based and lattice-based.

##### 1.2. Related Work

###### 1.2.1. Revocable Identity-Based Signature Schemes

The user’s revocable mechanism is a basic requirement for identity-based signatures. Boneh [2] mentioned for the first time that KGC generates a private key for each user who has not been revoked by cascading the user’s identity and time. Because the identity of each user is unique, this scheme has met forward security. However, this scheme does not have good scalability because the complexity of updating the key is , and time complexity increases with . refers to the total number of users, and *R* is the number of revoked users. Subsequently, Ge and Wei [3] introduced a structure that can reduce the size of the update key and reduced the update key size to . Subsequently, some works [6, 8] proposed new RIBS schemes. In 2014, Seo and Emura [5] proposed a new security model of RIBS, which can resist signing key exposure attacks and introduced a scalable RIBS scheme. All the following works [17, 18] are based on the improvement of the security model of the scheme [5], either increasing security or improving efficiency. In 2017, Wei et al. [16] proposed a scheme that can resist the exposure of signature keys and ensure forward security. However, all the above solutions are not resistant to quantum attacks. To resist quantum attacks, Xiang [12] proposed a lattice-based RIBS scheme in 2015, but its cancellation operation requires a secure channel. Subsequently, Wei et al. [16] introduced a RIBS scheme based on the NTRU lattice that the update key can be updated on the open channel. In the next few years, Xie et al. [13–15] proposed some RIBS schemes. These schemes all improve the security of the scheme in some cases. However, none of the above schemes can guarantee forward security. For now, there is no RIBS scheme on the lattice that can guarantee forward security and resist signature key exposure attacks.

###### 1.2.2. Forward-Secure Signature Scheme

For forward security (FS), Anderson [19] firstly proposed the idea of forward-secure signature in 1997. Later, Bellare and Miner proposed a more efficient scheme [20] based on [19] and gave the formal definition and security model of forward security signature. More forward-secure digital signature algorithms [21, 22] have been proposed. However, there is little research on identity-based forward-secure digital signature algorithm. In 2008, Liu et al. introduced the first FS-IBS scheme in [23]. Zhang et al. [18] gave the first FS-IBS scheme in 2014. In 2021, Wu and Huang [24] further proposed an efficient forward security algorithm on the lattice, which has stronger security. But there is no revocable mechanism, it and cannot resist key exposure attacks. To the best of our knowledge, Wei et al. [16] first studied FS-RIBS and gave a construction. But, it is not resistant to quantum attacks. Qin et al. [17] proposed the general structure of revocable forward security for encryption in 2021. Its main idea combines a node selection algorithm and identity-based hierarchical encryption.

#### 2. Preliminary

*Notations.* We use “” to represent a concatenation of two elements and , which can be binary strings, matrices, etc. We use “” to represent a time period in binary form. We denote sets with capital italic, e.g., and . Security parameter is . **mpk** means master public key, and **msk** means master secret key. The revocation list is represented by **RL**. A complete binary tree is represented by **BT**.

##### 2.1. The Algorithm of Node Selection

In order to prevent the time complexity of revoking users from increasing linearly, our revocation scheme adopts a node selection algorithm. The core idea of the algorithm is to use a complete binary tree to find the fewest nodes required to cover all non-revoked users. In this tree, each leaf node has a one-to-one correspondence with an identity. The set of all nodes on the path from the root node of the user **ID** to the leaf node is represented by Path (**ID**). and are used to represent the left and right child nodes of node . This algorithm will input **RL**, a binary tree **BT**, and time period. The algorithm has the following four steps:(1)Let sets and be empty sets.(2), if , add to .(3), if , then addend to ; if , then addend to .(4)If , return ; else return the root node.

Figures 2 and 3 give a simple example of this algorithm, in which Figure 2 shows that no user has been revoked, and Figure 3 shows that the user with has been revoked.

##### 2.2. Definition of (H)IBS

In this section, we introduce the formal definition of (H)IBS constructions. First, we give the definition of IBS, which can easily be extended to HIBS. There are 4 PPT algorithms in an IBS system:(i)**Setup**: on input and identity length , output **mpk** and **msk.**(ii)**Extract** (**mpk**, **msk**, **ID**): on input (**mpk, msk**) and an arbitrary identity , it outputs the user’s secret key , associated with .(iii)**Sign**: on input a message , and . A signature is returned.(iv)**Verify**: on input **mpk**, *M*, , and , it returns 0 if is invalid and 1 otherwise.

Essentially, the HIBS scheme only has one more feature than the IBS scheme, which is the feature of hierarchy, that is, the user of the parent node can deduce the key of the user of its child node, but the user of the leaf node cannot deduce the key of the parent node. However, there is no connection between the users of the IBS scheme. So, we just need to add a **Derive** algorithm to the IBS scheme. Let the maximum depth of our HIBS system be *d*; set a user , and the signature private key is , where . The **Derive** algorithm inputs **ID** and and obtains the key of the following hierarchy where *r* is 0 or 1. Through iteration, the user **ID** can get keys of all users whose depth is up to *d* and prefixed with **ID**. When , it is the IBS scheme.

Next, we give the security model of the (H)IBS scheme. Strong unforgeability under adaptive chosen message attack (SU-CMA) is the required security for our HIBS and IBS schemes. We set the maximum hierarchy depth of our HIBS scheme to be (IBS is the case of ). It formally defines the game between adversary and challenger .(1)**Setup:** gets (**mpk, msk**) by running **Setup** and sends **mpk** to adversary .(2)**Phase 1:** adaptively makes a polynomial number of the following queries:(i)**Create key**: for any identity at depth 1, the challenge runs **Extract** (**mpk, msk**, ). It adds to a key list *KL.*(ii)**Secret key**: can query a secret key for an identity where . first checks whether the key list has a secret key for identity which is a prefix of identity . If so, runs **Derive** and returns to the secret key . If no such tuple, returns . If , sends to .(iii)**Signature query:** can adaptively query for polynomial signatures. The identity and message of these signatures are arbitrary. Here, suppose queries times, the message set is , and the identity set is . Note that where refers to the -th identity. calculates the signature of these messages by **Sign**( where to form a set and returns the set to .(4)**Forgery:** the adversary forges a signature of . will succeed if the following three conditions hold:(1).(2) or its any prefix cannot be queried during the secret key query phase.(3) cannot be queried during the signature query phase.

The advantage of in the above game is defined as .

*Definition 1. *For any PPT adversary , if the above advantage of is negligible in , then the (H)IBS is SU-CMA secure.*Multi-Identity Security*. In the forgery stage, multiple identities can be submitted, and as long as one is successfully verified, the adversary is won. We assume there are *n* identities. By a hybrid argument, we can prove that the advantage of to forge a signature successfully is no more than .

#### 3. Definition of FS-RIBS Scheme

##### 3.1. Syntax of FS-RIBS Scheme

A forward-secure revocable identity-based signature (FS-RIBS) is made up of the following 8 algorithms:(i)(**mpk, msk, ST, RL**) **Setup**(: is the security parameter of the algorithm, represents the user’s identity space, and the algorithm has time periods. This algorithm inputs , , and and outputs (**mpk**, **msk**) and two empty sets **ST** and **RL.**(ii)**KeyGen** (**mpk, msk, ID, ST**): the algorithm generates a secret key for the newly added user **ID** and then outputs a secret key that can be evolved in initial time period 0 1.(iii): this algorithm outputs the secret key of the current time period *t* from the secret key of the previous time period *t*-1 through evolution.(iv)**SKUpdate** (**mpk, msk, RL, ST**, ): the algorithm outputs the update key within time period .(v)**SKGen**: in time period , this algorithm inputs update key and user **ID** secret key and returns a signing key within time period .(vi)**Sign**: on input a message , the algorithm signs it within the time period , identity **ID**, and signing key and outputs a signature .(vii)1/0 **Verify** (**mpk**, *M*, , **ID**, ): this algorithm verifies the signature and outputs 0 if is an invalid signature, and 1 otherwise.(viii)**RL****Revoke** (**RL, ID**, ): suppose that the input identity **ID** is not a non-revoked user at time period ; then, (**ID**, ) is added to **RL** by key authority, and it outputs new **RL.**

*Correctness*. An FS-RIBS needs to meet correctness as follows. For any message *M* and identity **ID**, if the user is not revoked at time period , then for **(mpk, msk, ST, RL)****Setup**, **KeyGen (mpk, msk, ID, ST)**, , **SKUpdate** (**mpk, msk, ST, RL,**), **SKGen**, and **Sign**(, **ID**, , *M*), **Verify** holds with overwhelming probability.

##### 3.2. Attacker Model

We refer to [25–27] and give what capabilities the attacker is allowed to have in our scheme combined with the actual situation. Attackers are divided into two different types:(1)T1 adversary is able to query of within time period . Thus, the user must have been revoked before time period.(2)T2 adversary does not do the above query. However, it is allowed to query a signing key within any and can query the secret key of after time period .

Both adversaries are allowed to obtain all public parameters of the system.

##### 3.3. Security Definition of FS-RIBS Scheme

Next, we give a security definition of FS-RIBS, which is resistant to signing key exposure and can guarantee forward security. The FS-RIBS scheme is SU-CMA secure.

*Definition 2. *(SU-CMA). The SU-CMA security of FS-RIBS is defined by the following experiment played between a challenger and a PPT adversary .(1)**Setup:** gets **mpk**, **msk**, **RL**, and a state **ST** by running **Setup**. **mpk** is sent by to . Then, sendsthat he wants to challengeand challenge time period.(2)**Query phase:** is allowed to make adaptive polynomial queries to as follows:(i) if queries the identity and creates key in time period , firstly, judges whether is the initial time period of the **ID**. If finds this to be the case, then it gets an initial secret key by running **KeyGen** (**mpk, msk, ID, ST**). Next, it adds triple (**ID**, , ) to the secret key list **SKL**. Otherwise, queries in **SKL** whether there exists a triple (**ID**, , ) satisfying . If this is the case, it iteratively runs **SKEval** (**mpk**, , ) until **SKEval** (**mpk**, , ), gets secret key in time period , and updates the triple (**ID**, , ) with (**ID**, , ). If this is not the case, returns to .(ii) if wants to query the secret key with in , searches the **SKL** for triple (**ID**, , ). If it searched such triple, sends to ; otherwise, it sends to .(iii) if sends a query for the update key at time period, gets and sends it to by running **SKUpdate** (**mpk, msk, ST, RL,**).(iv) if does a signing key query for **ID** within the time period , firstly, searches the **SKL** for the triple (**ID**, , ) satisfying . If it does not search such triple, responds . On the contrary, evolves from time period to by iterative running **SKEval** (**mpk**, , ) until **SKEval** (**mpk**, , ) and gets the signing key by running algorithm **SKGen** (, ). returns to .(v) returns **RL** to if it receives ’s request to query the revocation list for time period *t*.(vi): can adaptively query for polynomial signatures. The identity, time period, and the message of these signatures are arbitrary. Here, suppose queries *q* times; the message set is , the time period set is , and the identity set is . calculates the signature of these messages by **Sign** ( where to form a set and returns the set to . The above query has the following restrictions:(i) cannot query the signing key whose is within time period .(ii) can query the secret key of in time period , provided that must be revoked before time period .(iii)If the identity is not a non-revoked user within time period , return = to .(3)**Forgery:** the adversary forged a signature of . The adversary can win the game unless and **Verify**(**mpk**, , ) = 1.In the above experiment, the probability of successfully forging a verified signature is defined asFor any PPT adversary , if is negligible in , then the FS-RIBS scheme is SU-CMA secure.

#### 4. Our Generic Construction

The two fundamental schemes in our generic construction are HIBS and IBS. HIBS consists of five algorithms, **HIBS.Setup, HIBS.Extract, HIBS.Derive, HIBS.Sign,** and **HIBS.Verify** and its maximum depth is . The IBS is composed of 4 algorithms: **IBS.Setup, IBS.Extract, IBS.Sign,** and **IBS.Verify**. We let the message spaces of our HIBS and IBS schemes be for both. As described in Construction 1, we construct a FS-RIBS scheme consisting of eight algorithms: **RIBS.Setup, RIBS.KeyGen, RIBS.SKEval, RIBS.SKUpdate, RIBS.SKGen, RIBS.Sign, RIBS.Verify,** and **RIBS.Revoke**. Obviously, the message space of this scheme is , is the identity space of this scheme, and is the time period space of this scheme.

In the construction, the signature key of each user is related to a discrete time period. Specifically, it is necessary to cascade a certain time period after each user **ID**, where *t* is binary. In other words, when generating the signature key, the **ID** is concatenated with a certain time period as the input identity, which will lead to each user **ID** having different signature keys in different time periods, which ensures its forward security. More specifically, a time period can be represented by the integer of -bit, arranged from the top of the tree to the bottom. For , a set of identities is represented by and is treated as an identity vector. For, :

We give an example as shown in Figure 4. In the figure, time and time periods, and the set .

##### 4.1. Basic Construction

*Construction 1 (Forward-Secure RIBS Scheme)*. *Our generic construction of FS-RIBS scheme is detailed as follows*(i): it runs and **IBS.Setup** to obtain and , respectively. It initializes **BT**, whose depth is . All leaf nodes are closely related to an identity. Ultimately, it outputs , , an empty revocation list **RL**, and **ST** = **BT.**(ii) textbfRIBS.KeyGen (**mpk, msk, ID, ST**): generate a secret key set for any user , and the algorithm first calculates the set for initial time period 1. For *c* = 1, , +1, if , it runs **HIBS.Extract** to get a secret key . If , it sets . Ultimately, this algorithm outputs the secret key .(iii)**SKEval**: for , firstly, the algorithm calculates the two sets and . For +1, if , there must be an element in the set such that a prefix of (**ID**, ) is (**ID**, ). It then runs **HIBS.Derive** to gain the corresponding key . If , it sets . Ultimately, it returns .(iv): for , firstly, this algorithm runs node selection algorithm to get cover set **KUN** (**BT,RL**,t). Then, for , it runs **IBS.Extract** to get the key corresponding to identity . Ultimately, it outputs the update key set .(v): suppose that a user’s and . Suppose that **ID** is a non-revoked user within time period *t*; there must exist a . It outputs **ID**’s signature key .(vi): for a message , suppose that **ID** is a non-revoked user within time period; the signer has a valid signing key . Then, it computes , and . Finally, the algorithm returns a signature .(vii): for a signature , the algorithm computes and for each node . Note that is a set. If there is a such that , the algorithm outputs 1, and 0 otherwise.(viii)**RL****Revoke** (**RL, ID**, ): suppose that the input identity **ID** is not a non-revoked user at time period ; then (**ID**, ) is added to **RL** by key authority and outputs new **RL.**

*Correctness*. The correctness of Con.1 (Construction 1) is determined by the correctness of the fundamental HIBS and IBS schemes. Suppose that identity **ID** is a non-revoked user within time period ; in the IBS scheme, the signing key corresponding to is , and is the signing key corresponding to in the HIBS scheme. The two signature algorithms **IBS.Sign** and **HIBS.Sign** can correctly sign the message *M*. We can correctly get by **HIBS.Sign** and **IBS.Sign**. Then, compute **HIBS.Verify** and **IBS.Verify** for each node . There always exists a such that = 1 holds.

*Security*. The SU-CMA security of Con.1 is determined by the SU-CMA security of the fundamental HIBS scheme and IBS scheme. Especially, it is ensured by Theorem 1.

Theorem 1. *If the fundamental HIBS and IBS schemes are SU-CMA secure, the FS-RIBS scheme in Con.1 is SU-CMA secure.*

*Outline of Proof*. Firstly, we emphasize the core idea of security proof and then introduce a strict proof of security reduction. For this proof, adversaries are classified into two types as described in Section 3.2. T2 adversary is designed to break Con.1’s forward security. For T1 adversary, we need to build an emulator to store the master secret key of the fundamental HIBS and reduce the SU-CMA security of the FS-RIBS scheme to the SU-CMA security of the fundamental IBS scheme. For T2 adversary, the emulator holds the master secret key of the fundamental IBS scheme and reduces the SU-CMA security of the FS-RIBS scheme to the SU-CMA security of fundamental HIBS scheme.

*Proof. *Let adversary break the SU-CMA security of the FS-RIBS scheme; then, we build a PPT emulator to break the SU-CMA security of the fundamental IBS scheme or HIBS scheme. The emulator works in two steps: firstly, it randomly gets a bit . Secondly, if , is regarded as a T1 adversary, else a T2 adversary. So, the probability of correctly or incorrectly guessing the adversary’s type is 1/2.(i)For T1 adversary, is given of the fundamental IBS scheme. It emulates the process as follows:(1)**Setup:** it produces the master key pair of the fundamental HIBS scheme. initializes **RL** and **BT**. It sends and to . Then, sends a challenge identity and a challenge time period to .(2)**Phase 1:** since gets the of HIBS scheme, it can respond to ’s secret key query and create key query for any time period and any **ID**. If needs an update key query within time period , first calculates the set **KUN** (**BT,ST**, ). Then, it sends the set of identities to the challenger of the fundamental IBS scheme to get the corresponding update keys . Ultimately, sends to . can get corresponding update keys from its challenger, so can respond to ’s signing queries.(3)**Signature query phase:** can adaptively query for polynomial signatures. The identity, time period, and message of these signatures are arbitrary. Here, suppose queries times, the message set is , and the time period set is . For , it calculates and if is a non-revoked user within time period , respectively. Finally, it returns to .(4)**Forgery:** let us assume that successfully constructs a signature , and this signature . Now, we calculate the probability of success of . First, we calculate **HIBS.Verify** and **IBS.Verify** for . Then, in the above emulated experiment, since has been revoked before the challenge time period, for any (even the challenge) time period , the sets of identities . Therefore, the challenge identities that transmits to its own challenger are indeed valid. Naturally, if is a valid FS-RIBS signature, there must exist one , so that . That is, is a valid IBS signature under identity . Thus, has the same success probability of breaking the SU-CMA security of the fundamental IBS scheme. Therefore, we have where is any PPT adversary who can break the SU-CMA security of the fundamental IBS scheme.(ii)Next, for T2 adversary, we introduce a PPT algorithm to emulate the experiment and reduce the SU-CMA security of our FS-RIBS scheme to the SU-CMA security of the fundamental HIBS scheme. is the master public key of the HIBS scheme and gets the master key pair of IBS by itself. can respond to ’s queries about creating keys and secret keys. Obviously, may query the secret key within . can answer the update key queries using of the fundamental IBS scheme. The signature query is the same as the signature query of T-1. Let us assume that successfully constructs a signature . Because the is a non-revoked user in the time period , its is necessary to pass the verification. Then, because can only query for the signing key , successfully forges which is equivalent to breaking the SU-CMA security of the fundamental HIBS scheme. Thus, for Type-2 adversary, we will havewhere is any PPT adversary who can attack the SU-CMA security of the fundamental IBS scheme.

Considering the above two cases comprehensively, we can get the following inequality:

##### 4.2. Improvement

In Con.1, to determine the validity of the second part signature , Con.1 requires computing IBS verification algorithm times for each identity , where . Next, we introduce two simple methods to solve this problem.

###### 4.2.1. The First Method

The difference from Con.1 is that the second component of IBS scheme is replaced with a HIBS scheme. That is, the HIBS scheme will be used to get the update keys of the FS-RIBS scheme. Additionally, the value of each selected node in the node section algorithm is regarded as the identity vector of the fundamental HIBS scheme. For example, suppose that = 101 as in Figures 2 and 3. Therefore, for , the identity vector is used to represent . The details of this improved FS-RIBS scheme are given in Construction 2.

*Construction 2 (Forward-Secure RIBS Scheme)*. The construction is described as follows.(i)(**mpk, msk, ST, RL**) **RIBS.Setup**: *it gets**by running ***HIBS.Setup***and* by running **HIBS.Setup**. *A complete binary tree of depth**is initialized by the algorithm. Each leaf node corresponds to an identity. Ultimately, it returns*, , **ST** = **BT**, *and ***RL.**(ii)**RIBS.KeyGen**(**mpk, msk, ID, ST**): *this algorithm is the same as in* Construction 1.(iii): *this algorithm is the same as in* Construction 1.(iv): for , *firstly, it calculates the cover set ***KUN**(**BT, RL**, ). *Then,*, *it runs ***HIBS.Extract***to get the key**corresponding to the hierarchical identity*. *Ultimately, it returns the update key*.(v): *suppose that a user’s current secret key is**and current update key is*. *Suppose that ***ID ***is a non-revoked user at time period*; *there must be a node such that*. *Therefore, a prefix of**must be*. Firstly, *The algorithm runs ***HIBS.Extract***to get the corresponding key*. *It returns the corresponding signing key*.(vi): *if the identity ***ID ***is a non-revoked user within**time period,*. *Then, it computes*, *and*. *Finally, the algorithm returns a signature*.(vii): *for a signature*, *the algorithm computes**and*. *If*, *the algorithm outputs 1, and 0 otherwise.*(viii): *suppose that the input identity ***ID ***is not a non-revoked user at time period*; *then*, (**ID**, ) *is added to ***RL ***by key authority and outputs new ***RL.**

*Correctness*. Similar to the first generic construction, the correctness of Construction 2 (Con.2) is based on the correctness of two basic HIBS schemes. The difference from Con.1 is that is the signing key corresponding to identity vector in the second HIBS scheme, and the actual signature key is extracted from as is a prefix identity vector of . Therefore, the two verify algorithms of HIBS schemes can verify and , respectively.

*Security*. The SU-CMA security of Con.2 is determined by the SU-CMA security of the fundamental HIBS schemes. Then, we have Theorem 2.

Theorem 2. *If the fundamental HIBS schemes are SU-CMA secure, then the FS-RIBS scheme in Con.2 is SU-CMA secure.*

The proof of Theorem 2 is basically the same as Theorem 1. The only difference is that is obtained by a HIBS scheme. We omit its proof.

###### 4.2.2. The Second Method

Observe that, in Con.1, as the verifier does not know the target node used by the signer to generate the second part signature , he must run the IBS verification algorithm times for each node . So, to solve this issue, the signer can indicate the target node in the signature. The second improved FS-RIBS scheme (referred to as Construction 3) is identical to that of Con.1, except for the following differences in algorithms and .(i)The modified signing algorithm : for a message , if **ID** is a non-revoked user within time period , the signer should have a valid signing key . Then, it sets and computes , and . Finally, the algorithm returns a signature .(ii)The modified verification algorithm : for a signature , firstly, the algorithm judges whether . If this is not the case, it outputs ; otherwise, it sets and computes and . If , the algorithm outputs 1, and 0 otherwise.

In Con.1, if we change the message to , where is the corresponding node in the signing key , this is just the above improved Construction 3 (Con.3). So, the correctness and security of Con.3 can be proved similarly as in Con.1. We omit the details.

#### 5. Lattice-Based Instantiation and Comparison

In this section, we instantiate our generic construction to several lattice-based (H)IBS schemes and compare them with other lattice-based RIBS games. These schemes have or do not have forward security.

##### 5.1. Instantiations

The instantiation of the fundamental HIBS scheme uses the scheme of Rückert [28], and the instantiation of the fundamental IBS scheme uses the scheme of Liu et al. [29]. It produces an adaptively secure FS-RIBS scheme (represented by “Con.1+ [28, 29]”). In addition, the instantiations of Construction 2 and Construciton 3 are represented by “Con.2+ [28]” and “Con.3+ [28, 29],” respectively). To reduce the storage overhead of instantiation, we further replace the above HIBS scheme with the HIBS scheme of Tian et al. [30] and the above IBS scheme with the IBS scheme of Chen et al. [31] (represented by “Con.1+ [30, 31],” “Con.2+ [30],” and “Con.3+ [30, 31],” respectively). Next, we take Con.1+ [28, 29] as an example to introduce the detailed requirement and parameter settings:(1)The schemes in [28, 29] are strongly unforgeable under choice message attack. Their security is based on SIS over lattices.(2), where is a trapdoor , . . The sizes of are defined in Proposition 1 of Rückert [28].(3)The definitions of and are not different from those in Section 3 of Liu et al. [29].(4)The key extraction algorithm is the same as that defined in [28, 29]. The difference is that only input in [28, 29] is the identity, while our HIBS part (user’s long-term private key) input is , and the IBS part (user’s temporary private key) input is .(5) is constructed as in Section 4.2 [28] and is constructed in Section 3 [29]. The bottom layer of the signature algorithms in both parts is based on the SIS problem, in which the **HIBS.Sign ()** algorithm is based on the **SamplePre** algorithm proposed by Craig et al. [32]. **IBS.Sign ()** algorithm is based on **SampleLeft** algorithm proposed by Agrawal et al. [33].

The instantiation details of other schemes (“Con.2+ [28]” and “Con.3+ [28, 29]”) are similar to the above schemes and will not be repeated.

##### 5.2. Comparison

We mainly compare security and storage overhead through two tables. We compare the security of our six schemes (“Con.1+ [28, 29],” “Con.2+ [28],” “Con.3+ [28, 29],” “Con.1+ [30, 31],” “Con.2+ [30],” and “Con.3+ [30, 31]”) with other RIBS schemes in Table 1, in terms of whether it has forward security (FS), whether it is signing key exposure resistance (SKER), whether it is under the standard model or the random oracle model (SD/RO), whether it is existential unforgeability or strong unforgeability (SU/EU), whether it is resistant to quantum attacks (RQA), whether it is adaptive or not adaptive, and what difficult problems (DPs) are these schemes based on. We list in Table 2 space cost of our six schemes and other RIBS schemes in terms of , , and signature . In Table 2, the binary string length of the message is , is the maximum time period, and . means that the complexity of the subsequent scheme must be multiplied by the vector or matrix after .

It can be seen from Table 1 that our schemes can resist most attacks, including quantum computing attacks, forward security, revocation (backward security), standard model, signing key exposure attacks, and strong unforgeability. From Table 2, we can see that the master key and signature size of our “Con.1+ [28, 29],” “Con.2+ [28,]” and “Con.3+ [28, 29]” are large. This is because the underlying HIBS scheme [28] does not apply lattice basis delegation [35]. As shown in “Con.1+ [30, 31],” “Con.1+ [30]” and “Con.3+ [30, 31],” we then used the technique of [30] and the lattice basis delegation [31] to reduce the size of the signature as well as the system master key to a constant size.

#### 6. Conclusion and Future Work

This paper introduced a generic method to construct forward-secure revocable identity-based signature and introduced two methods to improve its verification efficiency. In addition, the paper instantiated the generic construction from various lattice-based (H)IBS schemes and obtained the first lattice-based FS-RIBS schemes. In the future, we will try to optimize the fundamental HIBS or IBS scheme to improve its practicality.

#### Data Availability

No data were used to support this study.

#### Conflicts of Interest

The authors declare that they have no conflicts of interest.

#### Acknowledgments

This study was supported by the National Natural Science Foundation of China (grant nos. 62002288 and 61872292), the Basic Research Program of Qinghai Province (grant no. 2020-ZJ-701), the fund of Science and Technology on Communication Security Laboratory (grant no. 6142103190101), and the Natural Science Foundation of Shanghai (grant no. 19ZR1454100).