Identity-based linear homomorphic signature for a restricted combiners’ group for e-commerce

Our contributions

Our proposed scheme, identity-based linear homomorphic signature for a restricted combiners’ group (IBLHS-RCG), restricts the combiners’ group, proves it is correct and secure in the random oracle model, and operates efficiently under the computer simulation experiments. The specific contributions of this article are as follows:

• 1.

  We propose a novel linear homomorphic signature (LHS) scheme that restricts specific authorized intermediate nodes from performing linear combinations of signature vectors according to different tasks. This measure effectively prevents unauthorized nodes from maliciously combining signature vectors.

• 2.

  We construct the first linear homomorphic signature scheme that is simultaneously resistant to malicious combinations, based on the original designated single combiner signature scheme (Lin, Xue & Huang, 2021), we expanding its functionality to a linear homomorphic signature scheme that can specify multiple combiners.

• 3.

  We compress the time for signature and signature verification to sublinear complexity. Our scheme’s achieved signature length does not change after combination, and it reduces the verification and communication costs during transmission and after the combination signature more than Lin’s designated combiner scheme (Lin, Xue & Huang, 2021).

• 4.

  We propose an identity-based linear homomorphic signature scheme for restricted combiner group. we combine this article’s scheme with the identity-based signature scheme, which makes the scheme more compatible with the IP network environment.

Related work

Electronic transactions (Cao, 2023; Al-Zubaidie & Shyaa, 2023) must occur in environments characterized by low latency and well-defined authorization protocols. Various external defense mechanisms and content-based security strategies have been proposed to enhance network protocols. Among these, network coding facilitates efficient content distribution while maximizing transmission throughput. However, a notable drawback is that data packets within network coding are susceptible to corruption, which presents significant challenges for secure data transmission.

To protect data confidentiality, homomorphic encryption can be employed. While encryption prevents attackers from eavesdropping on the original data, it does not inherently verify data integrity and authenticity. This gap can have serious ramifications in financial transactions, as tampered transaction data during transmission can impair recognition by the combiner group, thereby undermining the credibility of electronic transactions and causing substantial harm to electronic finance.

Thus, in addition to securing data content, ensuring data integrity and authenticity is crucial. One effective approach is the use of digital signatures combined with message digest functions to verify both the authenticity and integrity of data packets. Digital signatures provide non-repudiation, ensuring that the sender cannot deny the transmission of a specific message, while message digest functions guarantee that the message remains intact throughout its transmission. The homomorphic signature scheme represents a promising solution that simultaneously addresses these essential criteria.

In the era of big data, with increasing awareness of privacy protection, more attention is being given to securing data during network transmission and ensuring stored data integrity in the cloud. While digital signatures guarantee data integrity and verify data owner identity, their lack of homomorphic properties leads to increased bandwidth consumption during transmission—a major obstacle to their deployment in network environments. Homomorphic signatures aim to preserve the benefits of digital signatures while enabling operations on smaller, homomorphically linked packets. This leverages the aggregation capabilities of intermediate nodes, reducing both the number of packets transmitted and their size, thereby improving efficiency.

Early in 2000, Rivest proposed the basic concept of homomorphic signature schemes (Rivest, 2000). In 2002, the first formal definition of homomorphic signatures was proposed by Johnson et al. (2002). After 2002, research achievements in homomorphic signature schemes emerged in succession, such as linear homomorphic signature (LHS) schemes (Lin, Xue & Huang, 2021; Boneh et al., 2009; Boneh & Freeman, 2011b; Gennaro et al., 2010; Lin et al., 2018; Wang, Hu & Wang, 2013), polynomial homomorphic signature (PHS) schemes (Boneh & Freeman, 2011a), fully homomorphic signature (FHS) schemes (Gentry, 2009; Wang et al., 2015; Wang & Wang, 2020), homomorphic aggregate signature (HAS) schemes (Jing, 2014; Zhang, Yu & Wang, 2012), and multi-key homomorphic signature (MHS) schemes (Aranha & Pagnin, 2019; Fiore et al., 2016; Lai et al., 2018). Among them, LHS schemes (Zhao et al., 2007; Yu et al., 2008; Boneh et al., 2009; Cheng et al., 2016; Li et al., 2018; Chang et al., 2019; SadrHaghighi & Khorsandi, 2016; Zhang et al., 2018; Li, Zhang & Liu, 2022) are particularly useful in preventing pollution attacks in linear network coding.

In 2007, Zhao et al. (2007) proposed a linear homomorphic signature scheme with a network encoding function, which implements a signature scheme in a network encoding environment at a negligible cost; however, its security cannot be guaranteed. In 2008, Yu et al. (2008) proposed an antipollution homomorphic signature scheme based on the RSA difficulty problem, which can achieve improvements in efficiency and security. After 2009, Boneh et al. (2009) proposed the first formal definition of linear homomorphic signatures and proposed more efficient and secure signature schemes in network environments. At this point, research on linear homomorphic signatures began to move in the right direction. Based on Boneh et al. (2009), many linear homomorphic signature schemes based on public key infrastructure (PKI) were designed (Cheng et al., 2016; Li et al., 2018). However, these schemes are unsuitable for electronic transactions with high time requirements because the signature of the data packet needs to be bound with corresponding certificates, resulting in the signature length of the data packet being much longer than the data packet. Subsequently, some identity-based linear homomorphic signature schemes (Chang et al., 2019; Zhang et al., 2018) were proposed to address this issue. These schemes reduce the length of the signature, but the excessive signature generation and verification costs still cannot satisfy the requirements of the Internet environment. It was not until 2022 when Li, Zhang & Liu (2022) proposed a secure and efficient identity-based homomorphic signature, that the cost of signature generation and verification began to level out. For a comprehensive comparison of the various types of linear homomorphic signature schemes, the nature of the underlying hard problems, and other relevant factors, please refer to Table 1.

However, beyond ensuring transaction verifiability, electronic transactions should also exhibit partial transparency rather than full transparency. This is inherent to the privileged service model of electronic transactions, where only specific, partially privileged intermediate nodes can perform combination and verification at each step. Direct application of homomorphic signatures, however, would render the entire transaction process fully transparent across the network—an outcome we seek to avoid. After combining Li, Zhang & Liu (2022) and Lin, Xue & Huang (2021), we propose an efficient signature scheme that can specify multiple combiners and maintain the generation and verification costs of signatures at a constant level.

Article structure

The rest of this article is structured as follows. In the “Preliminaries and Related Definitions” section, we briefly review some basic concepts in linear homomorphic signature schemes. In the “Concrete Scheme” section, we present the proposed IBLHS-RCG scheme and analyze its correctness. In the “Security Analysis” section, we provide security proof of the scheme. In the “Performance Analysis” section, we provide a performance evaluation of the scheme. Finally, we provide our conclusions in the “Conclusions” section.

Preliminaries

Existential unforgeability under adaptive chosen message attacks (EUF-CMA) security model (Boneh & Freeman, 2011a). If an adversary of a probabilistic polynomial time algorithm (PPT) cannot win the challenge response game with advantage $ϵ$ within time t after asking for q signatures, then a signature scheme is said to have achieved (t,q, $ϵ$)-security in the EUF-CMA security model. That is, the adversary satisfies the following properties:

• 1.

  The adversary can forge the signature ${\sigma }^{\ast }$ for $v^{\ast }$.

• 2.

  The forged ${\sigma }^{\ast }$ has not been queried during the interrogation phase.

Asymmetric bilinear mapping (Boneh & Franklin, 2001; Verheul, 2001; Boneh, Lynn & Shacham, 2004; Miller, 2004). Select three cyclic groups ${\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_{\mathrm{T}}$, where $\mathrm{o}\mathrm{r}\mathrm{d}({\mathbb{G}}_1)=\mathrm{o}\mathrm{r}\mathrm{d}({\mathbb{G}}_2)=\mathrm{o}\mathrm{r}\mathrm{d}({\mathbb{G}}_{\mathrm{T}})=\mathrm{p}$ ( $\mathrm{p}$ is a prime number), and define a mapping $\mathrm{e}:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_{\mathrm{T}}$ that satisfies the following relationship:

• 1.

  Bilinear: $\mathrm{\forall }g\in {\mathbb{G}}_1,h\in {\mathbb{G}}_2,a,b\in {\mathbb{Z}}_{\mathrm{p}}$, we have $\mathrm{e}(g^a,h^b)=\mathrm{e}(g,h{)}^{ab}$.

• 2.

  Nondegeneracy: $\mathrm{\forall }g\in {\mathbb{G}}_1\mathrm{\backslash }\{1\},h\in {\mathbb{G}}_2\mathrm{\backslash }\{1\},\mathrm{e}(g,h)\ne 1_{{\mathbb{G}}_{\mathrm{T}}},1_{{\mathbb{G}}_{\mathrm{T}}}$ is the identity element of ${\mathbb{G}}_{\mathrm{T}}$.

• 3.

  Computability: $\mathrm{\forall }g\in {\mathbb{G}}_1,h\in {\mathbb{G}}_2,\mathrm{e}(g,h)$ can be efficiently calculated.

Co-Computational Diffie-Hellman (co-CDH) problem (Boneh, Lynn & Shacham, 2004; Huang & Wang, 2010; Galbraith & Verheul, 2008). We define two bilinear groups ${\mathbb{G}}_1$ and ${\mathbb{G}}_2$, where $\mathrm{o}\mathrm{r}\mathrm{d}({\mathbb{G}}_1)=\mathrm{o}\mathrm{r}\mathrm{d}({\mathbb{G}}_2)=\mathrm{p}$ ( $\mathrm{p}$ is a prime number); we randomly select $a\in {\mathbb{Z}}_{\mathrm{p}}$, give $g\in {\mathbb{G}}_1,h,h^a\in {\mathbb{G}}_2$, and the algorithm A can solve $g^a$. We denote this probability as $\mathrm{P}\mathrm{r}(\mathrm{P}\mathrm{P}{\mathrm{T}}_A(g,h,h^a)=g^a,a\in {\mathbb{Z}}_{\mathrm{p}})$.

Co-CDH assumption (Huang & Wang, 2010; Ng, Tan & Chin, 2018; Chang et al., 2017). For any PPT adversary, the probability that they can solve the co-CDH problem is negligible; that is, $\mathrm{P}\mathrm{r}(\mathrm{P}\mathrm{P}{\mathrm{T}}_A(g,h,h^a)=g^a,a\in {\mathbb{Z}}_{\mathrm{p}})=negligible$, meaning that the PPT adversary wanting to solve the co-CDH problem will have difficulty.

Chinese Remainder theorem (CRT) (Schindler, 2000; Zheng, Huang & Matthews, 2007; Quisquater, Preneel & Vandewalle, 2002). Suppose that $m_1,m_2,\dots ,m_n$ are mutually prime for any two pairs. The equations

(1) $$\{\begin{array}{c}x\equiv a_1(mod{m}_1),\hfill \\ x\equiv a_2(mod{m}_2),\hfill \\ ⋮\\ x\equiv a_n(mod{m}_n)\hfill \end{array}$$have a solution. If ${\chi }_1,{\chi }_2,\dots$ are the solutions to these equations, then we have ${\chi }_1\equiv {\chi }_2\equiv \cdots \equiv x(modM),$ $M={\prod }_{i=1}^n{m}_i,x\equiv {\sum }_{i=1}^n{a}_i\cdot \frac{M}{m_i}\cdot (\frac{M}{m_i}mod{m}_i{)}^{-1}modM$.

ID-based signature

An identity-based signature scheme typically consists of four algorithms: initialization algorithm Setup, key extraction algorithm KeyExt, signing algorithm Sign and verification algorithm Verify. The process involves interaction between the private key generator (PKG) and the user. The main steps are as follows:

• $(params,msk)\leftarrow \mathbf{S}\mathbf{e}\mathbf{t}\mathbf{u}\mathbf{p}(1^{\lambda })$: Input security parameter $1^{\lambda }$, output public parameters $params$ and master secret key $msk$, where $msk$ is kept secret by the PKG.

• $s{k}_{ID}\leftarrow \mathbf{K}\mathbf{e}\mathbf{y}\mathbf{E}\mathbf{x}\mathbf{t}(msk,ID)$: Input master secret key $msk$ and user’s identity ID, PKG computes the user’s private key $s{k}_{ID}$, and transmits it to the user via a secure channel.

• $\sigma \leftarrow \mathbf{S}\mathbf{i}\mathbf{g}\mathbf{n}(s{k}_{ID},m)$: Input the user’s private key $s{k}_{ID}$ and the message $m$ to be signed, output the user’s signature $\sigma$ for the message $m$.

• $0/1\leftarrow \mathbf{V}\mathbf{e}\mathbf{r}\mathbf{i}\mathbf{f}\mathbf{y}(ID,params,m,\sigma )$: Input the user’s identity ID, the public parameters $params$, the message $m$ and its signature $\sigma$, if the verification is passed, output 1; otherwise, output 0.

The formal definition of LHS

A linearly homomorphic signature scheme (LHS) (Boneh et al., 2009) consists of the following four PPT algorithms.

$(PK,SK)\leftarrow \mathbf{S}\mathbf{e}\mathbf{t}\mathbf{u}\mathbf{p}(1^{\lambda },N)$: Input the security parameter $\lambda$ and an integer N, generate the bilinear group $\mathcal{G}=({\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_{\mathrm{T}},\mathrm{p},\mathrm{e},\phi )$, choose the generator element $h$ of ${\mathbb{G}}_2$ and randomly choose an element $\alpha$ on ${\mathbb{F}}_{{\mathrm{p}}^{\ast }}$, such that $u=h^{\alpha }$, $\mathrm{H}:\{0,1{\}}^{\ast }\times \{0,1{\}}^{\ast }\to {\mathbb{G}}_1$, output the public key $PK=(\mathcal{G},\mathrm{H},h,u)$ and the private key $SK=\alpha$.

$\sigma \leftarrow \mathbf{S}\mathbf{i}\mathbf{g}\mathbf{n}(SK,id,v)$: Input private key SK, file label $id=\{0,1{\}}^{\lambda }$ and vector $v=(v_1,\cdots ,v_n)$, output signature $\sigma =({\prod }_{i=1}^N\mathrm{H}(id,i{)}^{v_i}{)}^{\alpha }$.

$\sigma \leftarrow \mathbf{C}\mathbf{o}\mathbf{m}\mathbf{b}\mathbf{i}\mathbf{n}\mathbf{e}(PK,id,\{{\beta }_i,{\sigma }_i{\}}_{i=1}^l)$: Input public key PK, file label $id$, and binary tuple $\{{\beta }_i,{\sigma }_i{\}}_{i=1}^l$, and then output signature $\sigma ={\prod }_{i=1}^l{{\sigma }_i}^{{\beta }_i}$.

$0/1\leftarrow \mathbf{V}\mathbf{e}\mathbf{r}\mathbf{i}\mathbf{f}\mathbf{y}(PK,id,y,\sigma )$: Input public key PK, file label $id$, verification vector $y=(y_1,\cdots ,y_n)$, and signature $\sigma$. If $\mathrm{e}(\sigma ,h)=\mathrm{e}({\prod }_{i=1}^N\mathrm{H}(id,i{)}^{y_i},u)$ is established, the verification passes and outputs 1; otherwise, outputs 0.

Security definitions

In this subsection, we will detail the properties and definitions (Boneh & Freeman, 2011a; Ateniese et al., 2000) related to security analysis as follows.

The formal definition of IBLHS-RCG

Before presenting the formal definition of this scheme, we give the concrete notation Table 2 for a clearer understanding of our scheme. IBLHS-RCG is a linear homomorphic signature scheme that can only be combined in a specified group of combiners. Based on the original LHS signature, we add four steps KeyExt, Quest, GroupVerify, and PartialVerify, so that the combiners in the scheme cannot take up bandwidth by arbitrarily combining signatures. Our scheme consists of the following eight PPT algorithms. $(params,msk)\leftarrow \mathbf{S}\mathbf{e}\mathbf{t}\mathbf{u}\mathbf{p}(1^{\lambda },N)$: This step is run by PKG, with the input of security parameter $\lambda$ and augmented vector dimension N. The algorithm generates public parameter $params$ and broadcasts it to the entire network while secretly preserving the master private key $msk$.

$us{k}_{ID}\leftarrow \mathbf{K}\mathbf{e}\mathbf{y}\mathbf{E}\mathbf{x}\mathbf{t}(ID,msk)$: This step is run by PKG, where the user inputs their own identity ID, PKG inputs $msk$, and the algorithm outputs the corresponding user’s private key $us{k}_{ID}$, which is returned to the user. After receiving $us{k}_{ID}$, the user can verify the credibility of the PKG.

$(Q,b_{ID})\leftarrow \mathbf{Q}\mathbf{u}\mathbf{e}\mathbf{s}\mathbf{t}(ID,q_{ID})$: This step is run by the signer and the combiners. The applicant combiners submit the identity ID and access level parameter $q_{ID}$ to the signer to apply for the signature combination right of a certain quantum space V. The signer reviews whether the access level of the combiners has reached the security level V. If the access right application has passed, the signer returns $(Q,b_{ID})$ to the designated combiners.

$(\{{\sigma }_k{\}}_{k\in l},\tau )\leftarrow \mathbf{S}\mathbf{i}\mathbf{g}\mathbf{n}(ID,us{k}_{ID},\{v_k{\}}_{k=1}^m,B,Q)$: This step is run by the signer, who splits and augments the packet data, signs the basic vectors, and adds the hierarchical parameter Q and session key B. The basic vector-signature pairs are divided into multiple packets and distributed to each designated combiner.

$\{0,1\}\leftarrow \mathbf{G}\mathbf{r}\mathbf{o}\mathbf{u}\mathbf{p}\mathbf{V}\mathbf{e}\mathbf{r}\mathbf{i}\mathbf{f}\mathbf{y}(\{q_d,b_d{\}}_{d\in t},Q)$: This step is run by a designated group of combiners, and this group uses the CRT to restore the session master key B. If recovery is correct, the algorithm outputs 1; else, the designated combiners terminate the algorithm and output 0.

$\{0,1\}\leftarrow \mathbf{P}\mathbf{a}\mathbf{r}\mathbf{t}\mathbf{i}\mathbf{a}\mathbf{l}\mathbf{V}\mathbf{e}\mathbf{r}\mathbf{i}\mathbf{f}\mathbf{y}(\{{\varsigma }_k{\}}_{l,d})$: This step is run by a designated group of combiners. In this step, the designated group of combiners can use the session master key B obtained from the algorithm GroupVerify to verify the correctness of the signature, thereby verifying the credibility of the signer.

$({\tilde{v}}_d,{\tilde{S}}_d,B^{\prime })\leftarrow \mathbf{C}\mathbf{o}\mathbf{m}\mathbf{b}\mathbf{i}\mathbf{n}\mathbf{e}(\{v_k,{\varsigma }_k,c_k{\}}_{l,d})$: This step is completed independently and run by each combiner. Each combiner can combine their received basic vector-signature pairs to generate secondary vector-signature pairs. Then, each combiner sends the pairs to the receiver.

$\{0,1\}\leftarrow \mathbf{V}\mathbf{e}\mathbf{r}\mathbf{i}\mathbf{f}\mathbf{y}({\tilde{v}}_d,{\tilde{S}}_d)$: After receiving the secondary vector-signature pairs $({\tilde{v}}_1,{\tilde{S}}_1),({\tilde{v}}_2,{\tilde{S}}_2),\dots ,$ sent by the combiners, the receiver can verify the credibility of each combiner through pairing operations.

In our scheme, if any of the first four steps cannot be honestly executed or there are unauthorized combiners in the combiner group, algorithm GroupVerify will output 0, and the dishonest behavior of the signer will result in a return of 0 for the algorithm PartialVerify, while a dishonest operation in any step will make the outputs of algorithm Verify 0. Therefore, our scheme ensures the security of the signature and the designated combination by preventing any malicious behavior of the signer or combiners from passing the verification.

Concrete structure

In our scheme, the combiners need to use the signer’s ID to verify the signature once it has been received. If the received ID is incorrect, the signature cannot pass the verification. Otherwise, each signature scheme will default to make the signer’s ID a part of the signature. Therefore, we can distinguish a specific signer by extracting their ID information from their signature. The overall process of our scheme is shown in Figs. 3 and 4, and the steps are as follows.

• 1.

  System initialization: Setup

  In this step, PKG generates the public parameter params and master private key $msk$ based on the security parameter $\lambda$ and positive integer N (where N is the dimension of the augmented vector). The details are as follows:

  • (a)

    PKG generates three cyclic groups ${\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_{\mathrm{T}}$ with the same prime order $\mathrm{p}(\mathrm{p}>2^{\lambda })$, which satisfies an asymmetric bilinear mapping $\mathrm{e}:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_{\mathrm{T}}$ and $\phi :{\mathbb{G}}_2\to {\mathbb{G}}_1$.

  • (b)

    PKG randomly selects generators $g\in {\mathbb{G}}_1,h\in {\mathbb{G}}_2$ and then randomly selects a value $s\in {\mathbb{Z}}_{\mathrm{p}}^{\ast }$ as $msk$, after which PKG calculates $h^s$ and uses the value as the PKG master public key $mpk$.

  • (c)

    PKG selects four collision-resistant hash functions ${\mathrm{H}}_0:\{0,1{\}}^{\ast }\times {\mathbb{G}}_2\to {\mathbb{Z}}_{\mathrm{p}}^{\ast },{\mathrm{H}}_1:\{0,1{\}}^{\ast }\times {\mathbb{Z}}_N\to {\mathbb{G}}_1,{\mathrm{H}}_2:\{0,1{\}}^{\ast }\times$ ${\mathbb{Z}}_N\times \{0,1{\}}^{\lambda }\times {\mathbb{G}}_2\to {\mathbb{Z}}_{\mathrm{p}},{\mathrm{H}}_3:{\mathbb{Z}}_{\mathrm{p}}^N\times \{0,1{\}}^{\lambda }\to {\mathbb{G}}_1$.

  • (d)

    PKG broadcasts $params:=(\mathrm{p},{\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_{\mathrm{T}},\mathrm{e},g,h,mpk,{\mathrm{H}}_0,{\mathrm{H}}_1,{\mathrm{H}}_2,{\mathrm{H}}_3)$ to the whole network and then secretly remains $msk$.

• 2.

  User registration: KeyExt

  This step is composed of two parts. First, the Signer, Combiners, and Receiver request $us{k}_{ID}$ from PKG. Second, users need to check the correctness of their $us{k}_{ID}$.

  • (a)

    The Signer, Combiners, and Receiver send identity ID to PKG, which randomly selects a value $r\in {\mathbb{Z}}_{\mathrm{p}}^{\ast }$. Calculate $R=h^r$, $x=r+s\cdot {\mathrm{H}}_0(ID,R)$, and send $(x,R)$ as $us{k}_{ID}$ to Signer, Combiners and Receiver through a secure channel.

  • (b)

    The Signer, Combiners, and Receiver check if the equation $\mathrm{e}(g^x,h)=\mathrm{e}(g,R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)})$ holds. If it holds, save $us{k}_{ID}$ locally, otherwise an error log will be created.

• 3.

  Combiners apply for permission: Quest

  In this step, the signer generates the hierarchical parameter Q corresponding to the data and the session key $b_{ID}$ of the approved combiner. The specific process is as follows:

  • (a)

    The signer randomly generates the session master private key $B\in {\mathbb{Z}}_{\mathrm{p}}^{\ast }$ and verifies whether $(ID,q_{ID})$ meets the confidentiality level of this data. If so, the signer generates the session key $b_{ID}=B(mod{q}_{ID})$ of combiners and records the $q_{ID}$.

  • (b)

    When the maximum number of applicants or the deadline for application permission has been reached, the signer calculates $Q:={\prod }_{ID\in list}{q}_{ID}$ and sends $(b_{ID},Q)$ to the corresponding approved Combiners. For the convenience of description, it is assumed that the number of approved combinations is $t$ and that the d^th combination already has $(b_d,Q,q_d),q_{ID}\in {\mathbb{Z}}_{\mathrm{p}}^{\ast })$.

• 4.

  Signature generation: Sign

  This step is divided into two parts. First, the signer splits and augments the data packet. Then, the signer signs the basic vectors and distributes the basic vector-signature pairs to the approved combiners. The specific process is as follows:

  • (a)

    The signer splits the data into m n-dimensional vectors $\{m_k{\}}_{k=1}^m(m_k\in {\mathbb{Z}}_{\mathrm{p}}^n)$ and then augments each $m_k$ to $v_k:=(m_{k1},\dots ,m_{kn},v_{k1},\dots ,v_{km})\in {\mathbb{Z}}_{\mathrm{p}}^N$, where $v_{ki}=1$ holds only in the case of $k=i$, and the value of $v_{ki}$ is always 0 in other cases. Here, we define the tensor space $V:=span(v_1,\dots ,v_m)$.

  • (b)

    The signer assigns the file identifier $f_{id}\in \{0,1{\}}^{\lambda }$ for V, binds the signer information to V using $\tau =(f_{id},R)$, and then signs each basic vector $v_k$ with the signature ${\sigma }_k$, as follows:

    (2) $${\hat{\sigma }}_k=\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_{ki}}\cdot g^{{\sum }_{j=1}^n\mathrm{H}{\mathrm{e}}_2(ID,j,\tau )m_{kj}}$$ (3) $${\sigma }_k={\hat{\sigma }}_k^x\cdot \mathrm{H}{\mathrm{e}}_3(v_k,ID{)}^{BmodQ}.$$

  Then, the signer sends $(\{{\sigma }_k{\}}_l,\tau )$ to the designated combiners, where $l$ represents the basic vector signature index received by the combiners. (For example, if Combiner₁ receives $({\sigma }_1,{\sigma }_2)$, then the index is $l=\{1,2\}$).

• 5.

  Validate the combined population: GroupVerify

  This step is divided into two parts. First, each approved combiner uses the CRT to jointly solve B. Then, we verify the combination group. The specific process is as follows:

  • (a)

    First, each combiner calculates $Q_d=\frac{Q}{q_d}$. Second, we calculate $Q_d^{-1}(Q_d^{-1}\cdot Q_d\equiv 1mod{q}_d)$. Then, we calculate $B_d\equiv b_d{Q}_d^{-1}{Q}_{d}modQ$. Finally, all combiners calculate $B^{\prime }={\sum }_{d=1}^t{B}_{d}modQ$ together.

  • (b)

    Each combiner checks whether $b_d\equiv B^{\prime }mod{q}_d$ is true (i.e., determines whether B′ = B is true). If it is true, there are no malicious combiners in the combiner group. Otherwise, the algorithm terminates.

• 6.

  Partial open verification: PartialVerify

  Owing to the hierarchical protection mechanism of data, open verification can only be carried out within the approved group of combiners in this step, the signer can encrypt signature information using a session key, and no arbitrary combiners can be allowed to verify. The workflow is divided into two parts, as follows:

  • (a)

    Each combiner calculates $\{{\varsigma }_k{\}}_{l,d}=\{{\sigma }_k\cdot {\mathrm{H}}_3(v_k,ID{)}^{-B^{\prime }modQ}{\}}_{l,d}$.

  • (b)

    The signer sends ciphertext to each combiner through broadcasting format. (Only the legal combiners who own the session key can decrypt ciphertext to signature information, others are not able to obtain the user’s information from the ciphertext.) Any combiner can verify whether any $\mathrm{e}({\varsigma }_k,h)=\mathrm{e}({\hat{\sigma }}_k,R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)})$ is valid. If it is true, the signer is trustworthy; otherwise, the algorithm terminates.

• 7.

  Signature aggregation: Combine

  In this step, the combiners first linearly combine the basic vectors and then add the session key. The specific process is as follows:

  • (a)

    Each combiner uses the encoding coefficient $\{c_k{\}}_l$ to perform the following operation on their respective $\{(v_k,{\varsigma }_k){\}}_l$ so that ${\tilde{v}}_d={\sum }_{k\in l}{c}_k{v}_k,{\tilde{\varsigma }}_d={\prod }_{k\in l}{\varsigma }_k^{c_k}$.

  • (b)

    The combiners calculate ${\tilde{S}}_d={\tilde{\varsigma }}_d\cdot {\mathrm{H}}_3({\tilde{v}}_d,ID{)}^{B^{\prime }modQ}$ and send $({\tilde{v}}_d,{\tilde{S}}_d)$ to the receiver through intermediate nodes.

• 8.

  Transaction validation: Verify

  After receiving the combiners’ $({\tilde{v}}_d,{\tilde{S}}_d)$, the receiver first uses B′ to decrypt the signature and then verifies the correctness of the signature. The specific process is as follows:

  • (a)

    The receiver uses B′ to solve for ${\tilde{\varsigma }}_d$ and uses the collected $\{({\tilde{v}}_d,{\tilde{\varsigma }}_d){\}}_t$ to perform a combination calculation to obtain $(data,\varsigma )$, where $\varsigma$ is the signature for $data$.

  • (b)

    The receiver tests whether $\mathrm{e}(\varsigma ,h)=\mathrm{e}(\hat{\sigma },R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)})$ is valid. If it is, the verification has passed. Otherwise, the verification has not passed.

Correctness

In this section, we assume that all participants faithfully execute the above algorithms and that the correctness of the signature can be checked from the following aspects.

Lemma 1. For $(s,mpk)$ pairs generated by Setup, the following conditions must be satisfied:

• 1.

  For $\mathrm{\forall }{\varsigma }_k$, $\mathrm{e}({\varsigma }_k,h)=\mathrm{e}({\hat{\sigma }}_k,R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)})$ is established.

• 2.

  For $\mathrm{\forall }{\tilde{S}}_d$, ${\prod }_{d=1}^t\mathrm{e}({\tilde{S}}_d,h)=\mathrm{e}(\hat{\sigma },R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)})$ is established.

• 3.

  For $\mathrm{\forall }\varsigma$, $\mathrm{e}(\varsigma ,h)=\mathrm{e}(\hat{\sigma },R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)})$ is established.

• 1.

  For the $(v_k,{\varsigma }_k)$ sent by the signer, we can conclude that $\mathrm{e}({\varsigma }_k,h)$ satisfies the relationship mentioned in the previous section. The details are as follows:

  (4) $$\begin{array}{rl}\mathrm{e}({\varsigma }_k,h)& =\mathrm{e}({\sigma }_k\cdot \mathrm{H}{\mathrm{e}}_3(v_k,ID{)}^{-B^{\prime }modQ},h)\\ & =\mathrm{e}({{\hat{\sigma }}_k}^x,h)\\ & =\mathrm{e}({\hat{\sigma }}_k,h^x)\\ & =\mathrm{e}({\hat{\sigma }}_k,h^{r+s\cdot {\mathrm{H}}_0(ID,R)})\\ & =\mathrm{e}({\hat{\sigma }}_k,R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)}).\end{array}$$

• 2.

  For the $({\tilde{v}}_d,{\tilde{S}}_d)$ sent by the above combiners, the receiver first calculates ${\tilde{\varsigma }}_d$ using the CRT, and the expression for the signature $\varsigma$ of data is as follows: (5) $$\begin{array}{rl}\varsigma & =\prod _{d=1}^t{\tilde{\varsigma }}_d\\ & =\prod _{d=1}^t\prod _{k\in l}{{\varsigma }_k}^{c_k}\\ & =\prod _{d=1}^t\prod _{k\in l}{\left(\prod _{i=1}^m{({\mathrm{H}}_1(ID,i{)}^{v_{ki}}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_{kj}})}^x\right)}^{c_k}\\ & =\prod _{d=1}^t\prod _{k\in l}\prod _{i=1}^m{({\mathrm{H}}_1(ID,i{)}^{c_k{v}_{ki}}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )c_k{m}_{kj}})}^x\\ & ={(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j})}^x.\end{array}$$ (6) $$\begin{array}{rl}\prod _{d=1}^t\mathrm{e}({\tilde{S}}_d,h)& =\mathrm{e}(\prod _{d=1}^t{\tilde{S}}_d,h)\\ & =\mathrm{e}(\varsigma ,h)\\ & =\mathrm{e}({(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j})}^x,h)\\ & =\mathrm{e}(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j},h^x)\\ & =\mathrm{e}(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j},h^{r+s\cdot {\mathrm{H}}_0(ID,R)})\\ & =\mathrm{e}(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j},R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)})\\ & =\mathrm{e}(\hat{\sigma },R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)}).\end{array}$$

• 3.

  For the signature $\varsigma$ of the $data$, we can conclude that $e(\varsigma ,h)$ satisfies the relationship mentioned in the previous section. The details are as follows:

  (7) $$\begin{array}{rl}e(\varsigma ,h)& =e({(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j})}^x,h)\\ & =e(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j},h^x)\\ & =e(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j},h^{r+s\cdot H_0(ID,R)})\\ & =e(\prod _{i=1}^m{\mathrm{H}}_1(ID,i{)}^{v_i}\cdot g^{{\sum }_{j=1}^n{\mathrm{H}}_2(ID,j,\tau )m_j},R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)})\\ & =e(\hat{\sigma },R\cdot mp{k}^{{\mathrm{H}}_0(ID,R)}).\end{array}$$

Unforgeability proof

In this section, we prove that the scheme can achieve adaptive selection under the random oracle model for vector subspace, the existence of which is unforgeable under the attack of messages. Here, we use the challenge response mode to prove this. We define the challenger as $chal$, the PPT adversary as $Adv$, and the number of times $Adv$ interrogates the random oracle $i$ as $O_i$.

Initialization. $chal$ let $param{s}^{\prime }=(\mathrm{p},{\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_{\mathrm{T}},\mathrm{e},g,h,mpk,{\mathrm{H}}_3)$, and we define $mpk=Z$, set the map $\phi :{\mathbb{G}}_2\to {\mathbb{G}}_1$.

Query the random oracle. The following seven query algorithms are adaptively selected between $Adv$ and $chal$.

Create Query. The number of times that $Adv$ asks $chal$’s $I{D}_i$ for the value of $R_i$ is recorded as $O_c$, and the number of times that $Adv$ creates a user query for ID as a challenger is recorded as $I(I\in [1,O_c])$. Whenever $Adv$ asks $I{D}_i$ for $R_i$, $chal$ performs the following steps:

• When $i\ne I$, $chal$ randomly chooses ${\alpha }_i,{\beta }_i\in {\mathbb{Z}}_{\mathrm{p}}^{\ast }$, and we define $x_i={\alpha }_i,R_i=h^{x_i}\cdot Z^{-{\beta }_i}$. Then, $chal$ returns $R_i$ to Adv and stores $(I{D}_i,R_i,{\alpha }_i,{\beta }_i)$ into list $l_0$.

• When $i=I$, $chal$ randomly chooses ${\alpha }_i,{\beta }_i\in {\mathbb{Z}}_{\mathrm{p}}^{\ast }$, and we define $x_i=\mathrm{\perp },R_i=h^{{\alpha }_i}$. Then, $chal$ returns $R_i$ to Adv and stores $(I{D}_i,R_i,{\alpha }_i,{\beta }_i)$ into list $l_0$.

Ext Query. Whenever $Adv$ queries $chal$’s $I{D}_i$ for the value of $x_i$, $chal$ performs the following steps:

• When $i\ne I$, $chal$ queries $l_c$ and returns ${\alpha }_i$ to $Adv$.

• When $i=I$, $chal$ terminates the Ext Query algorithm.

${\mathbf{H}}_{\mathbf{0}}$ Query. Whenever $Adv$ queries $(I{D}_i,R_i)$ for the value of ${\mathrm{H}}_0$, $chal$ performs the following steps:

• If $(I{D}_i,R_i)\in l_c$, $chal$ returns ${\beta }_i$ as the value of ${\mathrm{H}}_0(I{D}_i,R_i)$.

• If $(I{D}_i,R_i)\notin l_c$, $chal$ runs the Create Query algorithm and then returns ${\beta }_i$ as the value of ${\mathrm{H}}_0(I{D}_i,R_i)$.

${\mathbf{H}}_{\mathbf{1}}$ Query. Whenever $Adv$ queries $v_k$ for the value of $\{{\mathrm{H}}_1(I{D}_0,i){\}}_{i=1}^m$ for the first time, $chal$ performs the following steps:

• If $I{D}_0\ne I{D}_I$, $chal$ randomly chooses ${\gamma }_1,{\gamma }_2,\dots ,{\gamma }_m\in {\mathbb{G}}_1\mathrm{\backslash }\{1\}$, and returns $\{{\gamma }_i{\}}_{i=1}^m$ as $\{{\mathrm{H}}_1(I{D}_0,i){\}}_{i=1}^m$. Then, $chal$ stores $(I{D}_0,\{i{\}}_{i=1}^m,\{{\mathrm{H}}_1(ID,i){\}}_{i=1}^m)$ into list $l_1$.

• If $I{D}_0=I{D}_I$, $chal$ randomly chooses ${\delta }_1,{ϵ}_1,{\delta }_2,{ϵ}_2,\dots ,{\delta }_m,{ϵ}_m\in {\mathbb{Z}}_{\mathrm{p}}^{\ast }$, calculates $\{g^{{\delta }_i}\cdot \phi (h{)}^{{ϵ}_i}{\}}_{i=1}^m$, and returns it as $\{{\mathrm{H}}_1(I{D}_0,i){\}}_{i=1}^m$. Then, $chal$ stores $(I{D}_0,\{i{\}}_{i=1}^m,\{{\mathrm{H}}_1(ID,i){\}}_{i=1}^m)$ into list $l_1$.

When $Adv$ queries other vectors for the ${\mathrm{H}}_1$ value of $(I{D}_0,\{i{\}}_{i=1}^m)$, $chal$ queries whether $(I{D}_0,\{i{\}}_{i=1}^m)$ is on the list $l_1$. If it is, chal returns $\{{\mathrm{H}}_1(I{D}_0,i){\}}_{i=1}^m$. Otherwise, $chal$ runs the ${\mathbf{H}}_{\mathbf{1}}$ Query algorithm.

${\mathbf{H}}_{\mathbf{2}}$ Query. Whenever $Adv$ queries $v_k$ for the value of $\{{\mathrm{H}}_2(I{D}_0,j,\tau ){\}}_{j=1}^n$, $chal$ randomly chooses ${\zeta }_1$, ${\zeta }_2$, $\dots$, ${\zeta }_n\in {\mathbb{Z}}_{\mathrm{p}}$, and returns $\{{\zeta }_j{\}}_{j=1}^n$ as $\{{\mathrm{H}}_2(I{D}_0,j,\tau ){\}}_{j=1}^n$. Then, it stores $(I{D}_0,\{j{\}}_{j=1}^n,\tau ,\{{\mathrm{H}}_2(I{D}_0,j,\tau ){\}}_{j=1}^n)$ into list $l_2$.

When $Adv$ queries other vectors for the ${\mathrm{H}}_2$ value of $(I{D}_0,\{j{\}}_{j=1}^n,\tau )$, $chal$ queries whether $(I{D}_0,\{j{\}}_{j=1}^n,\tau )$ is on the list $l_2$. If it is, $chal$ returns $\{{\mathrm{H}}_2(I{D}_0,j,\tau ){\}}_{j=1}^n$. Otherwise, $chal$ runs the ${\mathbf{H}}_{\mathbf{2}}$ Query algorithm. Q Query. First, $chal$ randomly chooses $\eta \in {\mathbb{Z}}_{\mathrm{p}}^{\lambda }$, and the number of times $Adv$ asks $chal$’s $I{D}_i$ for the value of $q_i$ is denoted as $O_q$. When $Adv$ runs the $i^{th}$ session key query, if the queried ID is equal to the $chal$’s ID, record this query as the $J^{th}$ query $(J\in [1,O_q])$. Whenever $Adv$ asks $I{D}_i$ for $q_i$, $chal$ performs the following steps:

• If $i\ne J$, $chal$ randomly chooses ${\theta }_i\in {\mathbb{Z}}_{\mathrm{p}}^{\ast }$, and calculates ${\vartheta }_i\equiv \eta mod{\theta }_i$. Then, $chal$ returns $({\theta }_i,{\vartheta }_i)$ as $I{D}_i$’s $(q_i,b_i)$ and stores $(I{D}_i,q_i,b_i)$ into list $l_q$.

• If $i=J$, $chal$ terminates the Q Query algorithm.

Sign Query. When $Adv$ asks for the signature of $I{D}_0$’s basic vectors $v_1,v_2,\dots ,v_m$, $chal$ performs the following steps:

• If $I{D}_0\ne I{D}_I$, $chal$ runs the following steps:

  • -

    $chal$ queries whether $I{D}_0$ is in list $l_1$. If it is, it extracts $\{{\gamma }_i{\}}_{i=1}^m$. Otherwise, $chal$ runs the ${\mathbf{H}}_{\mathbf{1}}$ Query algorithm before extracting.

  • -

    $chal$ queries whether $(I{D}_0,\tau )$ is in list $l_2$. If it is, it extracts $\{{\zeta }_j{\}}_{j=1}^n$. Otherwise, $chal$ runs the ${\mathbf{H}}_{\mathbf{2}}$ Query algorithm before extracting.

  • -

    $chal$ calculates the signature ${\sigma }_k$ of $v_k$ by the equation:

    ${\sigma }_k={({\prod }_{i=1}^m{\gamma }_i^{v_{ki}}\cdot g^{{\sum }_{j=1}^n{\zeta }_j\cdot m_{kj}})}^{x_0}\cdot {\mathrm{H}}_3(v_k,I{D}_0{)}^{\eta mod{\prod }_{i=1}^{O_q}{\theta }_i}$.

  • -

    $chal$ returns $(\tau ,\{{\sigma }_i{\}}_{i=1}^m)$ to $Adv$.

• If $I{D}_0=I{D}_I$, $chal$ runs the following steps:

  • -

    $chal$ queries whether $I{D}_0$ is in list $l_1$. If it is, it extracts $\{g^{{\delta }_i}\cdot \phi (h{)}^{{ϵ}_i}{\}}_{i=1}^m$. Otherwise, $chal$ runs the ${\mathbf{H}}_{\mathbf{1}}$ Query algorithm before extracting.

  • -

    $chal$ queries whether $(I{D}_0,\tau )$ is in list $l_2$. If it is, it extracts $\{{\zeta }_j{\}}_{j=1}^n$. Otherwise, $chal$ runs the ${\mathbf{H}}_{\mathbf{2}}$ Query algorithm before extracting.

  • -

    $chal$ calculates the signature ${\sigma }_k$ of $v_k$, as shown in Eq. (8)

    (8) $$\begin{array}{rl}& ({\prod }_{i=1}^m{(g^{{\delta }_i}\phi {(h)}^{{ϵ}_i})}^{v_{ki}}\cdot g^{{\sum }_{j=1}^n{\zeta }_j\cdot m_{kj}}{)}^{x_I}\\ & \cdot {\mathrm{H}}_3(v_k,I{D}_0{)}^{\eta mod{\prod }_{i=1}^{O_q}{\theta }_i}\\ & =\phi (R_I{)}^{{\sum }_{i=1}^m{ϵ}_i{v}_{ki}}\phi (Z{)}^{{\beta }_0{\sum }_{i=1}^m{ϵ}_i{v}_{ki}}\\ & \cdot {\mathrm{H}}_3(v_k,I{D}_0{)}^{\eta mod{\prod }_{i=1}^{O_q}{\theta }_i}\end{array}$$

  • -

    $chal$ returns $(\tau ,\{{\sigma }_i{\}}_{i=1}^m)$ to $Adv$.