A study on the traceable attribute-based signature scheme provided with anonymous credentials

Abstract

In order to provide the reliability of transmitted data in the era of big data, it is necessary to communicate by applying signature technology to data. There are various signature schemes, among which attribute-based signatures perform signatures based on user attributes. This ensures signer anonymity by allowing users to create and verify signatures without exposing the signer's sensitive information. However, the verifier can verify normally if the attribute period expires and a user without signing authority creates and transmits a signature with the existing signing key and attributes. In addition, signers who abuse anonymity can disclose their signing keys and attributes for some purpose (Money, profit) because there is no risk of being caught. Unauthorized users can use public information to sign and send messages. Therefore, in this paper, we propose a Traceable Attribute-based Signature scheme provided with anonymous credentials. The proposed scheme has the feature of verifying the validity of the signer by using the pseudonym ID included in the user list in the cloud server. In addition, the signer's identity is expressed as an Oblivious Transfer-based pseudonym ID. The signer's identity can be verified through tracing in case of a problem.

Keywords:

• Data security
• cryptography
• attribute-based signature
• anonymity
• traceability

1. Introduction

Using recently developed cloud computing technology, users can securely store and share a lot of data. This gives users many advantages because they can use the cloud to manage and share data in companies or public institutions. However, several security threats exist when sharing data in a cloud environment (Singh & Chatterjee, 2017; Tabrizchi & Kuchaki Rafsanjani, 2020). First, sending data in plaintext can lead to data leakage or loss by attackers. There is even a possibility of data tampering. If the transmitted data is sensitive, such as the user's personal information, it will be a significant security threat.

Therefore, security technology is required to provide reliability of data shared in a cloud environment (Kavin & Ganapathy, 2021; Sun, 2019). Among various security technologies, signature technology is necessary to provide reliability of data. In particular, the ABS(Attribute-based Signature) scheme to protect the privacy of signers is being researched (Ge et al., 2012; Herranz et al., 2012; J. Li et al., 2010; Maji et al., 2011). ABS is a signature scheme that can guarantee the anonymity of each signer because the signature is performed based on the attributes the signer possesses. This attribute-based signature schemes can be used in various environments that require secure communication and anonymous authentication when sharing data in IoT and the cloud (Chen et al., 2023; Su et al., 2022). For example, it can be used to protect the privacy of producers included in the license of software stored on a server that shares OSS (Open-Source Software). Developers can anonymously prove rightful ownership of software by signing software without revealing their identity (Kakvi et al., 2023; Sucasas et al., 2021).

However, several security threats may occur when applying the traditional attribute-based signature (Oberko et al., 2022). First, due to the expiration of the registered attribute, unauthorised signers can create a signature using the existing signing key and attributes. When sending it, the verifier can correctly verify the signed message (Cao et al., 2012; Lian et al., 2013). Second, there are cases of exploiting the anonymity the attribute-based signature scheme provides. Signers who have been issued a signing key can share their signing key and attributes with other users for some purpose (Money, profit) because there is no risk of being caught. Unauthorized signers can sign using shared information (Signing key, attributes) (Ding et al., 2014; Gu et al., 2019; Z. Kang et al., 2023; Wei et al., 2016).

This paper proposes a TABS(Traceable Attribute-based Signature) scheme provided with anonymous credentials. The proposed scheme verifies the validity of the signer through the user list in the cloud server and then blocks the signed message sent by the signer without signing authority. In particular, in the ABS scheme using the existing user attribute revocation list, the signer's anonymity provided by default is broken by registering and using an ID that can identify the signer (Cui et al., 2018; Su et al., 2020; Tate & Vishwanathan, 2015).

In this proposed scheme, since the signer's identity is registered with a pseudonym ID obtained based on OT(Oblivious Transfer), anonymity excluded from existing revocable ABS schemes can be provided. In detail, the proposed scheme has the following contributions.

• Provide signer anonymity: In the existing ABS scheme, an ID value that can identify the signer is registered and used with AA in order to provide revocation of the signer's attributes. Therefore, the anonymity provided by default in ABS was excluded. However, in the proposed scheme, the signer's identity is registered with a pseudonym ID obtained based on OT to provide anonymity excluded from the existing revocable ABS scheme (Garcia-Grau et al., 2022).

• Block signatures from unauthorised signers: A problem arises when a signature can be created using the existing signing key and attributes even if the signer has expired or withdrawn the attribute. If the signature generated through the cloud is sent to the verifier, the verifier can verify the signature without a problem. This problem occurs because there is no user authentication process using attribute-based security technology (Cryptography, signature). In this proposed scheme, a value that verifies the validity of the signer is included in the signature based on the pseudonym value issued to the signer. With the verification value, the cloud server verifies the validity of the signer who sent the signature and determines whether the signature is stored.

• Traceability to prove the signer identity: In the proposed scheme, if the message obtained after signature verification is unclear or incorrect, the verifier can request the identity of the signer who sent the signature to AA. In this case, AA (Attribute Authority) and TA (Trace Authority) cooperate to trace the signer who performed the signature and verify the identity. Here, the signer who performed the signature is the user who performed the signature with the signing key issued by AA, and only the originally registered signer can perform the signature. Research contents related to transfer or delegation to other users are not included. If there is a problem with a message that has been signed and transmitted, the signer who performed the signature can be traced and identified at any time to hold accountability. This can prevent the registered signer from leaking the attributes or signing keys to other users in advance.

Each chapter of this paper is as follows. In Chapter 2, as the background of this paper, the contents of ABS, the security threats that occur, and existing researched ABS schemes are explained. Chapter 3 describes the security requirements for data sharing using ABS in a cloud environment, and Chapter 4 describes the proposed scheme. Chapter 5 explains the proposed scheme's security and performance (Amount of operation) and concludes in Chapter 6.

2. Background

This chapter describes the ABS scheme. In addition, the security threats that occur when using the ABS scheme and the solutions to solve them. It also describes the existing researched ABS schemes.

2.1. ABS(Attribute-based signature)

Attribute-based signature is a cryptographic technique in which a signer creates an access structure (γ) based on their attributes and signs or verifies messages based on it. The access structure used in attribute-based signature is similar to the access structure and function used in attribute-based encryption. A detailed description of the γ is provided in Appendix 2. In general, ${\gamma }_A$ means the access structure generated by the signer's A(Attribute set), and “V A” means the set of attributes held by the verifier. In this case, the intersection of A and the input attribute set (the verifier's V A(Attribute set)) is ${\gamma }_A(VA)=1$, then it satisfies ${\gamma }_A$.

Figure 1 shows the ABS scheme structure, which consists of three participants: AA, signer, and verifier. Generate γ with the attributes of the signer {Company A, Team B, Director}, sign the message and send it to the verifier. The verifier verifies the signed message. The verifier can now know that the signed message came from the signer with attributes {Company A, Team B, Director}, even though it is unclear who signed it.

Figure 1. Attribute-based signature structure.

Therefore, the privacy of the signer can be protected in a cloud environment where OSS can be shared because credentials can be properly asserted while uploading messages anonymously. In addition, it is used as a solution in environments where security problems may occur due to identity exposure during communication and authentication processes in IoT-Cloud environments such as VANET(Vehicular Ad-hoc Network) or smart grid.

This research analyses the security requirements by researching the existing ABS schemes. Based on the analysed data, it will provide requirements for the signer's anonymity, block signatures from unauthorised signers, and signer traceability for proof of identity.

2.2. Potential security threats from ABS schemes

There are two potential security threats to attribute-based signatures. First, there is a security threat in which an unauthorised signer can create and transmit a signature with the existing signing key and attributes. Second, a registered signer could leak the signing key and attributes for their benefit. At this time, a security threat may occur in which a third party can perform a signature with it. A detailed description of each security threat is as follows Oberko et al. (2022).

2.2.1. Security threats possible by unauthorized signers

In the existing ABS scheme, a withdrawal request must be submitted to the AA when a signer withdraws or the signature period expires. AA must ensure that signers with expired authority can no longer create signatures. Figure 2 shows that if a signer without signing authority creates and transmits a signature with the existing signing key and attributes, the verifier can verify it normally. When the verification is completed, the verifier can know that the signature came from the signer with the existing attributes {Company A, Team B, Director} (Cao et al., 2012; Lian et al., 2013). This is because the signer's requirement for revocation upon expiry of authority is not properly considered.

Figure 2. Security threats possible by unauthorised signers.

In the Li et al. scheme, which is the initial ABS scheme, the signer received a signing key($D_i=(d_{i0}=g_2^{q(i)})\cdot H_1(i{)}^{r_i},d_{i1}=g^{r_i})$ suitable for attributes such as $i\in w$ (Attributes set) from AA. The parameters in the signing key are the parameters included in the initial ABS signing key. Since the parameter symbols are different in each paper, please refer to the paper for an explanation of the equation. The attributes are then used to create an access structure(γ). When the signed message $\sigma =({\sigma }_0,\{{\sigma }_i{\}}_{i\in w^{\ast }\cup {\mathrm{\Omega }}^{\mathrm{\prime }}},{\sigma }_0^{\mathrm{\prime }})$ is sent to the verifier, the verifier verifies it J. Li et al. (2010). Among the signature parameters, $\{{\sigma }_i{\}}_{i\in w^{\ast }\cup {\mathrm{\Omega }}^{\mathrm{\prime }}}$ refers to the signature value including the attribute value. However, suppose the signer does not consider the AA requirement to revocation registration when the authority expires. In that case, the message can be continuously signed with the signer's existing signing key attribute value and access structure(γ). The signed message will be verified normally, and it can be known that it came from the signer with the attributes included in the signature. That is, when the signer's authority expires in the ABS, a scheme for revoking the signer's attributes in the AA is required. When a signer's signing authority expires, they must not be able to create a signature with their existing attributes and signing key. Even if a signature is generated and sent to a cloud server or verifier, the signature cannot be normally verified. Therefore, when designing the attribute-based signature scheme, it is necessary to consider the mechanism for the revocation problem in a dynamic cloud environment where signer registration and withdrawal occur frequently (Cui et al., 2018; Su et al., 2020; Tate & Vishwanathan, 2015).

Existing RABS(Revocable Attribute-based Signatures) schemes proposed considering the revocation problem register an ID that can identify a signer in AA. Based on it, a revocation list was used to prevent signers whose authority has expired from signing (Tan et al., 2022). Representatively, there are the Su et al. scheme and the Wei et al. scheme, which are described in Section 2.3. However, in the RABS schemes, AA can verify and infer who sent what signed message by verifying the signer for which the signing key was issued or the signature being communicated. In other words, since the privacy of the signer is not protected, a solution for this is required.

2.2.2. Security threats that occur when signing key and attributes are leaked

If the message is unclear or incorrect after verifying the signed message by the verifier, the signer's information and identity must be verified. However, since the signer's access structure included in the signature value is composed of attributes, the signer's attribute information can be known, but the identity cannot be verified. In other words, verification is normally performed even if exploiting the attribute-based signature using the leaked signing key, and the attribute value is performed as shown in Figure 3. At this time, the signer's identity cannot be traced and verified. Therefore, signers who abuse it can leak the signing key and attributes for their benefit. Cases of abuse mean, for example, when an authorised user publicly sells or leaks a signing key through an e-commerce platform. With this, third parties can sign with the leaked signer's attributes, so solutions are needed (Ding et al., 2014; Gu et al., 2019; Wei et al., 2016; Zhang & Chen, 2023).

Figure 3. Security threats that occur when signing key and attributes are leaked.

To solve this problem, TABS schemes can verify the identity by tracing the real ID of the signer. In detail, the ID is registered in AA during initial registration and included in the signing key. Compared to the existing ABS scheme, AA manages the signer's identity and has information about who has been issued which signing key. After verifying the signature, if the obtained message is unclear to the verifier, the verifier can request the identity of the signer who sent the signed message to AA. The AA can verify the identity of the issued signer through the signer ID of the signing key included in the signature and hold him accountable (Ding et al., 2014; Gu et al., 2019; Wei et al., 2016; Zhang & Chen, 2023). The malicious signer who leaked the signing key and attributes in the middle cannot be caught, but the signer who first issued and leaked it from AA can be traced and identified. Representatively, there are Wei et al. scheme and Gu et al. scheme, which are described in Section 2.3. However, since this also uses an ID that can identify the signer, the signer's anonymity provided by the existing ABS is excluded. Therefore, anonymity must be provided for the privacy of signers, and research on ABS that can be traced if necessary is required.

2.3. Existing ABS schemes

In 2010, Li et al. scheme published a paper on introducing and applying the first attribute-based signature scheme. Based on this paper, detailed research on the attribute-based signature scheme was published by Maji et al. scheme in 2011 (J. Li et al., 2010; Maji et al., 2011). Since then, research on ABS schemes that reflect the requirements that can be provided by applying the ABS scheme to various environments has been continuously conducted. Section 2.3 describes the ABS schemes researched, focussing on signer anonymity, unauthorised signer blocking, and traceability for signer identification among various ABS schemes.

The Cui et al. scheme and the Su et al. scheme are ABS schemes in which a signer without signing authority cannot create a signature, and both ABS schemes use a user revocation list. In the Cui et al. scheme, the signer requests a partial signature from the server when generating a signature. At this time, the server performs partial signing after verifying that the signer has expired. Therefore, the signer cannot sign after the expiry period “t” (Cui et al., 2018). The Su et al. scheme is similar to the Cui et al. scheme. When the signing authority of the signer expires, the Revoke phase is performed. Here, the node value “θ” is created with the signer's ID, expiration period “t”, and “st” indicating the signer's status, and it is registered in the revocation list. Then, create a signing key that can be signed with the update key in the initially generated secret key. The signing key now includes “θ” registered in the revocation list and the expiration period “t”. Therefore, if the signer's signature authority period “t” expires, the signing key cannot be used, and the message cannot be signed (Su et al., 2020). The problem that occurs when an unauthorised signer sends a signature is solved.

However, the two ABS schemes use an ID that can identify the signer for attribute revocation, thereby eliminating the issue of protecting the signer's privacy provided in the existing ABS. Also, if there is a problem with the message verified by the verifier, the signer who sent the signed message cannot be traced. In particular, since it does not consider security threats caused by leakers (Signers) for profit, a solution for this is needed.

The Wei et al. scheme and the Gu et al. scheme are ABS schemes that include a requirement to track and verify the real identity of the signer. This can verify the identity by tracking the signer who first leaked the signing key, which is the requirement mentioned above (Gu et al., 2019; Wei et al., 2016). The key can be leaked because only the attributes of the issued user are included in the encryption key or the signing key in the details of attribute-based cryptography. It still does not contain any identifiable value. This provides a disadvantage in that the signer who has been issued the signing key cannot be traced when a problem occurs in the future. Therefore, the user can exploit this to leak the key anytime for their benefit.

Regarding the requirement to block signatures from unauthorised signers, the Wei et al. scheme is similar to the Cui et al. scheme and the Su et al. scheme. It uses an $RL(Revocationlist)$ and the signer's ID and attribute values as input when extracting the initial signing key. Then, the initial signing key is updated with “t”, the expiration period of the signer registered in the RL, $PP(Publicparameter)$, $MSK(Masterkey)$, RL, and “st” indicating the signer's status (Registration or revocation). Then, create a signature with it. If the signer's authority expires, the $Revoke(ID,t)$ phase is performed to prevent the signing key of the signer whose authority has expired from being updated (Wei et al., 2016). Then, if identity is required by tracing the signer, the $Trace(PP,TK,\sigma )$ phase is performed. In detail, with the initially issued TK = q value and the signature value of $\sigma =({\sigma }_0,{\sigma }_0^{\mathrm{\prime }},{\sigma }_1,{\sigma }_2,{\sigma }_3,\{c_i,{\pi }_i{\}}_{i=1}^{l_1})$, the signer's ID is extracted through the following equation($c_i=u_i^{ID[i]}\cdot h^{v_i},ID[i]=(0if(c_i{)}^q=1$ OR 1 otherwise.) (Wei et al., 2016).

The Gu et al. scheme is similar to the Wei et al. scheme. AA performs the $Trace(PK,A,M,\gamma ,\sigma )$ phase if traceability is required to verify the signer's identity. Then, the real identity of the signer included in the signature is tracked and verified. However, the Gu et al. scheme does not consider the requirement for signers whose authority has expired. Therefore, the signer can sign the message with the existing signing key and attribute value even if the authority expires. A solution is needed because the verifier normally verifies the signed message. Wei et al. scheme and the Gu et al. scheme provided traceability by including an ID in the signing key that could verify the identity of the issued signer. However, by registering the signer's ID in AA, the problem of protecting the signer's privacy provided in the existing ABS scheme is excluded. In addition, if the information registered in AA (Signer's real ID, signing key, etc.) is leaked by an attacker or malicious user, secondary security threats such as leakage of sensitive data and signature forgery may occur. Therefore, it is necessary to minimise signer information even for AAs that manage attributes and generate keys.

The amount of operation related to sign and verification in ABS schemes is proportional to the number of attributes the signer selects. That is, the operation amount varies depending on the number of attributes. Regarding the amount of operation, the Su et al. scheme and the Gu et al. scheme are proportional to the number of attributes, and the efficiency aspect of reducing the amount of operation is not considered. However, Wei et al. scheme was researched so that the number of attributes does not affect the amount of operation in the verification phases. This is research to increase the efficiency of verification operations compared to the existing ABS scheme and is a direction for future research (Ma & Du, 2022). The efficiency aspect should not be considered in this paper.

This proposed scheme analyses ABS schemes that focus on the requirements mentioned above. Based on the researched contents, we propose an ABS scheme that satisfies the requirements of the anonymity of signers, the block of signatures from unauthorised signers, and signer traceability for proof of identity. In particular, the OT-based pseudonym acquisition protocol will be analysed and applied to the ABS scheme to provide the signer's anonymity.

2.4. Pseudonym acquisition protocol using OT

OT(Oblivious Transfer) is a protocol in which a sender transmits one of potentially many pieces of information to a receiver but does not know which part is being transferred (Yadav et al., 2022). OT protocols have been developed into various techniques, such as One-of-n OT and m-of-n OT, starting with One-of-two OT (Yadav et al., 2022). This provides user anonymity in the pseudonym acquisition protocol or data access control part (Fu et al., 2016; Han et al., 2012; J. N. Kang et al., 2009; Koblitz, 2010; Liu et al., 2018; Nyang & Lee, 2006; Xu & Zhang, 2010). The OT protocol to be applied to the thesis is One-of-n OT, and a detailed description is indicated in Appendix 3.

Figure 4 shows the One-of-n OT-based pseudonym acquisition protocol proposed in 2009 (Nyang & Lee, 2006). A pseudonym acquisition protocol using OT generally involves a judicial authority, a service provider, and a user. To apply this scheme in the cloud environment of this proposed scheme, the judgment agency is replaced with TA, and the service provider is replaced with AA. The user authenticates with the TA and AA with real names and creates a secure channel. Subsequent communication takes place over this secure channel. After real name authentication is completed, the TA selects “n indexes” of the pseudonym the service provider possesses and transmits them to the user. The user receives a pseudonym corresponding to the “n indexes” and an authentication key pair of the pseudonym from the service provider through the OT protocol. After that, the user returns the index and temporarily encrypts the authentication key of the pseudonym sent to the TA. The TA requests the remaining encryption secret keys from the user and decrypts the pseudonym authentication keys by obtaining them. The TA transmits these values together with the index to the service provider, and the service provider informs the TA of the result after checking whether the authentication key of the pseudonym is correct. If all are correct, the TA sends an OK message to the user, and the user uses the one remaining pseudonym.

Figure 4. OT-based pseudonym acquisition phases.

3. Security requirements

Since the ABS scheme performs signatures based on the attributes of the signer and verifier and shares data, the signer's anonymity is basically provided. A secure ABS scheme should provide integrity of shared data and should not verify even if an unauthorised user signs. In addition, there are various requirements, such as efficiency in the ABS scheme, attribute cancellation of users who have withdrawn, multiple AAs for secure user attribute management, and efficient signed message search. The ABS scheme is ideal as it can meet all requirements. However, as the requirements are applied, the ABS scheme becomes heavy and inefficient. Therefore, research is needed to apply the requirements suitable for the environment. The ABS scheme proposed in this paper aims to provide the following requirements.

• Provide signer anonymity: Anonymity must be provided between AAs, cloud servers, signers and users participating in the ABS. However, since ABS provides anonymity, multiple security threats can occur when abused, and at this time, the signer cannot be traced. To solve this problem, the AA registers the signer's ID and performs the signature. In this case, the anonymity part that can protect the signer's privacy is excluded from the existing ABS schemes. Therefore, there is a need for ABS research that provides adequate anonymity and traceability.

• Block signatures from unauthorised signers: The problem is that if the signer signs with the existing signing key and attributes and sends it to the verifier through the cloud, the verifier can verify it without problems. A signer whose signing authority has expired must be prevented from generating a signature. Even if an expired signer creates and transmits a signature, the cloud server or verifier should not be able to verify the signed message. One solution is to include a value that can verify the validity of the signer who sent the signature in the signed message. Therefore, when a signed message is received in the future, it is necessary to research the ABS scheme that can determine whether or not the signed message is stored according to the validity of the signer.

• Traceability to prove the signer identity: In ABS, there are cases in which signing keys and attributes are shared with other users for their benefit. This occurs because when a signing key is issued, values that can verify the identity of the signer to be issued are not included. Therefore, research is needed to include a value that can trace the signer in the signing key. This allows the user to request the identity of the signer who sent the signed message to AA if the message is unclear or problematic after verifying the signed message. If the identity of the signer who has been issued the signing key is verified through AA, even if the signer who leaked the signing key cannot be traced in the middle, the identity of the signer who first leaked the signing key can be verified.

4. The TABS proposed scheme

The proposed scheme is a study on the TABS scheme provided with anonymous credentials. Table 1 shows the system parameters used in the proposed scheme. In this proposed scheme, the signer's identity uses an OT-based pseudonym ID, which provides the signer's anonymity. Moreover, because the cloud server can validate signers through its user revocation list, it can block signatures from unauthorised signers. Finally, verifiers can ask the AA for the identity of the signer who sent the signed message if the verified, signed message is unclear. The AA can work with the TA to verify the identity of the signer or attribute leaker who sent the signed message.

Table 1. System parameter notation of the proposed scheme.

Symbol	Definition
PP, MK, PK	Public parameter, Master key, AA's public key
PIL, PIDL	Pseudonym index List, Pseudonym ID List
AK, SK	Authentication key, Signing key
RID	Real ID (In general, it means the real ID of the signer)
PID	Pseudonym ID (In general, it means the pseudonym ID of the signer)
PIDcert	A pseudonym certificate that can verify the validity of the signer
PTR	A value that can track the pseudonym ID of the signer
$At{t}_i,A$	Attribute data of user's (“i” is the number of attributes, $i\in [1,n]$), Attribute set
σ	Signature generated by the signer
t	Signature authority period (from registration period to expiration)
γ	Access structure
SS	Parameter value generated after signature verification
$H(\cdot )$	Cryptographic hash function

4.1. System model

Figure 5 shows the overall scenario of the proposed scheme, in which TA, AA, cloud server, signer, and verifier participate in the communication. There may be multiple signers depending on the environment. The proposed scheme is explained by configuring a single signer as shown in Figure 5. AA and TA communicate-based on secure channels when communicating with signers and verifiers. In detail, communication based on a secure channel is indicated by a solid line, and a dotted line indicates an insecure channel. The roles of each object in this proposed scheme are as follows.

Figure 5. Overall scenario of the proposed scheme.

• TA (Trace Authority): The TA is the central server that manages the real identity of the signer, and it is a single trusted server. It has $PIL=\{v_1,v_2,\dots ,v_n\}$ through the index pool. When a signer requests a pseudonym index, it uses an OT-based pseudonym acquisition protocol together with AA to issue a pseudonym to the signer. In the future, when the AA requests the identity of the signer's RID mapped to the PID for the signer who wants to reveal its identity, it can cooperate to verify the real identity mapped to the PID.

• AA (Attribute Authority): AA is a single server that manages user attributes, and there are cases where multiple AA exist considering key escrow issues and requirements for a single server failure point (Y. Li et al., 2020). This proposed scheme does not deal with key escrow problems and single server failure points and defines a single server that manages user attributes. In the existing RABS scheme, because the signer's ID is registered in AA, it is possible to know who signer performed the signature, so there are cases where AA is semi-trusted. Since the signer's anonymity is excluded, the AA server must also provide anonymity depending on whether the signer's privacy is protected. In this proposed scheme, a pseudonym ID is used. In detail, AA has a PID, such as $(PI{D}_1,u_1),(PI{D}_2,u_2),\dots ,(PI{D}_n,u_n)$ in the pseudonym pool, and plays the role of issuing the pseudonym of the signer with the TA. Sets the PP for ABS and generates a signing key with the signer's PID and attribute values when the signer requests an SK. In addition, it plays a role in transmitting the PP necessary for ABS to the signer, verifier, and cloud server. Also, when the signer's authority expires, the signer is registered as a revoked signer due to the expiration period “t” of the registered user list.

• Cloud server: A cloud server typically acts as a storage that receives data from multiple signers and stores it. In the proposed scheme, the cloud server validates the signer so that unauthorised signers cannot store the signature. Performs signer validation, which determines whether to save the signed message.

• Signer(Data owner): The signer is the user who signs the message and is responsible for sending the signed message. The signer creates an access structure with his attributes. Here, the role of the access structure (γ) is that the verifier knows the attributes of the signer through the access structure when verifying the signed message in the future. The signer signs the message with the SK received from AA and sends it to the cloud server.

• Verifier(User): A verifier is a user who receives signed messages and performs verification. The verifier requests and receives signed messages to be verified by the cloud server and then verifies the signed messages. If the verification is successful, the integrity of the signer's attribute information and data can be verified.

4.2. Assumptions of the proposed TABS scheme

The preliminaries of this proposed scheme are shown in Appendix 1. In detail, G and $G_T$ two multiplicative cycle groups of the prime order p, g are generators of G. Let e:$G\times G\to G_T$ be a bilinear map. Assume that there are n attributes in the universe where the universal set is $A=\{At{t}_1,At{t}_2,At{t}_3,\dots ,At{t}_n\}$. Attribute $At{t}_i$ is included in attribute A so that can be represented as $At{t}_i\in [A]$. Furthermore, this proposed scheme assumes that if the signer's authorisation expires, the AA registers the signer's information (PID, D, t) as a revoked signer. Therefore, a signer whose authorisation has expired cannot send signed messages.

4.3. Detailed protocol of the proposed scheme

This proposed scheme is a TABS scheme provided with anonymous credentials. Compared to the earlier ABS scheme, Initial User Registration, Signer Validation, and Tracing of Identity Proof phases have been added. This proposed scheme consists of a total of 7 phases.

• Initial User Registration phase: The signer sends the RID to the TA. A PID is issued from the TA and AA through the OT-based pseudonym acquisition protocol. At this time, communication between AA, TA, and signer is communicated through a secure channel.

• Setup phase: It is performed in AA and enters the security parameters to generate PP, MK, PK.

• Key Generation phase: When a signer requests a registration and signing key from AA, The AA generates SK for the attribute value using the signer A(Attribute set) and PP, MK, PID. The SK includes a PSK that can verify the validity of the signer who has been issued the SK and PTR, a value required to verify the identity. AA transmits PP, SK to the signer and PP to the verifier and shares the information (PID, D, t) of the signer registered in the user revocation list to the cloud server.

• Sign phase: The signer creates an γ with his attributes and signs the message (σ, M) with PP and SK. It then sends it to the cloud server.

• Signer Validation phase: The cloud server verifies the validity of the signer through verification of PIDcert in the user list and signature(σ) and determines whether the signed message is stored.

• Verification phase: The user requests and receives a signed message from the cloud server. Then verify the message signed with PP, M, σ, γ. If verified successfully the user knows that the message was sent by a signer with the attribute A.

• Tracing of Identity Proof phase: This phase consists of two phases: Tracing of PID and Tracing of the identity proof. If the verified message is unclear or incorrect, the user must trace and verify the signer's identity who sent the signed message to the AA. When AA requests the signer's identity, AA performs the Tracing of the PID phase to verify PIDcert in the signature and derives the signer's PID through operations. And cooperate with the TA to verify the RID of the signer that is mapped to the PID through the Tracing of the identity proof phase.

4.3.1. Initial user registration

The signer communicates with the TA and AA before signing to receive the pseudonym value. We have the signer initially register and receive the PID using the OT-based pseudonym acquisition protocol. In detail, the signer registers by sending a RID to the TA and receives $PIL(L=\{v_1,v_2,\dots ,v_n\})$ that is not currently in use. If a $PIDL((PI{D}_1,u_1),(PI{D}_2,u_2),\dots ,(PI{D}_n,u_n))$ mapped to the value “v” based on the PIL is requested from AA, it is transmitted using the OT protocol. Then, part of the received information $((v_1,C{T}_1),(v_2,C{T}_2),\dots ,(v_n,C{T}_n))$ is sent to the TA. $C{T}_n$ indicates that the signer selected the symmetric key $(b_n)$ and encrypted $u_n$. The TA randomly selects an n−1 index from the received information. They have usually selected one. And mark the selected index as “i”. A decryption key is requested from the user to decrypt the selected index. As a result, $(n-1)$ “u” values are obtained, such as $((v_1,u_1),(v_2,u_2),\dots ,(v_{i-1},u_{i-1}),(v_{i+1},u_{i+1}),\dots ,(v_n,u_n))$. The list of decrypted values is shared with AA to check the validity of the index value and AK. When the verification is completed, the TA can use the $PI{D}_i$ mapped to the selected value of $v_i$. The signer requests and receives an SK from AA with a PID and performs an ABS.

4.3.2. Setup phase

A setup phase is performed in AA to create PP, MK, and PK. The AA generates random values of $t{x}_i\in G$, $\alpha \in Z_p^{\ast }$ and computes it to generate PP. Then, the generated random values are generated by operating $T{X}_i=g^{t{x}_i}$, $ha=g^{\alpha }$ and $PK=\alpha \cdot P$. The PK is used to verify the validity of the signer. The Equations (1(1) $\begin{array}{rl}PP& =⟨e,g,G,G_T,T{X}_i,ha,H⟩\end{array}$(1) ) and (2(2) $\begin{array}{rl}MK& =⟨\alpha ,\{t{x}_i{\}}_{i\in [1,n]}⟩,PK=⟨\alpha \cdot P⟩\end{array}$(2) ) to generate the PP, MK and PK are as follows.

• Random values $t{x}_i\in G$, $\alpha \in Z_p^{\ast }$.

• Computes random values {$T{X}_i=g^{t{x}_i}{\}}_{i\in [1,n]}$, $ha=g^{\alpha }$ and $PK=\alpha \cdot P$.

(1) $\begin{array}{rl}PP& =⟨e,g,G,G_T,T{X}_i,ha,H⟩\end{array}$(1) (2) $\begin{array}{rl}MK& =⟨\alpha ,\{t{x}_i{\}}_{i\in [1,n]}⟩,PK=⟨\alpha \cdot P⟩\end{array}$(2)

4.3.3. Key generation phase

The signer requests registration with a PID from AA and requests an SK corresponding to an attribute. AA performs the key generation algorithm. A random value of $s\in Z_p^{\ast }$ is required for verifying the signer's identity random values of $r_i\in Z_p^{\ast }$ are required for key generation, and a random value of $d\in Z_p^{\ast }$ is required to validate the signer is generated. Then, the generated random values are generated by operating $r=\sum _{i=1}^n{r}_i$ and $D=d\cdot P$. In addition, $K,\{K_i^{\mathrm{\prime }},K_i^{{}^{″}}{\}}_{(At{t}_i\in [A])}$, PSK, PTR are generated with Equations (3(3) $\begin{array}{rl}& K=g^{\alpha -r},K_i^{\mathrm{\prime }}=g^{r_i}\cdot H(At{t}_i{)}^{r_i},K_i^{{}^{″}}=H(At{t}_i{)}^{\frac{r_i}{t{x}_i}}\end{array}$(3) )–5(5) $\begin{array}{rl}& PTR=PID\oplus PSK\oplus S\end{array}$(5) to generate a key and prove the signer's validity. A corresponding SK is generated based on the signer's attributes and PID. The SK contains “t” the period the signer can sign.

• Random values $s\in Z_p^{\ast },\{r_i\in Z_p^{\ast }{\}}_{(I\in [1,n])},d\in Z_p^{\ast }$.

• Computes random values $r=\sum _{i=1}^n{r}_i,D=d\cdot P$.

(3) $\begin{array}{rl}& K=g^{\alpha -r},K_i^{\mathrm{\prime }}=g^{r_i}\cdot H(At{t}_i{)}^{r_i},K_i^{{}^{″}}=H(At{t}_i{)}^{\frac{r_i}{t{x}_i}}\end{array}$(3) (4) $\begin{array}{rl}& PSK=d+H(PID,D)\cdot \alpha \end{array}$(4) (5) $\begin{array}{rl}& PTR=PID\oplus PSK\oplus S\end{array}$(5) (6) $\begin{array}{rl}& SK=\{PSK,PTR,K,\{K_i^{\mathrm{\prime }},K_i^{{}^{″}}{\}}_{(At{t}_i\in [A])},t\}\end{array}$(6) When the SK is generated PP and SK are sent to the signer, and PP is sent to the verifier. Furthermore, it shares the signer's information (PID, D, t) with the cloud server.

4.3.4. Sign phase

In this phase, the signer signs the message and transmits it to the cloud server. The signer creates an access structure ${\gamma }_A$ based on its attributes. Verifiers use ${\gamma }_A$ to know the attributes of the signer who sent the signed message when verifying the signed message later. Generate the random value o, $o^{\mathrm{\prime }}\in Z_p^{\ast }$, required for the signature and calculate it to generate the required value ($V,f,VM,R,\{R_i^{\mathrm{\prime }},R_i^{{}^{″}}\}$). Verify using Equations (7(7) $\begin{array}{rl}& V=e(f,g^{o^{\mathrm{\prime }}}),VM=H(M,V)\end{array}$(7) ) to (9(9) $\begin{array}{rl}& PIDcert=PSK+o\cdot H(PID,O,t)\end{array}$(9) ). The verifier can verify the integrity of the message through the V M later. Using the PSK received from AA, create a PIDcert that can verify the validity of the signer. The “M” is selected, and the message is signed by operating PP, SK and ${\gamma }_A$ as shown in Equation (10(10) $\begin{array}{rl}& \sigma =⟨{\gamma }_A,M,PIDcert,PTR,V,f,VM,R,\{R_i^{\mathrm{\prime }},R_i^{{}^{″}}\}⟩\end{array}$(10) ), and the signed message ($\sigma ,M$) is transmitted to the cloud server.

• Random values o, $o^{\mathrm{\prime }}\in Z_p^{\ast },f=g^o,O=o\cdot P$.

(7) $\begin{array}{rl}& V=e(f,g^{o^{\mathrm{\prime }}}),VM=H(M,V)\end{array}$(7) (8) $\begin{array}{rl}& R=g^{o^{\mathrm{\prime }}}\cdot K,R_i^{\mathrm{\prime }}=(K_i{)}^o\cdot T{X}_i,R_i^{{}^{″}}=(K_i^{{}^{″}}{)}^o\cdot T{X}_i\end{array}$(8) (9) $\begin{array}{rl}& PIDcert=PSK+o\cdot H(PID,O,t)\end{array}$(9) (10) $\begin{array}{rl}& \sigma =⟨{\gamma }_A,M,PIDcert,PTR,V,f,VM,R,\{R_i^{\mathrm{\prime }},R_i^{{}^{″}}\}⟩\end{array}$(10)

4.3.5. Signer validation phase

The cloud server verifies the user revocation list and the PIDcert of the received signature and verifies the validity of the signer, as shown in Equation (11(11) $\begin{array}{rl}PIDcert\cdot P& \stackrel{?}{=}D+H(PID,D)\cdot PK+H(PID,O,t)\cdot O\end{array}$(11) ). The Equation (12(12) $\begin{array}{rl}PIDcert\cdot P& \stackrel{?}{=}PSK\cdot P+o\cdot H(PID,O,t)\cdot P\\ & =(d+H(PID,D)\cdot \alpha )\cdot P+H(PID,O,t)\cdot o\cdot P\\ & =d\cdot P+H(PID,D)\cdot \alpha \cdot P+H(PID,O,t)\cdot O\\ & =D+H(PID,D)\cdot PK+H(PID,O,t)\cdot O\end{array}$(12) ) is a verification of Equation (11(11) $\begin{array}{rl}PIDcert\cdot P& \stackrel{?}{=}D+H(PID,D)\cdot PK+H(PID,O,t)\cdot O\end{array}$(11) ). Depending on the verification results, the signed message sent by the signer is stored. (11) $\begin{array}{rl}PIDcert\cdot P& \stackrel{?}{=}D+H(PID,D)\cdot PK+H(PID,O,t)\cdot O\end{array}$(11) (12) $\begin{array}{rl}PIDcert\cdot P& \stackrel{?}{=}PSK\cdot P+o\cdot H(PID,O,t)\cdot P\\ & =(d+H(PID,D)\cdot \alpha )\cdot P+H(PID,O,t)\cdot o\cdot P\\ & =d\cdot P+H(PID,D)\cdot \alpha \cdot P+H(PID,O,t)\cdot O\\ & =D+H(PID,D)\cdot PK+H(PID,O,t)\cdot O\end{array}$(12)

4.3.6. Verification phase

The verifier requests the signed message to be verified from the cloud server. After searching for the signed message requested by the user, the cloud server sends it to the user, and the user performs a verification phase. At the time of verification, it is compared whether it is $\gamma (At{t}_i)=1$, and if satisfied, the verification phase is performed as shown in Equation (13(13) $\begin{array}{rl}SS& =\frac{\prod _{i\in A}e(R_i^{\mathrm{\prime }},g)}{\prod _{i\in A}e(T{X}_i,R_i^{{}^{″}})}=\frac{\prod _{i\in A}e(g^{r_i\cdot o}\cdot H(At{t}_i{)}^{r_i\cdot o}\cdot g^{t{x}_i},g)}{\prod _{i\in A}e(g^{t{X}_i},(H(At{t}_i{)}^{\frac{r_i}{t{x}_i}}{)}^o\cdot g^{t{x}_i})}=e(g,g{)}^{r\cdot o}\\ V^{\mathrm{\prime }}& =\frac{e(f,R)}{e(ha,f)\cdot S{S}^{-1}}=\frac{e(g^o,g^{o^{\prime }}\cdot g^{\alpha -r})}{(g^{\alpha },g^o)\cdot e(g,g{)}^{r\cdot o}}=e(g^o,g^{o^{\mathrm{\prime }}}),\\ V^{\mathrm{\prime }}& \stackrel{?}{=}V,V{M}^{\mathrm{\prime }}\stackrel{?}{=}VM\end{array}$(13) ). If the signed message is verified correctly, the verifier can generate $V^{\prime }$ through operation. And by operating with $V^{\prime }$, we can generate $V{A}^{\prime }$ and compare it with V A to verify the integrity of the message. The verifier also knows that the signed message was sent by a signer with attribute A contained in γ.

• If ${\gamma }_A(VA)=1,(|A\cap VA|\ge i)$.

(13) $\begin{array}{rl}SS& =\frac{\prod _{i\in A}e(R_i^{\mathrm{\prime }},g)}{\prod _{i\in A}e(T{X}_i,R_i^{{}^{″}})}=\frac{\prod _{i\in A}e(g^{r_i\cdot o}\cdot H(At{t}_i{)}^{r_i\cdot o}\cdot g^{t{x}_i},g)}{\prod _{i\in A}e(g^{t{X}_i},(H(At{t}_i{)}^{\frac{r_i}{t{x}_i}}{)}^o\cdot g^{t{x}_i})}=e(g,g{)}^{r\cdot o}\\ V^{\mathrm{\prime }}& =\frac{e(f,R)}{e(ha,f)\cdot S{S}^{-1}}=\frac{e(g^o,g^{o^{\prime }}\cdot g^{\alpha -r})}{(g^{\alpha },g^o)\cdot e(g,g{)}^{r\cdot o}}=e(g^o,g^{o^{\mathrm{\prime }}}),\\ V^{\mathrm{\prime }}& \stackrel{?}{=}V,V{M}^{\mathrm{\prime }}\stackrel{?}{=}VM\end{array}$(13)

4.3.7. Tracing of identity proof phase

The tracing of identity proof phase is performed to verify the identity of the signer who originally issued the leaked signing key. After verifying the signed message by the verifier, if the integrity of the data is broken or incorrect data is verified, the signer's identity must be verified. It is also necessary to prevent an unauthorised third party from accessing the cloud by obtaining a signing key from someone. AA first verifies the PIDcert that can verify the validity of the signer in the signature and then derives the PSK. In addition, using the value of “s” held by AA, the “u” value mapped to the signer's PID is derived through Equation (14(14) $PID=PSK\oplus s\oplus PTR$(14) ).

〈$\mathit{T}\mathit{r}\mathit{a}\mathit{c}\mathit{i}\mathit{n}\mathit{g}\mathit{o}\mathit{f}\mathit{P}\mathit{I}\mathit{D}\mathbf{(}\mathit{\sigma }\mathbf{)}\mathbf{\to }\mathit{P}\mathit{I}\mathit{D}\mathbf{,}\mathit{u}$〉 (14) $PID=PSK\oplus s\oplus PTR$(14) 〈$\mathit{T}\mathit{r}\mathit{a}\mathit{c}\mathit{i}\mathit{n}\mathit{g}\mathit{o}\mathit{f}\mathit{I}\mathit{d}\mathit{e}\mathit{n}\mathit{t}\mathit{i}\mathit{t}\mathit{y}\mathit{P}\mathit{r}\mathit{o}\mathit{o}\mathit{f}\mathbf{(}\mathit{u}\mathbf{)}\mathbf{\to }\mathit{R}\mathit{I}\mathit{D}$〉

Then, “u” corresponding to the PID is derived and sent to the TA to request the signer's identity mapped to the PID. After deriving “v” corresponding to “u” in PIL, the TA can check the RID of the signer to be mapped.

5. Analysis of the proposed scheme

This proposed scheme analyses security and performance (Amount of operation) to provide the requirements presented in Chapter 3.

5.1. Security analysis

This proposed scheme provides the security requirements presented in Chapter 3 as follows.

• Provide signer anonymity: In the existing ABS scheme, the signer's ID was registered with the AA for the attribute revocation of the signer whose authority has expired. With the ID of the signer included in the user attribute revocation list and the expiration period “t” the singer whose authority has expired is prevented from creating a signature (Su et al., 2020; Wei et al., 2016). This is a simple yet effective scheme. However, since this scheme registers an ID that can verify the signer's identity, the anonymity of the signer provided by the existing attribute-based signature scheme is broken. In the proposed scheme to provide broken anonymity, the signer uses an OT-based pseudonym acquisition protocol to obtain the PID. Then, the acquired PID is registered in AA to perform the ABS scheme. In detail, the signer is provided with $PIL(L=\{v_1,v_2,\dots ,v_n\})$ provided by TA and a pseudonym list [$(PI{D}_1,u_1),(PI{D}_2,u_2),\dots ,(PI{D}_n,u_n)$] provided by AA. Then, the PID is obtained by receiving and verifying the validity of the index value and the AK through the OT protocol. In order to provide traceability to prove the signer identity verification, the pseudonym ID is verified with the information of the connected signer and can be viewed as pseudonymity in the process of verifying the actual identity ID. However, TA and AA cannot know about signers who have acquired a given PID on their own. The reason is that One-of-n OT was used for communication, so it is unknown which specific signer uses PID. In other words, in the existing ABS scheme that provides revocation and traceability, the problem of the signer's anonymity being excluded from AA and the cloud server has been solved. In addition to AA and cloud servers, other verifiers (Anyone) can verify received signed messages. However, only the attributes of the γ specified by the signer can be known, and the actual identity of the signer cannot be known. Therefore, in the proposed scheme, anonymity of signers is provided to AA, cloud server and verifier.

• Block signatures from unauthorised signers: Since the Gu et al. scheme does not require attribute revocation, an unauthorised signer can create a signature with the existing signing key and attributes and send it to the verifier. On the other hand, the Su et al. scheme and Wei et al. scheme manage signers who are withdrawn due to registration of the signer's ID, making it impossible to create a signature with “t”. In the proposed scheme, a signer whose signing authority has expired is a signer withdrawn due to the expiration period “t” in the user list. The signer information registered in the user list is shared between AA and the cloud server. A signed message a signer sends contains the signer's PIDcert corresponding to the attribute. Therefore, the cloud server validates the signer as follows based on the signer's information (PID, D, t) registered in the user list. Based on the verification result, decide whether to store the signed message sent by the signer(See Equation (12(12) $\begin{array}{rl}PIDcert\cdot P& \stackrel{?}{=}PSK\cdot P+o\cdot H(PID,O,t)\cdot P\\ & =(d+H(PID,D)\cdot \alpha )\cdot P+H(PID,O,t)\cdot o\cdot P\\ & =d\cdot P+H(PID,D)\cdot \alpha \cdot P+H(PID,O,t)\cdot O\\ & =D+H(PID,D)\cdot PK+H(PID,O,t)\cdot O\end{array}$(12) )). In the proposed scheme, when the unauthorised signer signs the message using the existing A and SK and sends it to the cloud server, it verifies the PIDcert of the signature. The signer's PIDcert cannot be validated when validating a signer because the expiration period “t” does not match the signer information in the user list. This means that even if an unauthorised signer sends a signed message to the cloud server, it will not store the signed message as validation of the signer.

• Traceability to prove the signer identity: In the ABS scheme that provides existing traceability, the identity of the requested signer is confirmed through the registered signer's ID (Gu et al., 2019; Wei et al., 2016). This is a simple yet effective scheme, but it still excludes the signer's anonymity. In this proposed scheme, SK is issued using the PID obtained from AA. The SK contains a PTR that allows the signer to be traced back to the PID. As shown in Figure 3, the signer may leak the $SK=\{PSK,PTR,K,\{K_i^{\mathrm{\prime }},K_i^{{}^{″}}{\}}_{At{t}_i\in [A]}\}$ to a third party who is unauthorised to sign. The third party can sign the message with the leaked signing key and attributes and send it to the verifier through the cloud. When the verifier verifies the signature, it can be seen that the message is from the signer with the attributes of the signer who leaked the existing signing key. If the verified message is suspicious, the AA can be sent a signed message and asked for the signer's identity. The AA verifies the signer's validation PIDcert and derives the PSK. The AA then derives a PID by operating ($PID=PSK\oplus s\oplus PTR$) with the value of “s” and PTR only the AA has. Then, it derives the value of “u” corresponding to the PID and sends it to the TA to request the signer's RID mapped to the PID. The TA can check the RID of the mapped signer after deriving “v” corresponding to “u” from the PIL. In other words, the proposed scheme cannot track signers who leaked their signing keys in the middle. However, the signer's identity who was first issued the signing key through AA and TA can be checked by operating and tracing the PIDcert and PTR. As mentioned in the introduction, the signer is the user who executes the signature with the signing key issued by the AA. It can only be used by the original registered user, and studies on transfer and delegation to other users are not included in the paper. As a result, signers can be found and held accountable through traceability and proof of identity. In this way utilises existing anonymity to minimise the security threat of signature abuse by others, such as leaking signing keys and attributes.

• Provide integrity of shared signed messages: The proposed scheme shares data by signing the message with the ABS scheme to ensure the authenticity of the data to be shared. Specifically, $\sigma =⟨{\gamma }_A,PIDcert,PTR,V,f,VM,R,\{R_i^{\mathrm{\prime }},R_i^{{}^{″}}\}⟩$ is generated from the ${\gamma }_A$ generated based on the attributes $A=\{At{t}_1,At{t}_2,At{t}_3,\dots ,At{t}_n\}$ of the users who performed the signature and the operational values resulting from the Equations (7(7) $\begin{array}{rl}& V=e(f,g^{o^{\mathrm{\prime }}}),VM=H(M,V)\end{array}$(7) ) to (9(9) $\begin{array}{rl}& PIDcert=PSK+o\cdot H(PID,O,t)\end{array}$(9) ). Among the parameters of the signature, $\{V,f,VM,R,\{R_i^{\mathrm{\prime }},R_i^{{}^{″}}\}\}$ can be used to perform the verification phase as follows: (15) $SS=\frac{\prod _{i\in [1,n]}e(R_i^{\mathrm{\prime }},g)}{\prod _{i\in [1,n]}e(T{X}_i,R_i^{{}^{″}})}=\frac{\prod _{i\in [1,n]}e(g^{r_i\cdot o}\cdot H(At{t}_i{)}^{r_i\cdot o}\cdot g^{t{x}_i},g)}{\prod _{i\in [1,n]}e(g^{t{x}_i},(H(At{t}_i{)}^{\frac{r_i}{t{x}_i}}{)}^o\cdot g^{t{x}_i})}=e(g,g{)}^{r\cdot o}$(15) The integrity of the shared message can be verified through the following verification operation. (16) $\begin{array}{rl}{V}^{\mathrm{\prime }}& =\frac{e(f,R)}{e(ha,f)\cdot S{S}^{-1}}=\frac{e(g^o,g^{o^{\mathrm{\prime }}}\cdot g^{\alpha -r})}{e(g^{\alpha },g^o)\cdot e(g,g{)}^{-r\cdot o}}=(g^o,g^{o^{\mathrm{\prime }}}),\\ V^{\mathrm{\prime }}& \stackrel{?}{=}V,V{M}^{\mathrm{\prime }}\stackrel{?}{=}VM\end{array}$(16)

5.2. Performance

Performance was performed on a Windows system with a $3.50\mathrm{GHz}$ Intel Core i5−4690 processor and 8 GB of RAM. For pairing operations, we refer to the pairing-based cryptographic library (Lynn, 2010). The ECC implementation used the Koblitz elliptic curve $y^2=x^3+ax+b(modp)$ with a = 1 and b = 1 with a $163-\mathrm{bit}$ randomised prime number defined in $F_{2^{163}}$. Performance is approximately $2.766\mathrm{ms}$ for Pe(paring operation), $0.265\mathrm{ms}$ for $T_M$(Multiplication of group G), $1.215\mathrm{ms}$ for $T_E$(Exponential operation of group G), and $0.079\mathrm{ms}$ for Cryptographic hash function. Figure 6 is shown based on performance.

Figure 6. Comparison of the amount of operation between the existing ABS scheme and the proposed scheme. (a) Amount of computation required to perform signature and (b) Amount of computation required to perform verification.

The y-axis represents the computational effort shown in Table 2, and the x-axis represents the number of attributes. This means that the amount of operation for signing and verification in ABS schemes is proportional to the number of attributes specified by the signer, so the amount of operation varies depending on the number of attributes. It is accurate to set the number of attributes from 1 to n and perform the operation. Still, this proposal limits the number of attributes to a maximum of 20 to analyse and compare the operation with the existing ABS scheme. In other words, we compare the amount of operation of signing and verification when the number of attributes is the same for the existing ABS and this proposed scheme through Figure 6, so we do not consider the difference depending on the number of attributes.

Table 2. Comparison of security requirements between the existing ABS schemes and this proposed scheme

	Su et al. scheme	Wei et al. scheme	Gu et al. scheme	Proposed scheme
Provide signer anonymity	Not provided anonymity (The signer ID is used during initial registration, and the ID is used when generating the signing key)	Provide anonymity (Using OT-based pseudonym acquisition)
Block signatures from unauthorised signers	Unable to generate the signature (Including the expiration period “t” in the signing key)	Unable to generate the signature (Revocation list and key update)	Can be signed (Use with existing attributes and signing key)	Unable to save signature (Verify the signer with the user list on the server)
Traceability to prove the signer identity	Not traceable	Traceable and identifiable (Use registered ID)		Traceable and identifiable (Using OT-based pseudonym acquisition protocol)
Sign	$(3na+8)\cdot T_M+(2na+11)\cdot T_E+2H$	$(7na+11)\cdot T_M+(5na+15)\cdot T_E$	$Pe+(2na+10)\cdot T_M+19T_E+H$	$Pe+(2na+2)\cdot T_E+(2na+2)\cdot T_M+2H$
Verify	$4Pe+3T_M+(5+na)\cdot T_E$	$7Pe+5T_M$	$(na+3)\cdot Pe+(2na+4)\cdot T_M+(2na+2)\cdot T_E$	$(2na+2)\cdot Pe+2T_M+T_E+H$

Notes: Pe: Paring operation;  na: Number of attributes;  $H(\cdot )$: Cryptographic hash function;  $T_E$: Exponential operation of group G;  $T_M$: Multiplication of group G;

Specifically, Figure 6(a) shows the amount of operation required to generate a signature. The proposed scheme is efficient because it requires less operation to generate a signature when the number of attributes is small compared to the traditional ABS scheme. However, as the number of attributes increases, the amount of operation required for signature generation increases. Figure 6(b) shows the amount of operation required for signature verification, and the proposed scheme has the disadvantage of requiring a lot of operation because the pairing operation affects the number of attributes during signature verification.

In addition, the proposed scheme uses an OT-based pseudonym acquisition protocol to acquire the signer's PID before performing the ABS scheme, and an additional operation is reflected for PIDcert to authenticate the signer's validity. Therefore, when comparing the total amount of operation, it is high compared to existing ABS schemes.

However, the proposed scheme can protect the signer's privacy by providing anonymity that is excluded from the existing ABS scheme at the cost of performing additional operation. It can also block signatures from unauthorised signers. Finally, since the original leaker of the signing key can be tracked and identified, the security threat of leaking the signing key and attributes by exploiting the existing anonymity and the security threat of others abusing the signature with it can be minimised in advance.

6. Conclusion

This paper proposes a TABS scheme provided with anonymous credentials. In this proposed scheme, the signer first obtains a PID using an OT-based pseudonym acquisition protocol and then uses it to perform the ABS scheme. This provides signer anonymity on AA and cloud servers. This provided anonymity that was excluded by identity registration in existing revocation and traceability ABS schemes (Su et al. scheme, Wei et al. scheme, Gu et al. scheme). Second, when an unauthorised signer creates a signature using the existing signing key and attributes and sends it to the cloud server, the cloud server verifies the signer with the PID included in the user list and the PIDcert included in the signature. Then, storage of the signed message is determined based on signature verification. The cloud server can block unauthorised signers from continuously generating and sending signatures. Third, if the signature obtained by the verifier is unclear or problematic, the signer's identity can be verified through AA and TA. Specifically, the identity of a signer who has been issued a signing key can be verified. This minimises the security threats of leaking signing secrets and attributes by exploiting existing anonymity and of signatures being abused by others with them. Finally, since the signer signs the message with his attributes and the corresponding SK, the signer's anonymity is provided to the verifier, and the integrity of the message is guaranteed through the verification phase.

The proposed scheme in this paper can be utilised in many signature environments requiring signers' privacy protection by targeting data shared within a company/enterprise. In particular, it can be applied to environments where signers' privacy can be protected in source code licenses or works when uploading their developed OSS or data to a cloud server. The signer can claim the credentials and ownership of the source code license with only the attribute information. Since the signer can claim credentials and ownership of the source code license using only attribute information, the signer's anonymity is guaranteed. In addition, signers whose signing authority has expired cannot transmit the developed source code to the cloud server, and signers who abuse signing keys and attributes for their benefit can be minimised. This advantage is important because it can protect secure data communication and signer privacy in various industries beyond the cloud environment that shares OSS, and will become the basis for a secure data sharing system. It is expected that this can be applied to environments that require secure communication and anonymous authentication in IoT-Cloud environments, including VANET and smart grid.

In future research, we will evaluate and improve the security and efficiency of the proposed scheme by conducting tests on whether the proposed scheme can be used for anonymous credentialing in a real cloud environment. We also consider that research is needed on pseudonym exhaustion and pseudonym forgery prevention, which are requirements that should be considered in OT pseudonym acquisition protocols.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Funding

This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIT) (No.2022R1A2B5B01002490) and This work was funded by BK21 FOUR (Fostering Outstanding Universities for Research)(No.:5199990914048).

Appendices

Appendix 1. Preliminaries

A.1. Bilinear map

Bilinear mapping has been proposed as a tool to attack elliptic curve cryptosystems in the past. However, recently, it has been used as a cryptography tool for information protection, and the algorithms ECDSA(Elliptic Curve Digital Signature Algorithm) and ECC(Elliptic curve cryptography), which are based on bilinear mapping, are widely used in IoT environments. A bilinear pairing function is called a bilinear mapping, and the notation is expressed as follows Koblitz (2010) and Xu and Zhang (2010):

Suppose we have a multiplicative group $G_1$ and $G_2$ with the same order p. Assume that it is difficult to solve the discrete logarithm problem within a group. Let g be a generator group of $G_1$, and let $e:G_{1}X{G}_1\to G_2$ be a bilinear mapping that satisfies the following properties:

• Bilinearity: For all $P,Q\in G_1$ and all $a,b\in Z_p$, $e(P^a,Q^b)=e(P,Q{)}^{ab}$.

• Non-degeneracy: if $e(P,Q)=1$ for all $Q\in G_1$, then P = 0.

• Computability: For all $P,Q\in G_1$, there is an efficient algorithm to compute $e(P,Q)\in G_2$.

A.2. Bilinear diffie hellman (BDH) assumption

The deterministic BDH assumption means that, given two pairs $(g^a,g^b,g^c,W=e(g,g{)}^z)$ and $(g^a,g^b,g^c,T=e(g,g{)}^{abc})$, there is no algorithm A that can distinguish between the two pairs with meaningful probability. Here, $a,b,c,z\in Z_p$. If algorithm A is able to solve the deterministic BDH assumption, that is $|Pr[A(g^a,g^b,g^c,T)=1]-Pr[A(g^a,g^b,g^c,W)=1]|\ge ϵ$ if satisfied, then algorithm A has an advantage of ϵ.

A.3. Elliptic curve discrete logarithm problem (ECDLP) assumption

Elliptic curve cryptography is a public key encryption method that uses the mathematical properties (the discrete logarithm problem on the elliptic curve is difficult) of elliptic curves in a finite field. To use elliptic curve cryptography, an elliptic curve is a set of solutions (X, Y) of the equation $y^2=x^3+ax+b(modp)$ defined for arbitrary integers a, b. The fact that the point $P=(X,Y)$ is on the elliptic curve means that the above equation is satisfied. $Q=x\cdot P$ can be defined for any integer x for two points P, Q. Finding the solution x is a matter of discrete logarithm elliptic curves. It is easy to find Q by using $x\cdot P$ in $Q=x\cdot P$. However, even if Q and P are known, it is very difficult to infer the value of x (Koblitz, 2010; Xu & Zhang, 2010).

Appendix 2

Access structure

ABS performs signed/verified based on an access structure created using each entity's attributes (e.g. affiliation, occupation). The access structure(γ) is created and used based on the attributes of the signer who uploaded the signed message. Here, the access structure is in the form of a tree. In this work, we focus on ABS schemes supporting threshold signing predicates denoted by $\gamma (\cdot )$, where A is the signer's attribute set, and “i” is a threshold value satisfying $1\le i\le [A]$. The ${\gamma }_A$ means access structure created with the attributes of the signer. “V A” means a set of attributes that the verifier has, and we have the following definition (Wei et al., 2016).

Appendix 3

OT protocol

OT is a type of protocol in which the sender sends one piece of potentially many pieces of information to the receiver but does not know which piece is being sent (Yadav et al., 2022). To understand OT, we have prepared the following description of One-of-two OT.

• Alice generates two secret values ($s_0,s_1$). She then creates two key pairs ($e_0,d_0$), ($e_1,d_1$)and sends ($e_0,e_1$) to Bob.

• Bob has his symmetric key (k), selects one of the two public keys sent by Alice, and encrypts ($c=E_{e_b}(k),b\in \{0,1\}$). And send it to Alice.

• Alice does not know whether Bob encrypted with $e_0$ or $e_1$. Therefore, she decrypts($D_{d_i}(c),i\in \{0,1\}$) both $d_0$ and $d_1$ and gets $k_0$ and $k_1$. (One of $k_0$ and $k_1$ is the real k.) And Alice performs symmetric key encryption ($c_i=E_{k_i}(s_{i\oplus b^{\mathrm{\prime }}}),i\in \{0,1\}$) with $k_0$ for one of her two messages and $k_1$ for the other. She sends ($c_0$,$c_1$) to Bob. One is the real Bob's key, and the other is a fake.

• Bob decrypts $(s=s_{b\oplus b^{\mathrm{\prime }}}=D_{k_i}(c_b))$ with his normal key. One of the two messages is normally obtained, and Bob cannot obtain the other message. That is, Bob can only get one.

The goal is that the sender (Alice) does not want the receiver (Bob) to know which of the two messages Alice sends, and Bob should only receive one message. Based on this, One-of-n OT and m-of-n OT have been developed, and this proposed scheme uses One-of-n OT. The signer can only receive one message out of n messages (List values mapped to PIL) sent by the TA and AA. The TA and AA have yet to learn which one was received, and the signer selects and uses the PID value based on the selected message.