PriSign, A Privacy-Preserving Single Sign-On System for Cloud Environments

Abstract

Anonymous single sign-on systems allow users to use a single credential to access multiple services protected by verifiers without revealing their personal information, which is especially important due to privacy regulations such as GDPR. In this paper, we introduce a new strong privacy-preserving single sign-on scheme, dubbed PriSign, based on our proposed attribute-based credential with traceability (ABCT), attribute-based credential with blindness (ABCB), and threshold inner-product functional encryption (TIPFE). Compared with the existing state-of-the-art solutions, PriSign presents three improvements: (1) users can obtain different types of tickets according to the attribute disclosure policies enforced by the ticket issuer to support fine-grained access control; (2) users can hide access tokens and designate a verifier for tokens according to a verifier’s policy jointly issued by multiple policymakers, meaning that non-designated verifiers cannot obtain any information about the tokens; (3) we innovatively use a threshold approach to issue policy keys online in order for verifiers to achieve proxy re-verification services in an unstable cloud environment. We implement PriSign and compare the performance with other ASSO systems in the personal laptop, and the results prove its practicability.

1. Introduction

Single sign-on systems (e.g., OpenID [1], Kerberos [2] etc.) allow users to access multiple services using one credential without requiring users to apply for different credentials for each service, which is very convenient for users in the cloud environment. Anonymous single sign-on (ASSO) systems provide authentication services while protecting the privacy of users from being known by malicious service providers, which complies with privacy regulations such as the General Data Protection Regulations (GDPR) [3] that seek to minimize personal information collection.

In many application contexts of ASSO, such as the electronic ticket system, it is necessary to support fine-grained access control based on user credentials. Consider the example of a transportation ticket system, where a user can prove to the ticket issuer that they have a credential that meets certain attribute disclosure policies (e.g., age, location, disability, etc.) without revealing anything else. For example, students, disabled persons, or soldiers can selectively disclose their identity attributes to purchase discounted tickets without revealing sensitive information such as specific schools, illnesses, or service units. Supporting attribute disclosure policies can greatly improve the application scope of ASSO systems. Unfortunately, this function is not available in existing ASSO schemes [4,5,6,7,8,9].

An ASSO system’s main security requirement is to protect users’ privacy. Most of the existing schemes only consider the unlinkability of user identities [4,5,6,7], and do not protect the privacy of the user’s service requests, i.e., any service providers can obtain and verify the user access tokens. Han et al. [8] proposed an ASSO scheme for designated verifiers; their scheme guarantees that user access tokens can only be verified by a designated service provider, while user access tokens can be obtained by any non-designated verifiers. This may disclose other information of tokens, such as the validity period, serial number, etc., thus destroying the privacy of user service requests.

Although the ASSO system for designated verifiers [8] protects user service requests from being validated by malicious service providers, it reduces the reliability of the verification service in cloud environments. Due to the complexity of the cloud environment, it is not guaranteed that the verifier of each service provider can perform the verification service online in real-time while ensuring that non-designated verifiers cannot verify the access tokens of the designated verifier. This causes the entire service to become unavailable when the designated verifier encounters a single point of failure. Han et al. [9] proposed a new ASSO system with proxy re-verification to address this problem. Unfortunately, their scheme re-verifies access tokens by introducing a trusted central verifier to generate keys for proxy verifiers. If the central verifier is attacked, the verification service is unavailable. Therefore, this scheme does not improve the reliability of verification services.

1.1. Contributions

To address the above requirements, we propose a strong privacy-preserving single sign-on scheme called PriSign, which uses our proposed attribute-based credential with traceability (ABCT), attribute-based credential with blindness (ABCB), and threshold inner-product functional encryption (TIPFE) schemes along with Groth’s structure-preserving signatures (SPS) scheme. The main contributions of our scheme are:

Fine-grained access control: PriSign allows users to anonymously disclose a subset of user attributes to the ticket issuer, thereby obtaining different types of tickets for fine-grained access control.

Designated verifiers and token-hiding: For the first time, we achieve perfect privacy protection for user service requests (i.e., access tokens); that is, users’ access tokens can only be verified by a verifier with the designated policy, and are hidden from any non-designated verifiers.

Threshold key issuance for verifiers and proxy re-verification: We innovatively deploy n policymakers in the PriSign scheme using threshold cryptography technology. As long as t policymakers are online, they can issue the verification key for proxy verifiers in order to achieve a stable proxy re-verification service in the unstable cloud environment.

Similar to existing schemes, PriSign supports the unlinkability of user identities and double-spending detection. In addition, PriSign supports the traceability of users to achieve strong security control. We prove that PriSign satisfies the formal security definitions by reducing them to either well-known complexity assumptions or the security of proven cryptography primitives. The performance of PriSign is measured on a personal laptop, and our source code is made publicly available [10].

1.2. Organization

The rest of this paper is organized as follows. Section 2 presents and compares related works. Section 3 provides important preliminaries. Section 4 describes the system and security model of our PriSign system, while Section 5 describes its construction. Section 6 contains a security analysis and Section 7 a performance analysis, while Section 8 presents our conclusions.

2. Related Work and Comparison

Elmufti et al. [4] proposed an ASSO scheme suitable for the Global System for Mobile communication (GSM) system, in which the GSM network operator provides a single sign-on service for users. They combined the security features of GSM with digital signatures to allow users to access arbitrary third-party services anonymously. In their scheme, a new one-time identity is generated and used to authenticate a trusted third party (TTP) each time a user accesses a service. After authenticating the user, TTP forwards the one-time identity of the user to the service provider; therefore, the service provider cannot infer the user’s real identity from this one-time identity. Although their scheme achieves the unlinkability of user identities, it makes the verification services vulnerable to a single point of failure due to the need for the TTP when verifying user service requests. In our scheme, users can directly access services without TTP involvement.

Han et al. [5] proposed a generic construction of dynamic ASSO schemes with strong security based on CCA-secure broadcast encryption [11,12], strongly existentially unforgeable signature [13,14], and zero-knowledge proof [15,16]. In their construction, registered users can obtain an encrypted credential of their public key from an identity provider (IDP) along with the set of services they want to access. Users can use this credential to access all designated services without requiring different credentials for different services. Furthermore, when the user presents their credentials, a zero-knowledge proof of the user’s private key should be computed to prevent the sharing of credentials. Unfortunately, as all designated verifiers can know users’ public keys, this scheme cannot achieve unlinkability of user identities.

Wang et al. [6] proposed a generic construction of the ASSO scheme that is transformed from dynamic group signatures [17,18]. In their scheme, users register with a central authority and obtain a group signing key. When accessing a service, a user generates a group signature using his group signing key. The service provider checks whether the user is authorized to access the service by verifying the correctness of the group signature. In addition, the central authority can use the tracing algorithm of the group signature scheme to trace users’ identities. However, all service providers can verify users’ access requests; in our scheme, on the other hand, a user can designate the verifier of service requests.

Lee et al. [7] proposed a provably secure ASSO scheme based on extended Chebyshev chaotic maps [19,20]. In their scheme, an issuer generates ephemeral keys to users and service providers. When accessing a service, a user and a service provider need to use their ephemeral keys to exchange a session key to grant the service. Compared to the scheme based on modular exponential computations of the elliptic curve, their scheme is more efficient; however, each service provider knows user identities when generating session keys, which compromises user privacy.

Han et al. [8] utilized Au and colleagues’ BBS+ signature [21] and zero-knowledge proof of knowledge [22] in constructing an ASSO scheme for designated services. The main contribution of their construction is to protect the privacy of both user identities and their service requests. Their scheme allows users to obtain tickets from the ticket issuers in order to access multiple services, while the tickets contain a set of authentication tags that can only be verified by designated verifiers. Designated verifiers can verify that their corresponding tags cannot be linked to the user’s service request. However, unlike our scheme, their scheme does not support fine-grained access control of tickets nor proxy re-verification of access tokens.

Recently, Han et al. [9] proposed a new ASSO scheme with proxy re-verification using BBS+ Signature [21], zero-knowledge proof of knowledge [22], and identity-based encryption [23,24]. Their scheme is an improvement of the scheme in [8] to achieve proxy re-verification of services by introducing a trusted central verifier (CV). In case the designated verifier is unavailable when verifying user access tokens, the CV can authorize a proxy verifier to complete the verification of access tokens on behalf of the original verifier. Unfortunately, the setting of a CV does not improve the stability of verification services; moreover, their scheme does not support token-hiding and fine-grained access control.

The closest parallel to ASSO is the attribute-based electronic ticket (e-ticket) system [25,26,27]. In such systems, users can buy tickets from issuers using the attribute-based credentials requested from the CA, and then use the tickets to access multiple services. Han et al. [25] first proposed a privacy-preserving e-ticket system, using attribute-based credentials derived from Boneh–Boyen Signature (BBS) [28] and efficient set membership proof and range proof [29]. Next, Feng et al. [26] utilized structure-preserving signatures on equivalence class [30] and dynamically malleable signatures [31] to construct efficient and strong privacy protection in a transferable attribute-based ticket scheme. Shi et al. [27] proposed an electronic ticketing system to address the problem of existing electronic ticketing systems being challenging to deploy in resource-constrained devices and unable to prevent ticket sharing among unauthorized devices. Similar schemes [25,26,27] have achieved user anonymity and fine-grained access control; however, unlike our scheme, none of them support token-hiding and designating verifiers.

Table 1. Functional comparison.

Scheme	Unlinkability	Designated Verifiers	Proxy Re-Verification	Threshold Key Issuance	Token-Hiding	Traceability	Fine-Grained Access Control
[4]	√	×	×	−	×	√	×
[5]	×	×	×	−	×	√	×
[6]	√	×	×	−	×	√	×
[7]	×	×	×	−	×	×	×
[8]	√	√	×	−	×	√	×
[9]	√	√	√	×	×	√	×
[25]	√	×	×	−	×	√	√
[26]	√	×	×	−	×	√	√
[27]	√	×	×	−	×	×	√
PriSign	√	√	√	√	√	√	√

√: supported feature; ×: unsupported feature; −: not applicable.

summarizes a detailed comparison between PriSign and related ASSO schemes [4,5,6,7,8,9]. Comparisons are conducted in terms of unlinkability, designated verifiers, proxy re-verification, threshold keys issuance, token-hiding, traceability, and fine-grained access control. Unlinkability means that an ASSO scheme can protect users’ identities from being linked by malicious verifiers, even if they collude. Designated verifiers mean that an ASSO scheme allows users to designate a verifier for access tokens without any non-designated verifiers being able to determine the correctness of tokens. Proxy re-verification means that an ASSO scheme allows a proxy verifier to perform token verification services on behalf of the original verifier. Threshold key issuance means that an ASSO scheme allows multiple CVs (or policymakers) to generate verification keys for designated verifiers or proxy verifiers using a threshold approach. Token-hiding means that an ASSO scheme hides user service requests from all non-designated verifiers. Traceability means that an ASSO scheme can de-anonymize a user’s identity. Fine-grained access control means that an ASSO system supports users’ obtaining different types of tickets according to attribute disclosure policies. Table 1 indicates that among all schemes in our comparison, only PriSign supports all desirable features, making it a preferred solution in practice.

3. Preliminaries

In this section, we recall the definitions of complexity assumption and the cryptographic primitives used in the construction scheme. The abbreviations used in this paper are summarized in

Table 2. Nomenclature.

Abbreviation	Description
CA	Central Authority
I	Issuer
P	Policymaker
U	User
V	Verifier
SDL	Symmetric Discrete Logarithm
DDH	Decisional Diffie–Hellman
BDDH	Bilinear Decisional Diffie–Hellman
PS	Pointcheval–Sanders
SPS	Structure-Preserving Signatures
EUF-CMA	Existentially Unforgeable under Chosen Message Attacks
ZKSoK	Zero-Knowledge Signature of Knowledge
ABCT	Attribute-Based Credential with Traceability
ABCB	Attribute-Based Credential with Blindness
IPFE	Inner-Product Functional Encryption
TIPFE	Threshold Inner-Product Functional Encryption

.

3.1. Bilinear Pairing

Let ${\mathbb{G}}_1$, ${\mathbb{G}}_2$, and ${\mathbb{G}}_T$ be cyclic groups of prime order p. Let g and $\tilde{g}$ be generators of ${\mathbb{G}}_1$ and ${\mathbb{G}}_2$, respectively. The mapping $e:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$ is a bilinear map if it has three properties: (1) bilinearity: $\forall g\in {\mathbb{G}}_1,\tilde{g}\in {\mathbb{G}}_2$, and $a,b\in {\mathbb{Z}}_p$, and we have $e(g^a,{\tilde{g}}^b)=e{(g,\tilde{g})}^{ab}$; (2) non-degeneracy: $e(g,\tilde{g})\ne 1_{{\mathbb{G}}_T}$; (3) computability: e can be efficiently computed. We denote a bilinear group $\mathcal{BL}=({\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T,e,p,g,\tilde{g})$. Our scheme is based on the Type-III pairing [32], which means that there is no efficiently computable homomorphism between ${\mathbb{G}}_1$ and ${\mathbb{G}}_2$.

3.2. Complexity Assumptions

• Symmetric Discrete Logarithm (SDL) Assumption: Let $\mathcal{BL}$ be a bilinear group. Given $(g,g^x)\in {\mathbb{G}}_1^2$ and $(\tilde{g},{\tilde{g}}^x)\in {\mathbb{G}}_2^2$, the SDL assumption holds in $\mathcal{BL}$ if no efficient adversary can compute x with non-negligible probability.
• Decisional Diffie–Hellman (DDH) assumption: Let $\mathbb{G}$ be an cyclic group of prime order and g be a generator of $\mathbb{G}$; given $(g,g^x,g^y,g^z)\in {\mathbb{G}}^4$, the DDH assumption holds in the group $\mathbb{G}$ if no efficient adversary can distinguish $z=x·y$ from an element z randomly chosen from ${\mathbb{Z}}_p$.
• Bilinear Decisional Diffie–Hellman (BDDH) Assumption: Let $\mathcal{BL}$ be a bilinear group; given $(g^a,g^b,{\tilde{g}}^a,{\tilde{g}}^c,e{(g,\tilde{g})}^z)$, the BDDH assumption holds if no efficient adversary can distinguish $z=a·b·c$ from an element z randomly chosen from ${\mathbb{Z}}_p$.

3.3. Structure-Preserving Signatures

Groth’s structure-preserving signatures (SPS) [33] consist of the following probability polynomial-time (PPT) algorithms:

• $\mathsf{SPS}.\mathsf{Setup}(1^{\lambda },l)\to pp$: On input a security parameter $1^{\lambda }$ and a positive integer l, this algorithm generates a bilinear group $\mathcal{BL}=({\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T,$$e,p,g,\tilde{g})$ and outputs public parameters $pp=(\mathcal{BL},l)$.
• $\mathsf{SPS}.\mathsf{KeyGen}\left(pp\right)\to (sk,pk)$: On input public parameters $pp$, this algorithm selects $({\alpha }_0,{\alpha }_1,\cdots ,{\alpha }_{l-1})\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$ and a generator $\gamma \stackrel{R}{\leftarrow }{\mathbb{G}}_2$, then computes ${\beta }_i=g^{{\alpha }_i},0⩽i⩽l-1$. It outputs a secret key $sk=({\alpha }_0,{\alpha }_1,\cdots ,{\alpha }_{l-1})$ and a public key $pk=(\gamma ,{\left\{{\beta }_i\right\}}_{i=0}^{l-1})$.
• $\mathsf{SPS}.\mathsf{Sign}(sk,{\left\{m_i\right\}}_{i=1}^l)\to \delta$: To sign l messages $m_1,\cdots ,m_l$ ($m_i\in {\mathbb{G}}_2,1⩽i⩽l$), the signer selects $r\stackrel{R}{\leftarrow }{\mathbb{Z}}_p$, computes ${\delta }_1=g^{r^{-1}}$; ${\tilde{\delta }}_2={(\gamma ·{\tilde{g}}^{{\alpha }_0})}^r$ and ${\tilde{\delta }}_3={({\gamma }^{{\alpha }_0}{m}_l·{\prod }_{i=1}^{l-1}{m}_i^{{\alpha }_i})}^r$, then outputs the signature $\delta =({\delta }_1,{\tilde{\delta }}_2,{\tilde{\delta }}_3)$.
• $\mathsf{SPS}.\mathsf{Verify}(pk,\delta ,{\left\{m_i\right\}}_{i=1}^l)\to 0/1$: To verify the signature $\delta =({\delta }_1,{\tilde{\delta }}_2,{\tilde{\delta }}_3)$ on messages ${\left\{m_i\right\}}_{i=1}^l$, this algorithm checks two pairing equations, $e({\delta }_1,{\tilde{\delta }}_2)=e(g,\gamma ,)e({\beta }_0,\tilde{g})$ and $e({\delta }_1,{\tilde{\delta }}_3)=e({\beta }_0,\gamma )e(g,m_l){\prod }_{i=1}^{l-1}e({\beta }_i,m_i)$. If both equations are satisfied, it outputs 1; otherwise, it outputs 0.

Groth’s SPS scheme [33] is existentially unforgeable under chosen message attacks (EUF-CMA). In this paper, we use this signature scheme to create credentials for the public key of the ticket issuer.

3.4. Pointcheval–Sanders Signatures

The multiple-message Pointcheval–Sanders (PS) signatures [34] consist of the following PPT algorithms:

• $\mathsf{PS}.\mathsf{Setup}(1^{\lambda },q)\to pp$: On input of a security parameter $1^{\lambda }$ and a positive integer q, this algorithm generates a bilinear group $\mathcal{BL}=({\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T,$$e,p,g,\tilde{g})$ and outputs public parameters $pp=(\mathcal{BL},q)$.
• $\mathsf{PS}.\mathsf{KeyGen}\left(pp\right)\to (sk,pk)$: On input public parameters $pp$, this algorithm selects $(x,y_0,\cdots ,y_q)\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$ and computes $\tilde{X}={\tilde{g}}^x,{\tilde{Y}}_i={\tilde{g}}^{y_i}0⩽i⩽q$. It outputs a secret key $sk=(x,y_0,\cdots ,y_q)$ and a public key $pk=(\tilde{X},{\tilde{Y}}_0,\cdots ,{\tilde{Y}}_q)$.
• $\mathsf{PS}.\mathsf{Sign}(sk,{\left\{m_j\right\}}_{j\in [0,q]})\to \sigma$: To sign messages $m_0,\cdots ,m_q$ ($m_j\in {\mathbb{Z}}_p^{*},0⩽j⩽q$), the signer selects $r\stackrel{R}{\leftarrow }{\mathbb{Z}}_p$, computes ${\sigma }_1=g^r$, ${\sigma }_2=g^{r(x+{\sum }_{j\in [0,q]}{m}_j{y}_j)}$ and outputs the signature $\sigma =({\sigma }_1,{\sigma }_2)$.
• $\mathsf{PS}.\mathsf{Verify}(pk,{\left\{m_j\right\}}_{j\in [0,q]},\sigma )\to 0/1$: To verify the signature $\sigma =({\sigma }_1,{\sigma }_2)$ on messages ${\left\{m_j\right\}}_{i=0}^q$, this algorithm checks two equations, ${\sigma }_1\ne 1_{{\mathbb{G}}_1}$ and $e({\sigma }_2,\tilde{g})=e({\sigma }_1,\tilde{X}{\prod }_{j\in [0,q]}{\tilde{Y}}_j^{m_j})$. If both equations are satisfied, it outputs 1; otherwise, it outputs 0.

PS signature achieves EUF-CMA secure status under the PS assumption [34].

3.5. Inner-Product Functional Encryption

An inner-product functional encryption (IPFE) [35,36] scheme over the set of attributes $\mathrm{\Sigma }$ consists of the following PPT algorithms:

• $\mathsf{IPFE}.\mathsf{Setup}\left(1^{\lambda }\right)\to (sk,pk)$: On input of a security parameter $1^{\lambda }$, this algorithm outputs a master private key $sk$ and a master public key $pk$.
• $\mathsf{IPFE}.\mathsf{Extract}(sk,\overrightarrow{v})\to d{k}_{\overrightarrow{v}}$: On input of a master private key $sk$ and a characteristic vector $\overrightarrow{v}$, this algorithm outputs a policy key $d{k}_{\overrightarrow{v}}$.
• $\mathsf{IPFE}.\mathsf{Enc}(pk,\overrightarrow{u},M)\to C$: On input of a master public key $pk$, an attribute vector $\overrightarrow{u}\in \mathrm{\Sigma }$, and a message M, this algorithm outputs a ciphertext C.
• $\mathsf{IPFE}.\mathsf{Dec}(d{k}_{\overrightarrow{v}},C)\to M/\perp$: On input of a policy key $d{k}_{\overrightarrow{v}}$ and a ciphertext C, this algorithm outputs the message M if $<\overrightarrow{u},\overrightarrow{v}>=0$; otherwise, it outputs the failure symbol ⊥.

An IPFE [36] scheme is secure if it is attribute-hiding; we introduce the definition of attribute-hiding in Supplemental Material A.

3.6. Zero-Knowledge Signature of Knowledge

Zero-knowledge signature of knowledge (ZKSoK) [37] for an NP-relation $\mathcal{R}$ with the language $L_{\mathcal{R}}=\{y:\exists x,(x,y)\in \mathcal{R}\}$ consists of the following algorithms:

• $\mathsf{ZKSoK}.\mathsf{Gen}\left(1^{\lambda }\right)\to pp$: On input of a security parameter $\lambda$, this algorithm outputs a public parameter $pp$.
• $\mathsf{ZKSoK}.\mathsf{Prove}(m,x,y)\to \mathrm{\Pi }$: On input of a message m and a relation $(x,y)\in \mathcal{R}$, this algorithm it outputs a ZKSoK: $\mathrm{\Pi }=\mathsf{ZKSoK}\left\{x\right|(x,y)\in \mathcal{R}\}$.
• $\mathsf{ZKSoK}.\mathsf{Verify}(m,\mathrm{\Pi },y)\to 0/1$: On input of a message m, a ZKSoK $\mathrm{\Pi }$, and a statement y, this algorithm returns 1 if $\mathrm{\Pi }$ is valid; otherwise, it returns 0.

A ZKSoK is $SimExt$-$secure$ [37] if it satisfies correctness, simulatability, and extractability.

4. System and Security Model

In this section, we describe the system and security model of our PriSign system.

4.1. System Model

As shown in Figure 1, the architecture of a PriSign scheme consists of five types of parties: a central authority (CA), a ticket issuer ($\mathsf{I}$), policymakers ($\mathsf{P}$), users ($\mathsf{U}$), and ticket verifiers ($\mathsf{V}$). The specific role of each party is described below.

• CA is a trusted global party responsible for setting up the system (step ➀), providing certification service for the ticket issuer (step ➂) and all users (step ➇) as well as issuing keys for a group of policymakers (step ➃). Moreover, CA can trace the identities of malicious users (step ➉).
• I is a ticket issuer and should register with CA (step ➁ and step ➂). I is tasked to verify any user’s credentials according to attribute disclosure policies generated by itself and to issue tickets for users (step ➈).
• P${}_i$ is an independent policymaker which receives keys from CA (step ➃) and is responsible for issuing a share of the policy key for each verifier and binding this share to the verifier’s identity (step ➄). The PriSign scheme is set up with n policymakers, of which t policymakers can cooperate to issue complete policy keys for verifiers. If a verifier is offline, t policymakers can cooperate to issue a new key with the same policy as the offline verifier that is bound to the identity of a new proxy verifier. This proxy-verifier can replace the offline verifier in order to complete the verification of tokens that are designated to be verified by the offline verifier.
• U with with a set of attributes should apply for a credential from CA (steps ➆ and ➇). To obtain a ticket, U needs to present a credential to I anonymously and disclose a subset of attributes to prove that the attribute disclosure policy enforced by I is satisfied (step ➈). To access a designated service with a ticket, U computes an access token of the ticket using an attribute vector that matches the designated verifier’s policy (step ⑪).
• V should request that each of t online policymakers receive a share of the policy key bound to its identity (step ➄) and aggregate them into a complete policy key (step ➅). V with a complete policy key that matches the user’s attribute vector then provides token verification services for those users who designate it as the verifier, and can detect any double-spending tickets (step ⑫).

In practical applications, in order to prevent users from accessing services unrestricted, tickets applied by users from issuers can only be used once, such as movie tickets and traffic tickets. However, electronic tickets are easily copied and shared, meaning that malicious users must be prevented from double-spending. In this paper, we use the pre-generated double-spending identity $dsid$ as the unique identity of the ticket; if the verifier detects that the double-spending identity is repeated, it suspends access.

4.2. Formal Definition

The notation used in the scheme is summarized in

Table 3. Summary of notation.

Notation	Description
$1^{\lambda }/ϵ\left(\lambda \right)$	security parameter/negligible function
$x\stackrel{R}{\leftarrow }\mathbb{Z}$	x is randomly selected from the set $\mathbb{Z}$
$[1,q]$	set $\{1,2,\cdots ,q\}$
$\mathcal{D}$	a subset of $[1,q]$
q	number of user attributes
$n/t$	number of policymakers/threshold value
k	length of verifier’s policy
$pp/\mathcal{L}$	public parameters/user registration list
$msk/mpk$	private key of system/public key of system
$isk/ipk/icred$	private key/public key/credential of I
$ps{k}_i/pv{k}_i$	private/verification key of P${}_i$
$vid/\overrightarrow{v}/t{d}_{vid,\overrightarrow{v}}$	identity/policy/policy key of V
$uid/usk/upk/utk$	identity/secret/public/tracing key of U
${\left\{m_j\right\}}_{j\in [1,q]}/ucred$	attributes/credential of U
$dsid/VP$	double-spending identity/validity period
$\overrightarrow{u}$	attribute vector that matches a policy
$tkt/tok$	ticket/token of U
$\mathcal{D}/I$	set/number of indexes for disclosed attributes
CTX	random value
$\mathsf{HASH}$	collision resistant hash functions: ${\{0,1\}}^{*}\to {\mathbb{Z}}_p^{*}$
${\mathsf{HASH}}^{\prime }$	collision resistant hash functions: ${\{0,1\}}^{*}\to {\mathbb{G}}_1^{*}$
⊥	failed identifier

. The PriSign scheme consists of the following PPT algorithms:

• $\mathsf{PriSign}.\mathsf{Setup}(1^{\lambda },q,n,t,k)\to (pp,msk,mpk,\mathcal{L})$: This algorithm is operated by CA, which inputs a security parameter $1^{\lambda }$, a number of user attributes q, a number of policymakers n and threshold value t, and a policy length k, then outputs the system parameters $pp$, a main key pair $(msk,mpk)$, and a user registration list $\mathcal{L}$, where $pp$ contains a matching function $\mathcal{F}$ over the set of attribute vectors $\mathrm{\Sigma }$ and the set of policies $\Delta$. To simplify the description, the remaining algorithms take $pp$ as the input by default.
• $\mathsf{PriSign}.\mathsf{IssuerKeyGen}\left(\right)\to (isk,ipk)$: This algorithm is operated by the ticket issuer and outputs a secret key $isk$ and public key $ipk$.
• $\mathsf{PriSign}.\mathsf{IssuerReg}\langle \mathsf{I}(isk,ipk)\leftrightarrow \mathsf{CA}(msk,mpk)\rangle \to icred/\perp$: This algorithm operates by interacting between I and CA to issue a public key credential for I. I takes $(isk,ipk)$ as inputs, while CA takes $msk$ and $mpk$ as inputs. It returns either a credential $icred$ for I if the execution of the algorithm succeeds, or ⊥ if the execution fails.
• $\mathsf{PriSign}.\mathsf{PolMakKeyGen}(msk,mpk)\to \left(\right\{ps{k}_i,$$pv{k}_i{\}}_{i\in [1,n]})$: This algorithm is operated by CA to issue keys for n policymakers. It inputs $msk$, $mpk$, and outputs a private key $ps{k}_i$ and a verification key $pv{k}_i$ for each P${}_i$, where $i\in [1,n]$. Note that t policymakers can cooperate to recover the complete key used to generate policy keys for verifiers.
• $\mathsf{PriSign}.\mathsf{IssPolKey}(ps{k}_i,vid,\overrightarrow{v})\to t{k}_{vid,\overrightarrow{v},i}.$ This algorithm is operated by a policymaker P${}_i$ with index i to generate a share of a policy key for a verifier with identity $vid$ and policy $\overrightarrow{v}$. It inputs $ps{k}_i$, a verifier’s identity $vid$, and a policy $\overrightarrow{v}$, and outputs a share of policy key $t{k}_{vid,\overrightarrow{v},i}$.
• $\mathsf{PriSign}.\mathsf{AggrPolKey}(vid,\overrightarrow{v},{\{t{k}_{vid,\overrightarrow{v},i},pv{k}_i\}}_{i\in [1,t]})\to t{k}_{vid,\overrightarrow{v}}$; This algorithm is operated by V, which receives t shares of the policy key from t policymakers and aggregates them into a complete policy key. It inputs $vid$, $\overrightarrow{v}$, t shares of policy key ${\left\{t{k}_{vid,\overrightarrow{v},i}\right\}}_{i\in [1,t]}$, and ${\left\{pv{k}_i\right\}}_{i\in [1,t]}$, then outputs a complete policy key $t{k}_{vid,\overrightarrow{v}}$.
• $\mathsf{PriSign}.\mathsf{UserKeyGen}\left(\right)\to (usk,upk,utk)$: This algorithm is operated by U and outputs a private key $usk$, a public key $upk$, and a tracing key $utk$.
• $\mathsf{PriSign}.\mathsf{UserReg}\langle \mathsf{U}(uid,usk,upk,utk,{\left\{m_j\right\}}_{j\in [1,q]})\leftrightarrow \mathsf{CA}(msk,mpk,\mathcal{L})\rangle \to (ucred,$${\mathcal{L}}^{\prime })$$/\perp$: This algorithm is operated by interacting between U and CA to issue an attribute-based credential for U. U takes the identity $uid$, $usk$, $upk$, $utk$ and set of attributes ${\left\{m_j\right\}}_{j\in [1,q]}$ as inputs, while CA takes $msk$, $mpk$, and $\mathcal{L}$ as inputs. It returns either a credential $ucred$ for U and updated user registration list ${\mathcal{L}}^{\prime }$ if the execution of the algorithm succeeds, or ⊥ if the execution fails.
• $\mathsf{PriSign}.\mathsf{ObtTkt}\langle \mathsf{U}(usk,upk,ucred,{\left\{m_j\right\}}_{j\in [1,q]},\mathcal{D},\mathsf{CTX})$$\leftrightarrow \mathsf{I}(isk,ipk,icred)\rangle \to (pst,tkt,$$dsid,VP)/\perp$: This algorithm operates by interacting between U and I to issue a ticket for U. U takes $usk$, $upk$, $ucred$, ${\left\{m_j\right\}}_{j\in [1,q]}$, an attribute disclosure policy $\mathcal{D}$ ($\mathcal{D}\subseteq [1,q]$), and a context $\mathsf{CTX}$ as inputs, while I takes $isk$, $ipk$, and $icred$ as inputs. It outputs either a credential presentation $pst$, a ticket $tkt$, the ticket’s double-spending identity $dsid$, and validity period $VP$ if the execution of the algorithm succeeds, or if the execution fails, ⊥. Note that ${\left\{m_j\right\}}_{j\in \mathcal{D}}$ should satisfy an attribute disclosure policy generated by I to pass I’s verification, and CTX is a random value to prevent replay attacks.
• $\mathsf{PriSign}.\mathsf{Trace}(msk,\mathcal{L},pst)\to uid/\perp$: This algorithm is operated by CA, which takes $msk$, $\mathcal{L}$, and $pst$ as inputs, and outputs either a user’s identity $uid$ if the execution of the algorithm succeeds or ⊥ if the execution fails.
• $\mathsf{PriSign}.\mathsf{SignOn}(tkt,dsid,VP,\overrightarrow{u},\overrightarrow{v},mpk)\to tok/\perp$: This algorithm is operated by U to create an access token $tok$ to a designated verifier with the policy $\overrightarrow{v}$. It takes $tkt$, $dsid$, $VP$, an attribute vector $\overrightarrow{u}$ that matches the policy $\overrightarrow{v}$ (i.e., $\overrightarrow{u}\in \mathrm{\Sigma },\overrightarrow{v}\in \Delta ,\mathcal{F}(\overrightarrow{u},\overrightarrow{v})=0$), and $mpk$ as inputs, then outputs an access token $tok$.
• $\mathsf{PriSign}.\mathsf{Verify}(vid,tok,t{k}_{vid,\overrightarrow{v}},mpk)\to 0/1$: This algorithm is operated by a designated verifier V that takes $vid$, $tok$, $t{k}_{vid,\overrightarrow{v}}$, and $mpk$ as inputs. It outputs 1 if the token is validated and not double-spending, and 0 otherwise.

Correctness. A PriSign scheme is correct if it satisfies the following conditions: (1) access tokens generated by honest users can be verified by designated verifiers; (2) the identities of users who have successfully obtained tickets can be traced by the CA. The formal correctness definition is shown in Supplemental Material E.1.

4.3. Overflow of PriSign

As shown in Figure 1, the working flow of a PriSign scheme is described as follows. CA initializes the system and outputs public parameter $pp$, a main key pair $(msk,mpk)$, and a user registration list $\mathcal{L}$ (PriSign.Setup step ➀). To be a legitimate ticket issuer, I generates a private and public key pair ($isk,ipk$) (PriSign.IssuerKeyGen step ➁) and authenticates to CA to obtain their public key credential $icred$ (PriSign.IssuerReg step ➂). To achieve stable policy key generation in an unstable cloud environment, CA issues keys to n policymakers such that t of these policymakers cooperate to generate the complete policy keys for verifiers (PriSign.PolMakKeyGen step ➃); t policymakers then generate a share of the policy key for the respective verifier with identity $vid$ and policy $\overrightarrow{v}$ (PriSign.IssPolKey step ➄) and the verifier aggregates the t shares into a complete policy key $t{k}_{vid,\overrightarrow{v}}$ (PriSign.AggrPolKey step ➅). Suppose a verifier with policy $\overrightarrow{v}$ is offline. In this case, t policymakers can cooperate to issue a new key $t{k}_{vi{d}^{\prime },\overrightarrow{v}}$ with the policy $\overrightarrow{v}$ for a proxy verifier with identity $vi{d}^{\prime }$; this proxy verifier can replace the offline verifier to complete the verification of tokens that are designated to be verified by the offline verifier. When joining the system, each U generates a private and public key pair ($usk,upk$) and a tracing key $utk$ (PriSign.UserKeyGen step ➆), then U authenticates to CA to obtain their attribute-based credentials $ucred$ (PriSign.UserReg step ➇). To obtain a ticket, U authenticates to I by computing a credential presentation $pst$ and disclosing a subset of attributes, then I issues a ticket $tkt$ for U (PriSign.ObtTkt step ➈). At this point, CA can trace the identities of users (PriSign.Trace step ➉). When accessing a designated service, U computes an access token of the ticket using an attribute vector $\overrightarrow{u}$ that matches the designated verifier’s policy $\overrightarrow{v}$ (PriSign.SignOn step ⑪). The designated verifier with the policy key $t{k}_{vid,\overrightarrow{v}}$ verifies the validity of the token and detects whether it is double-spending (PriSign.Verify step ⑫).

4.4. Threat Model

We assume that the central authority CA is a globally trusted party in the system. The ticket issuer I is assumed to be honest but curious, in the sense that while it is honest in issuing tickets for users according to the attribute disclosure policies, it is curious about obtaining users’ undisclosed attributes and real identities. Policymakers P are globally trusted parties in the system, assuming that at least t out of n policymakers in a cloud environment simultaneously provide policy key generation services online. Users U are assumed to be malicious; they either forge the credential presentations to illegally obtain tickets, or directly forge tokens to illegally access designated services. Verifiers V are assumed to be honest but curious; V honestly verifies tokens of the users who designated it as a verifier and prevents double-spending of tickets, but is curious about the real identities of the users. In addition, it is curious about knowing the token information of users who did not designate it as the verifier.

4.5. Security Model

In this section, we adopt a game-based model to define the security properties of the PriSign scheme, including its unforgeability, unlinkability, and token-hiding. All security definitions use the following global variables and oracles. There is a challenger $\mathcal{C}$ and a PPT adversary $\mathcal{A}$ in the game; $\mathcal{C}$ is responsible for initializing the system, issuing keys for all policymakers, and controlling all global variables and oracles; and $\mathcal{A}$ interacts with $\mathcal{C}$ through the oracles to break the scheme.

Global Variables.

${\mathcal{Q}}_{\mathsf{HU}}$: a set storing $(uid,usk,upk,utk,{\left\{m_j\right\}}_{j\in [1,q]},ucred)$ each time CA issues a credential for an honest user $uid$.

${\mathcal{Q}}_{\mathsf{CU}}$: a set of corrupt user identities $uid$;

${\mathcal{Q}}_{\mathsf{I}}$: a set storing $isk$ when CA issues a credential for the ticket issuer.

${\mathcal{Q}}_{\mathsf{V}}$: a set storing $(vid,\overrightarrow{v},t{k}_{vid,\overrightarrow{v}})$ each time t policymakers cooperate to generate a policy key for a verifier $vid$ with policy $\overrightarrow{v}$.

${\mathcal{Q}}_{\mathsf{TKT}}$: a set storing $(uid,pst,tkt,dsid,VP,\mathsf{CTX})$ each time I issues a ticket for an honest user $uid$.

${\mathcal{Q}}_{\mathsf{TOK}}$: a set storing $(uid,tok,\overrightarrow{u},\overrightarrow{v},vid)$ each time U create an access token to a designated verifier $vid$ with a policy $\overrightarrow{v}$.

Oracles.

−${\mathcal{O}}_{{\mathsf{Reg}}_I}\left(\right)$: It is an oracle that can be used to issue a public key credential for the ticket issuer. It generates a key pair by running $(isk,ipk)\leftarrow \mathsf{PriSign}.\mathsf{IssuerKeyGen}\left(\right)$, and then issues a credential to the ticket issuer by running $icred\leftarrow \mathsf{PriSign}.\mathsf{IssuerReg}\langle \mathsf{I}(isk,ipk)\leftrightarrow \mathsf{CA}(msk,mpk)\rangle$. Finally, it adds $isk$ to ${\mathcal{Q}}_{\mathsf{I}}$ and returns $(ipk,icred)$.

−${\mathcal{O}}_{{\mathsf{Cor}}_I}\left(\right)$: an oracle that can be used to corrupt the ticket issuer by returning $isk$.

−${\mathcal{O}}_{{\mathsf{Iss}}_V}(vid,\overrightarrow{v})$: an oracle that can be used to generate a policy key for a ticket verifier $vid$ with a policy $\overrightarrow{v}$. If $(vid,\overrightarrow{v})\in {\mathcal{Q}}_{\mathsf{V}}$, then it returns ⊥; otherwise, it runs $\{t{k}_{vid,\overrightarrow{v},i}\leftarrow$$\mathsf{PriSign}.\mathsf{IssPolKey}(ps{k}_i,vid,\overrightarrow{v}){\}}_{i\in [1,t]}$, then runs $t{k}_{vid,\overrightarrow{v}}$$\leftarrow \mathsf{PriSign}.\mathsf{AggrPolKey}(vid,\overrightarrow{v},$ ${\{t{k}_{vid,\overrightarrow{v},i},pv{k}_i\}}_{i\in [1,t]})$, and finally adds $(vid,\overrightarrow{v},t{k}_{vid,\overrightarrow{v}})$ to ${\mathcal{Q}}_{\mathsf{V}}$.

−${\mathcal{O}}_{{\mathsf{Cor}}_V}(vid,\overrightarrow{v})$: an oracle that can be used to corrupt a ticket verifier $vid$ with the policy $\overrightarrow{v}$ by returning $t{k}_{vid,\overrightarrow{v}}$.

−${\mathcal{O}}_{{\mathsf{Reg}}_U}(uid,{\left\{m_j\right\}}_{j\in [1,q]})$: an oracle that can be used to issue an attribute-based credential for an honest user $uid$ with an attribute set ${\left\{m_j\right\}}_{j\in [1,q]}$. If $uid\in \mathcal{CU}\cup \mathcal{HU}$, then it returns ⊥; otherwise, it generates keys by running $(usk,upk,utk)\leftarrow \mathsf{PriSign}.\mathsf{UserKeyGen}\left(\right)$, then issues a credential to user $uid$ by running $(ucred,{\mathcal{L}}^{\prime })\leftarrow \mathsf{PriSign}.\mathsf{UserReg}\langle \mathsf{U}(uid,usk,$$upk,utk,{\left\{m_j\right\}}_{j\in [1,q]})\leftrightarrow \mathsf{CA}($$msk,mpk,\mathcal{L})\rangle$. Finally, it adds $(uid,usk,upk,utk,$${\left\{m_j\right\}}_{j\in [1,q]},$$ucred)$ to ${\mathcal{Q}}_{\mathsf{HU}}$.

−${\mathcal{O}}_{{\mathsf{Cor}}_U}\left(uid\right)$: an oracle that can be used to corrupt an honest user $uid$. If $uid\in {\mathcal{Q}}_{\mathsf{CU}}$, then it returns ⊥. If $uid\in {\mathcal{Q}}_{\mathsf{HU}}$, then it removes $(uid,usk,upk,utk,$${\left\{m_j\right\}}_{j\in [1,q]},ucred)$ from ${\mathcal{Q}}_{\mathsf{HU}}$ and adds $uid$ to ${\mathcal{Q}}_{\mathsf{CU}}$. Finally, it returns $(usk,upk,utk,$${\left\{m_j\right\}}_{j\in [1,q]},ucred)$.

$-{\mathcal{O}}_{\mathsf{Obt}}(uid,\mathcal{D},\mathsf{CTX}):$ an oracle that can be used to play the honest ticket issuer issuing a ticket to an honest user $uid$. If $uid\in {\mathcal{Q}}_{\mathsf{CU}}$, it returns ⊥; otherwise, it runs $(pst,tkt,dsid,VP,\mathsf{CTX})\leftarrow \mathsf{PriSign}.\mathsf{ObtTkt}\langle \mathsf{U}(usk,upk,ucred,{\left\{m_j\right\}}_{j\in [1,q]},\mathcal{D},\mathsf{CTX})$$\leftrightarrow \mathsf{I}(isk,$$ipk,icred)\rangle$. Finally, it adds $(uid,pst,tkt,dsid,VP,$$\mathsf{CTX})$ to ${\mathcal{Q}}_{\mathsf{TKT}}$.

$-{\mathcal{O}}_{{\mathsf{Obt}}_U}(uid,\mathcal{D},\mathsf{CTX}):$ an oracle that can be used to play the corrupted ticket issuer issuing a ticket to an honest user $uid$. If $uid\in {\mathcal{Q}}_{\mathsf{CU}}$, it returns ⊥; otherwise, it runs $(pst,tkt,dsid,VP,\mathsf{CTX})\leftarrow \mathsf{PriSign}.\mathsf{ObtTkt}\langle \mathsf{U}(usk,upk,ucred,{\left\{m_j\right\}}_{j\in [1,q]},\mathcal{D},\mathsf{CTX})$$\leftrightarrow \mathcal{A}(·,ipk,icred)\rangle$, where the ticket issuer’s side is executed by the adversary. Finally, it adds $(uid,pst,tkt,dsid,VP,\mathsf{CTX})$ to ${\mathcal{Q}}_{\mathsf{TKT}}$.

$-{\mathcal{O}}_{{\mathsf{Obt}}_I}(uid,\mathcal{D},\mathsf{CTX}):$ an oracle that can be used to play the honest ticket issuer issuing a ticket to a corrupt user $uid$. If $uid\notin {\mathcal{Q}}_{\mathsf{CU}}$, it returns ⊥; otherwise, it runs $(pst,tkt,dsid,VP,\mathsf{CTX})\leftarrow \mathsf{PriSign}.\mathsf{ObtTkt}\langle \mathcal{A}(·,\mathcal{D},\mathsf{CTX})$$\leftrightarrow \mathsf{I}(isk,ipk,icred)\rangle$, where the user’s side is executed by the adversary. Finally, it adds $(uid,pst,tkt,*,VP,\mathsf{CTX})$ to ${\mathcal{Q}}_{\mathsf{TKT}}$, where * is unknown.

$-{\mathcal{O}}_{\mathsf{Sign}}(uid,\overrightarrow{u},vid,\overrightarrow{v}):$ an oracle that can be used to play an honest user $uid$ with an attribute vector $\overrightarrow{u}$ creating a token to a designated verifier $vid$ with the policy $\overrightarrow{v}$. If $uid\in {\mathcal{Q}}_{\mathsf{CU}}$, it returns ⊥; otherwise, it runs $tok\leftarrow \mathsf{PriSign}.\mathsf{SignOn}(tkt,dsid,VP,\overrightarrow{u},\overrightarrow{v},mpk)$. Finally, it adds $(uid,tok,\overrightarrow{u},\overrightarrow{v},vid)$ to ${\mathcal{Q}}_{\mathsf{TOK}}$ and returns $tok$.

−${\mathcal{O}}_{{\mathsf{UnlCred}}_b}(ui{d}_0,ui{d}_1,\mathcal{D},\mathsf{CTX})$: a challenge oracle in the unlinkability of credentials experiment, where the adversary playing as the ticket issuer is challenged to distinguish credential presentations computed by two different users. It takes two identities of users $(ui{d}_0,ui{d}_1)$ and an attribute disclosure policy $\mathcal{D}$ as inputs, then runs $(ps{t}_b,tk{t}_b,dsi{d}_b,V{P}_b,$$\mathsf{CTX})\leftarrow \mathsf{PriSign}.\mathsf{ObtTkt}\langle \mathsf{U}(us{k}_b,up{k}_b,ucre{d}_b,{\left\{m_{b,j}\right\}}_{j\in [1,q]},\mathcal{D},\mathsf{CTX})$$\leftrightarrow \mathsf{I}(isk,ipk,icred)\rangle$, where $b\in \{0,1\}$. Finally, it returns $ps{t}_b$. Note that the attributes disclosed by both users should be the same, i.e., $\forall j\in \mathcal{D},m_{0,j}=m_{1,j}$.

−${\mathcal{O}}_{{\mathsf{UnlTkt}}_b}(ui{d}_0,ui{d}_1,\overrightarrow{u},vid,\overrightarrow{v},\mathsf{CTX})$: a challenge oracle in the unlinkability of tokens experiment, where the adversary playing as a designated ticket verifier $vid$ with the policy $\overrightarrow{v}$ is challenged to distinguish access tokens computed by two different users. It takes two identities of users $(ui{d}_0,ui{d}_1)$ and an attribute vector $\overrightarrow{u}$ that matches the policy $\overrightarrow{v}$ (i.e., $\mathcal{F}(\overrightarrow{u},\overrightarrow{v})=0$) as inputs. It first runs $(ps{t}_b,tk{t}_b,dsi{d}_b,V{P}_B,\mathsf{CTX})\leftarrow \mathsf{PriSign}.\mathsf{ObtTkt}\langle \mathsf{U}(us{k}_b,$$up{k}_b,ucre{d}_b,{\left\{m_{b,j}\right\}}_{j\in [1,q]},\mathcal{D},\mathsf{CTX})$$\leftrightarrow \mathsf{I}(isk,ipk,icred)\rangle$, where $b\in \{0,1\}$, then runs $to{k}_b\leftarrow \mathsf{PriSign}.\mathsf{SignOn}(tk{t}_b,dsi{d}_b,V{P}_b,\overrightarrow{u},\overrightarrow{v},mpk)$. Finally, it returns $to{k}_b$.

−${\mathcal{O}}_{{\mathsf{TokHid}}_b}(\{tk{t}_0,dsi{d}_0,V{P}_0\},\{tk{t}_1,dsi{d}_1,V{P}_1\},\overrightarrow{u},vid,$$\overrightarrow{v})$: a challenge oracle in the token-hiding experiment, where the adversary playing as a non-designated ticket verifier $vid$ with the policy $\overrightarrow{v}$ is challenged to distinguish access tokens derived from two different tickets. It takes two tickets $(\{tk{t}_0,dsi{d}_0,V{P}_0\},\{tk{t}_1,dsi{d}_1,V{P}_1\})$, an attribute vector $\overrightarrow{u}$ that does not match the policy $\overrightarrow{v}$ ((i.e., $\mathcal{F}(\overrightarrow{u},\overrightarrow{v})\ne 0$)), and $vid$ as inputs. It runs $to{k}_b\leftarrow \mathsf{PriSign}.\mathsf{SignOn}(tk{t}_b,dsi{d}_b,V{P}_b,\overrightarrow{u},\overrightarrow{v},mpk)$, where $b\in \{0,1\}$, then returns $to{k}_b$.

4.5.1. Unforgeability

The unforgeability of credentials protects honest ticket issuers from malicious users. The adversary wins the game by forging a credential presentation of an honest user or an unregistered user in the $\mathsf{PriSign}.\mathsf{ObtTkt}$ algorithm.

Definition 1 

(Unforgeability of credentials). The unforgeability of credentials is defined by experiment $Ex{p}^{u{f}_{cred}}$ in Figure 2. The users’ credentials are unforgeable if, for any PPT adversary $\mathcal{A}$ having access to the oracles $\mathcal{O}=\{{\mathcal{O}}_{{\mathsf{Reg}}_I},{\mathcal{O}}_{{\mathsf{Reg}}_U},{\mathcal{O}}_{{\mathsf{Cor}}_U},{\mathcal{O}}_{\mathsf{Obt}},{\mathcal{O}}_{{\mathsf{Obt}}_I}\}$, there is a negligible function $ϵ\left(\lambda \right)$ such that

$$\begin{array}{c}\hfill Ad{v}^{u{f}_{cred}}=|Pr\left[Ex{p}^{u{f}_{cred}}(\mathcal{A},\lambda ,q,n,t,k)\right]=1|⩽ϵ\left(\lambda \right)\end{array}$$

The unforgeability of tokens protects ticket verifiers from malicious users. If an adversary can forge a token not issued by the ticket issuer, this wins the game.

Definition 2 

(Unforgeability of tokens). The unforgeability of tokens is defined by experiment $Ex{p}^{u{f}_{tok}}$ in Figure 3. The users’ tokens are unforgeable if, for any PPT adversary $\mathcal{A}$ having access to the oracles $\mathcal{O}=\{{\mathcal{O}}_{{\mathsf{Reg}}_I},{\mathcal{O}}_{{\mathsf{Iss}}_V},{\mathcal{O}}_{{\mathsf{Reg}}_U},{\mathcal{O}}_{{\mathsf{Cor}}_U},{\mathcal{O}}_{\mathsf{Obt}},{\mathcal{O}}_{\mathsf{Sign}}\}$, there is a negligible function $ϵ\left(\lambda \right)$ such that

$$\begin{array}{c}\hfill Ad{v}^{u{f}_{tok}}=|Pr\left[Ex{p}^{u{f}_{tok}}(\mathcal{A},\lambda ,q,n,t,k)\right]=1|⩽ϵ\left(\lambda \right)\end{array}$$

4.5.2. Unlinkability

The unlinkability of credentials protects honest users from a curious ticket issuer. In the PriSign.ObtTkt algorithm, the curious ticket issuer cannot distinguish between the credential presentations of two honest users with non-negligible probability.

Definition 3 

(Unlinkability of credentials). The unlinkability of credentials is defined by experiment $Ex{p}^{un{l}_{cred}-b}$ in Figure 4. The users’ credentials are unlinkable if, for any PPT adversary $\mathcal{A}$ having access to the oracles $\mathcal{O}=\{{\mathcal{O}}_{{\mathsf{Reg}}_I},{\mathcal{O}}_{{\mathsf{Cor}}_I},{\mathcal{O}}_{{\mathsf{Iss}}_V},{\mathcal{O}}_{{\mathsf{Reg}}_U},{\mathcal{O}}_{{\mathsf{Cor}}_U},{\mathcal{O}}_{\mathsf{Obt}},{\mathcal{O}}_{{\mathsf{Obt}}_U}\}$ and ${\mathcal{O}}_{{\mathsf{UnlCred}}_b}$, there is a negligible function $ϵ\left(\lambda \right)$ such that

$$\begin{array}{c}\hfill Ad{v}^{un{l}_{cred}}=\left|Pr\left[Ex{p}^{un{l}_{cred}-1}(\mathcal{A},\lambda ,q,n,t,k)=1\right]-\frac{1}{2}\right|⩽ϵ\left(\lambda \right)\end{array}$$

The unlinkability of tokens protects honest users from curious designated verifiers. In this experiment, the adversary can control all verifiers by querying the oracle ${\mathcal{O}}_{{\mathsf{Cor}}_V}$, and even the designated verifier cannot distinguish the tokens of two honest users with non-negligible probability.

Definition 4 

(Unlinkability of tokens). The unlinkability of tokens is defined by experiment $Ex{p}^{un{l}_{tok}-b}$ in Figure 5. The users’ tokens are unlinkable if, for any PPT adversary $\mathcal{A}$ having access to the oracles $\mathcal{O}=\{{\mathcal{O}}_{{\mathsf{Reg}}_I},{\mathcal{O}}_{{\mathsf{Cor}}_I},{\mathcal{O}}_{{\mathsf{Iss}}_V},{\mathcal{O}}_{{\mathsf{Cor}}_V},{\mathcal{O}}_{{\mathsf{Reg}}_U},{\mathcal{O}}_{{\mathsf{Cor}}_U},{\mathcal{O}}_{\mathsf{Obt}},{\mathcal{O}}_{{\mathsf{Obt}}_U},{\mathcal{O}}_{\mathsf{Sign}}\}$ and ${\mathcal{O}}_{{\mathsf{UnlTok}}_b}$, there is a negligible function $ϵ\left(\lambda \right)$ such that

$$\begin{array}{c}\hfill Ad{v}^{un{l}_{tok}}=\left|Pr\left[Ex{p}^{un{l}_{tok}-1}(\mathcal{A},\lambda ,q,n,t,k)=1\right]-\frac{1}{2}\right|⩽ϵ\left(\lambda \right)\end{array}$$

4.5.3. Token-Hiding

Token-hiding protects honest users from curious non-designated verifiers. In the PriSign.Sign algorithm, any non-designated verifiers cannot distinguish the tokens of two different tickets with non-negligible probability.

Definition 5 

(Token-hiding). Token-hiding is defined by experiment $Ex{p}^{tkh-b}$ in Figure 6. Users’ tokens are hidden if, for any PPT adversary $\mathcal{A}$ having access to the oracles $\mathcal{O}=\{{\mathcal{O}}_{{\mathsf{Reg}}_I},{\mathcal{O}}_{{\mathsf{Cor}}_I},{\mathcal{O}}_{{\mathsf{Iss}}_V},{\mathcal{O}}_{{\mathsf{Reg}}_U},{\mathcal{O}}_{{\mathsf{Cor}}_U},{\mathcal{O}}_{\mathsf{Obt}},{\mathcal{O}}_{{\mathsf{Obt}}_U},{\mathcal{O}}_{\mathsf{Sign}}\}$ and ${\mathcal{O}}_{{\mathsf{TokHid}}_b}$, there is a negligible function $ϵ\left(\lambda \right)$ such that

$$\begin{array}{c}\hfill Ad{v}^{tkh}=\left|Pr\left[Ex{p}^{tkh-1}(\mathcal{A},\lambda ,q,n,t,k)=1\right]-\frac{1}{2}\right|⩽ϵ\left(\lambda \right)\end{array}$$

5. Construction of PriSign

In this section, we provide a detailed description of the PriSign system’s construction.

5.1. Challenges and Intuitions

The schemes described in [33,34,35,36,38] form the basis of our construction; the challenge is to combine and adapt them to ensure that the final scheme satisfies the system and security model proposed in Section 4. As shown in Figure 7, we summarize the dependencies between the building blocks used by PriSign along with a roadmap highlighting our contributions in gray boxes.

First, we construct an attribute-based credential with traceability (ABCT) scheme from the anonymous credential in [34] and utilize it to create users’ credentials. Because our ABCT scheme supports attribute disclosure proofs with unlinkability, the ticket issuer can issue different types of tickets for users according to different selective disclosure policies in the PriSign scheme, thereby realizing fine-grained access control of services. In addition, this enables PriSign to support traceability of users.

Second, we construct an attribute-based credential with blindness (ABCB) scheme from the anonymous credential in [38] and utilize it to issue tokens for users. Our ABCB scheme supports issuing credentials based on both unblinded and blinded attributes simultaneously. Therefore, when issuing a ticket, the double-spending identity of the ticket can be used as the blinded attribute and the ticket’s validity period as the unblinded attribute.

Third, we construct a threshold inner-product functional encryption (TIPFE) scheme from the inner-product functional encryption (IPFE) in [35] and predicate encryption scheme in [36]. We use TIPFE’s encryption algorithm to hide tokens, TIPFE’s inner product predicate as the matching function to designate verifiers, and TIPFE’s threshold key issuance to achieve stable policy key generation for verifiers in cloud environments. Finally, the SPS [33] scheme enables us to implement public key credential issuance of the ticket issuer.

5.2. New Results and Building Blocks

5.2.1. Attribute-Based Credentials with Traceability

We construct an attribute-based credential with traceability (ABCT) scheme from the anonymous credential scheme in [34]. Compared with the original scheme [34], our ABCT scheme is improved in three aspects: (1) we enable users to generate public and private key pairs independently and obtain credentials of attributes set and the public key without disclosing their private keys; (2) we extend the feature to support malicious user identity tracing while protecting user privacy; and (3) we modify the credential presentation algorithm (Show) to support efficient selective disclosure, which is essential to support fine-grained access control.

$-\mathsf{ABCT}.\mathsf{Setup}(1^{\lambda },q)\to pp$: On input of a security parameter $1^{\lambda }$ and a positive integer q, this algorithm generates a bilinear group $\mathcal{BL}=({\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T,$$e,p,g,\tilde{g})$ and sets $pp=(\mathcal{BL},q)$, where q is the attribute number for user.

$-\mathsf{ABCT}.\mathsf{CredKeyGen}\left(pp\right)\to (isk,ipk,\mathcal{L})$: This algorithm is operated by an issuer to generate their public private key pair. The issuer chooses $(x,y_0,\cdots ,y_q)\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$ and computes $\tilde{X}={\tilde{g}}^x$ and ${\tilde{Y}}_i={\tilde{g}}^{y_i}$ for $i\in [0,q]$. Then, it initializes a user registration list $\mathcal{L}=\varnothing$ and outputs a private key $isk=(x,y_0,\cdots ,y_q)$ and public key $ipk=(\tilde{X},{\tilde{Y}}_0,\cdots ,{\tilde{Y}}_q)$.

$-\mathsf{ABCT}.\mathsf{UserKeyGen}\left(pp\right)\to (usk,upk,utk)$: This algorithm is operated by a user to generate their public private key pair. The user chooses a private key $usk\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$, then computes their public key $upk=g^{usk}$ and tracing key $utk={\tilde{g}}^{usk}$.

$-\langle \mathsf{ABCT}.\mathsf{Issue}.\mathsf{U}(uid,usk,upk,utk,{\left\{m_j\right\}}_{j=1}^q)\leftrightarrow$$\mathsf{ABCT}.\mathsf{Issue}.\mathsf{I}(isk,ipk,\mathcal{L})\rangle \to (ucred,{\mathcal{L}}^{\prime })$: This algorithm operates by interacting between a user and an issuer to create an attribute-based credential for the user.

• $\mathsf{ABCT}.\mathsf{PreCred}(uid,usk,upk,utk,{\left\{m_j\right\}}_{j\in [1,q]})\to (uid,{\left\{m_j\right\}}_{j=1}^q,{\mathrm{\Pi }}_1)$: The user computes a ZKSoK ${\mathrm{\Pi }}_1=\mathsf{ZKSoK}\{usk:upk=g^{usk}\wedge utk={\tilde{g}}^{usk}\}$, then sends their identity $uid$, attribute set ${\left\{m_j\right\}}_{j=1}^q$, and ${\mathrm{\Pi }}_1$ to the issuer.
• $\mathsf{ABCT}.\mathsf{SigCed}(isk,ipk,uid,{\left\{m_j\right\}}_{j\in [1,q]},{\mathrm{\Pi }}_1)\to ucred$: After ${\mathrm{\Pi }}_1$ is verified, the issuer chooses $r\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$ and computes ${\sigma }_1=g^r$, ${\sigma }_2={\left(upk\right)}^{r·y_0}{g}^{r·(x+{\sum }_{j=1}^q{m}_j{y}_j)}$. Then, it sets ${\mathcal{L}}^{\prime }=\mathcal{L}\cup (uid,utk)$ and returns $ucred=({\sigma }_1,{\sigma }_2)$.
• $\mathsf{ABCT}.\mathsf{VfyCred}(usk,{\left\{m_j\right\}}_{j\in [1,q]},ucred)\to ucred$: The user accepts the credential $ucred$ if $e({\sigma }_2,\tilde{g})=e({\sigma }_1,\tilde{X}{\tilde{Y}}_0^{usk}{\prod }_{j=1}^q{\tilde{Y}}_j^{m_j})$ holds.

$-\mathsf{ABCT}.\mathsf{Show}(usk,upk,ucred,{\left\{m_j\right\}}_{j=1}^q,\mathcal{D},\mathsf{CTX})\to tok$: This algorithm is operated by a user to anonymously present a credential while disclosing a subset of attributes ${\left\{m_j\right\}}_{j\in \mathcal{D}}$, where $\mathcal{D}\subset [1,q]$. The user chooses $r_1,r_2\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$, computes ${\sigma }_1^{\prime }={\sigma }_1^{r_1},{\sigma }_2^{\prime }={\sigma }_2^{r_1}$, $\mu ={\sigma }_1^{\prime usk},\nu ={\sigma }_1^{\prime r_2},\kappa =\tilde{X}{\prod }_{j\in [1,q]/\mathcal{D}}{\tilde{Y}}_j^{m_j}{\tilde{g}}^{r_2}$, and computes a ZKSoK ${\mathrm{\Pi }}_2=\mathsf{ZKSoK}\left\{\right(usk,r_2,$${\left\{m_j\right\}}_{j\in [1,q]/\mathcal{D}}):\mu ={\sigma }_1^{\prime usk}\wedge \nu ={\sigma }_1^{\prime r_2}\wedge \kappa =\tilde{X}{\prod }_{j\in [1,q]/\mathcal{D}}{\tilde{Y}}_j^{m_j}{\tilde{g}}^{r_2}\}\left(\mathsf{CTX}\right)$. Finally, the user outputs a credential presentation $pst=({\left\{m_j\right\}}_{j\in \mathcal{D}},{\sigma }_1^{\prime },{\sigma }_2^{\prime },\mu ,\nu ,\kappa ,{\mathrm{\Pi }}_2)$. Note that CTX is a random value used to prevent replay attacks.

$-\mathsf{ABCT}.\mathsf{Verify}(ipk,pst,\mathsf{CTX})\to 0/1$: This algorithm is operated by a verifier. The verifier outputs 1 if the user’s attributes ${\left\{m_j\right\}}_{j\in \mathcal{D}}$ satisfy an attribute disclosure policy enforced by the verifier, $e({\sigma }_2^{\prime }\nu ,\tilde{g})=e({\sigma }_1^{\prime },\kappa {\prod }_{j\in \mathcal{D}}{\tilde{Y}}_j^{m_j})e(\mu ,{\tilde{Y}}_0)$, and ${\mathrm{\Pi }}_2$ is verified, and outputs 0 otherwise.

$-\mathsf{ABCT}.\mathsf{Trace}(ipk,pst,\mathsf{CTX},\mathcal{L})\to uid/\perp$: This algorithm is operated by the issuer to trace the identity of a user who generates the presentation $pst$. The issuer outputs $uid$ if there exists a tuple $(uid,utk)$ in $\mathcal{L}$ satisfying $e(\mu ,\tilde{g})=e({\sigma }_1^{\prime },utk)$; otherwise, it outputs ⊥.

The details of the ZKSoK and the correctness analysis of our ABCT scheme are shown in Supplemental Material B. Naturally, our ABCT scheme satisfies the unlinkability and unforgeability the same as the anonymous credential scheme in [34]. In this paper, we use the ABCT scheme to issue a credential for the public key and attributes set of a user.

5.2.2. Attribute-Based Credentials with Blindness

We construct an attribute-based credential with blindness (ABCB) scheme by making two crucial modifications to the anonymous credential in [38]: (1) we streamline the threshold issuance functionality of the original scheme to ensure that there is only one issuer in the ABCB scheme and (2) we extend it to support both blind issuing of user attributes and adding non-blind attributes to user credentials by the issuer in the issuing credential algorithm. In short, attributes of user credentials can come from both user and issuer, and attributes from the user are hidden from the issuer.

$-\mathsf{ABCB}.\mathsf{Setup}(1^{\lambda },l)\to pp$: On input of a security parameter $1^{\lambda }$ and a positive integer l, this algorithm generates a bilinear group $\mathcal{BL}=({\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T,$$e,p,g,\tilde{g})$ and sets $pp=(\mathcal{BL},l)$.

$-\mathsf{ABCB}.\mathsf{CredKeyGen}\left(pp\right)\to (isk,ipk)$: The issuer chooses $(a,b_1,\cdots ,b_l)\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$, then computes $\tilde{A}={\tilde{g}}^a$ and ${\tilde{B}}_i={\tilde{g}}^{b_i},B_i=g^{b_i}$ for $i\in [1,l]$. Then, it outputs a private key $isk=(a,b_1,\cdots ,b_l)$ and public key $ipk=(\tilde{A},{\tilde{B}}_1,\cdots ,{\tilde{B}}_l,B_1,\cdots ,B_l)$.

$-\langle \mathsf{ABCB}.\mathsf{Issue}.\mathsf{U}\left({\left\{m_j\right\}}_{j\in [1,l^{\prime }]}\right)\leftrightarrow$$\mathsf{ABCB}.\mathsf{Issue}.\mathsf{I}(isk,$$ipk,{\left\{m_j\right\}}_{j\in [l^{\prime }+1,l]})\rangle \to ucred$: This algorithm is used to issue attribute-based credentials for users, with attributes consisting of two parts: (1) attributes that the user owns are hidden from the issuer ${\left\{m_j\right\}}_{j\in [1,l^{\prime }]}$ and (2) attributes that the issuer adds to the user ${\left\{m_j\right\}}_{j\in [l^{\prime }+1,l]}$.

• $\mathsf{ABCB}.\mathsf{PreBlind}({\left\{m_j\right\}}_{j\in [1,l^{\prime }]},\mathsf{CTX})\to (d,C)$: The user chooses a secret key $d\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$, then computes a public key $D=g^d$ and a group element $h={\mathsf{HASH}}^{\prime }(\mathsf{CTX},D)\in {\mathbb{G}}_1$, chooses a random $(r_1,r_2,\cdots ,r_{l^{\prime }})\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$, and computes the ElGamal encryption for each $m_j$ ($j\in [1,l^{\prime }]$): $C_j=(C_{j,0},C_{j,1})\leftarrow (g^{r_j},D^{r_j}{h}^{m_j})$. The user computes a ZKSoK ${\mathrm{\Pi }}_3=\mathsf{ZKSoK}\{(d,r_1,\cdots ,r_{l^{\prime }},m_1,\cdots ,m_{l^{\prime }}):D=g^d,C_j=(g^{r_j},D^{r_j}{h}^{m_j})$$\forall j\in [1,l^{\prime }]\}$ and sets $C=(C_1,\cdots ,C_{l^{\prime }},{\mathrm{\Pi }}_3,D)$.
• $\mathsf{ABCB}.\mathsf{BlindSign}(isk,ipk,C,{\left\{m_j\right\}}_{j\in [l^{\prime }+1,l]},\mathsf{CTX})\to {\tau }^{\prime }$: After ${\mathrm{\Pi }}_3$ is verified, the issuer recomputes $h={\mathsf{HASH}}^{\prime }(\mathsf{CTX},D)$ and returns ${\tau }^{\prime }=({\tau }_1^{\prime },{\tau }_2^{\prime })$, where ${\tau }_1^{\prime },{\tau }_2^{\prime }$ are computed as follows: ${\tau }_1^{\prime }=h^a{\prod }_{j=1}^{l^{\prime }}{C}_{j,1}^{b_j}·h^{{\sum }_{j=l^{\prime }+1}^l{b}_j{m}_j},{\tau }_2^{\prime }={\prod }_{j=1}^{l^{\prime }}{C}_{j,0}^{b_j}$.
• $\mathsf{ABCB}.\mathsf{Unblind}(d,{\tau }^{\prime },{\left\{m_j\right\}}_{j\in [1,l]})\to ucred$.
  The user computes ${\tau }_1=h,{\tau }_2={\tau }_1^{\prime }{\tau }_2^{\prime -d}$ and sets $ucred=({\tau }_1,{\tau }_2)$. The user accepts the credential $ucred$ if $e({\tau }_2,\tilde{g})=e({\tau }_1,\tilde{A}{\prod }_{j=1}^l{\tilde{B}}_j^{m_j})$ holds.

$-\mathsf{ABCB}.\mathsf{Show}(ucred,{\left\{m_j\right\}}_{j=1}^l,\mathcal{D})\to tok$: The user chooses $r_1,r_2\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$, computes ${\tau }_1^{\prime }={\tau }_1^{r_1},{\tau }_2^{\prime }={\tau }_2^{r_1}$, ${\nu }^{\prime }={\tau }_1^{\prime r_2},{\kappa }^{\prime }=\tilde{A}{\prod }_{j\in [1,l]/\mathcal{D}}{\tilde{B}}_j^{m_j}{\tilde{g}}^{r_2}$, and computes a ZKSoK ${\mathrm{\Pi }}_4=\mathsf{ZKSoK}\left\{\right(r_2,$${\left\{m_j\right\}}_{j\in [1,l]/\mathcal{D}}):{\nu }^{\prime }={\tau }_1^{\prime r_2}\wedge {\kappa }^{\prime }=\tilde{A}{\prod }_{j\in [1,l]/\mathcal{D}}{\tilde{B}}_j^{m_j}{\tilde{g}}^{r_2}\}$. The user outputs a token $tok=({\left\{m_j\right\}}_{j\in \mathcal{D}},{\tau }_1^{\prime },{\tau }_2^{\prime },{\nu }^{\prime },{\kappa }^{\prime },{\mathrm{\Pi }}_4)$.

$-\mathsf{ABCB}.\mathsf{Verify}(ipk,tok)\to 0/1$: The verifier outputs 1 if the user’s attributes ${\left\{m_j\right\}}_{j\in \mathcal{D}}$ satisfy an attribute disclosure policy enforced by the verifier, $e({\tau }_2^{\prime }{\nu }^{\prime },\tilde{g})=e({\tau }_1^{\prime },{\kappa }^{\prime }{\prod }_{j\in \mathcal{D}}{\tilde{B}}_j^{m_j})$, and ${\mathrm{\Pi }}_4$ is verified; otherwise, it outputs 0.

The details of the ZKSoK and the correctness analysis of our ABCB scheme are shown in Supplemental Material C. Naturally, our ABCB scheme satisfies the unlinkability, unforgeability, and blindness requirements, the same as the anonymous credential scheme in [38]. In this paper, we use the ABCB scheme to create tickets for users.

5.2.3. Threshold Inner-Product Functional Encryption

Threshold inner-product functional encryption (TIPFE) is inspired by Inner-product functional encryption (IPFE) [35]. First, we realize the threshold key extraction algorithm using the linear feature of IPFE’s key extraction algorithm. Of course, this modification sacrifices its traceability, which is unnecessary in this application. Second, we use the transformation in [36] to convert the predicate-only scheme into a full-fledged predicate encryption scheme.

$-\mathsf{TIPFE}.\mathsf{Setup}(\mathcal{BL},n,t,k)\to (pk,sk)$: This algorithm is operated by a central authority to generate public parameters and a master key pair for the system.

• Set $pp=(\mathcal{BL},n,t,k)$
• Randomly choose $sk=(s_1,s_2,\cdots ,s_k,e)\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$
• Compute $G=e(g,\tilde{g})$, $P=G^e$ and $H_i=G^{s_i},$$i\in [1,k]$, and set $pk=(G,P,H_1,H_2,\cdots ,$$H_k)$

$-\mathsf{TIPFE}.\mathsf{IssKey}(pk,sk,n,t)\to \left({\{s{k}_i,p{k}_i\}}_{i=1}^n\right):$ This algorithm is operated by the central authority to issue shared keys for n policymakers, where t policymakers cooperate to recover the master key.

• Choose $k+1$ polynomials of degree $t-1$ with coefficients in ${\mathbb{Z}}_p^{*}$, denoted as $f_1,f_2,$$\cdots ,f_k,f_e$, and set $f_1\left(0\right)=s_1,f_2\left(0\right)=s_2,\cdots ,f_k\left(0\right)=s_k,f_e\left(0\right)=e$
• Compute $s_{i,j}=f_j\left(i\right)$ and $e_i=f_e\left(i\right)$ where $i\in [1,n],j\in [1,k]$, and set $s{k}_i=(s_{i,1},s_{i,2},\cdots ,s_{i,k},e_i)$
• Compute $P_i=G^{e_i},H_{i,j}=G^{s_{i,j}}$ where $i\in [1,n],j\in [1,k]$, and set $p{k}_i=(G,P_i,H_{i,1},H_{i,2},$$\cdots ,H_{i,k})$

$-\mathsf{TIPFE}.\mathsf{Extract}(s{k}_i,id,\overrightarrow{v})\to d{k}_{id,\overrightarrow{v},i}$: This algorithm is operated by a policymaker i to issue a share of a policy key for a receiver with identity $id$ and a characteristic vector $\overrightarrow{v}$.

• Set ${\overrightarrow{s}}_i=(s_{i,1},s_{i,2},\cdots s_{i,k})$ and compute ${\theta }_{id}=\mathsf{HASH}\left(id\right)$
• Compute $d{k}_{id,\overrightarrow{v},i}={\tilde{g}}^{<{\overrightarrow{s}}_i,\overrightarrow{v}>+e_i{\theta }_{id}}={\tilde{g}}^{{\sum }_{j=1}^k{s}_{i,j}{v}_j+e_i{\theta }_{id}}$

$-\mathsf{TIPFE}.\mathsf{KeyAgg}(id,\overrightarrow{v},{\{d{k}_{id,\overrightarrow{v},i},p{k}_i\}}_{i\in [1,t]})\to d{k}_{id,\overrightarrow{v}}$: This algorithm is operated by a receiver to aggregate t received shares of policy keys into a compact policy key.

• For each $i\in [1,t]$, check $e(g,d{k}_{id,\overrightarrow{v},i})=P_i^{{\theta }_{id}}{\prod }_{j=1}^k{H}_{i,j}^{v_j}$
• For each $i\in [1,t]$, compute ${\lambda }_i=\left[{\prod }_{j\in [1,t],j\ne i}\left(j\right)\right]{\left[{\prod }_{j\in [1,t],j\ne i}(j-i)\right]}^{-1}$
• Compute $d{k}_{id,\overrightarrow{v}}={\prod }_{i\in [1,t]}d{k}_{id,\overrightarrow{v},i}^{{\lambda }_i}$

$-\mathsf{TIPFE}.\mathsf{Enc}(pp,pk,\overrightarrow{u},M)\to CT.$ This algorithm is operated by a sender to encrypt a message M with an attribute vector $\overrightarrow{u}$.

• Randomly choose $r\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$, then compute $C_0=M·P^r$
• Compute $C_1=g^r,C_2=(H_1^r{G}^{u_1},H_2^r{G}^{u_2},\cdots ,$$H_1^r{G}^{u_k})$
• Set $CT=(C_0,C_1,C_2)$

$-\mathsf{TIPFE}.\mathsf{Dec}(pp,id,t{k}_{id,\overrightarrow{v}},CT)\to M$: This algorithm is operated by a receiver to decrypt the ciphertext using a policy key.

• If $<\overrightarrow{u},\overrightarrow{v}>=0$, compute $M=C_0·{\left(\frac{{\prod }_{j=1}^k{C}_{2,j}^{v_j}}{e(C_1,t{k}_{id,\overrightarrow{v}})}\right)}^{{\theta }_{id}^{-1}}$

Theorem 1. 

Our TIPFE scheme satisfies attribute-hiding under the BDDH assumption.

The correctness analysis and formal proof of our TIPFE scheme are provided in Supplemental Material D. In this paper, we use the TIPFE scheme to achieve token-hiding and proxy re-verification.

5.3. Concrete Construction

In this section, we present a concrete instantiation of the PriSign scheme based on the ABCT scheme in Section 5.2.1, the ABCB scheme in Section 5.2.2, the TIPFE scheme in Section 5.2.3, and Groth’s SPS scheme [33].

• $\mathsf{PriSign}.\mathsf{Setup}(1^{\lambda },q,n,t,k)\to (pp,msk,mpk,\mathcal{L})$: As shown in Figure 8, CA runs $\mathsf{BlGen}$ to generate public parameters (a Type-III bilinear group) for other algorithms of PriSign scheme, runs $\mathsf{Groth}.\mathsf{KeyGen}$ to generate keys used to issue public-key credentials for issuers, runs $\mathsf{ABCT}.\mathsf{CredKeyGen}$ to generate keys used to issue attribute-based credentials for users, and runs $\mathsf{TIPFE}.\mathsf{Setup}$ to generate the keys used to issue keys for policymakers. Finally, it sets the public parameters $pp$, master secret key $msk$, master public key $mpk$, and user registration list $\mathcal{L}$.
• $\mathsf{PriSign}.\mathsf{IssuerKeyGen}\left(\right)\to (isk,ipk)$: The ticket issuer runs $(isk,ipk)\leftarrow \mathsf{ABCB}.\mathsf{CredKey}$$\mathsf{Gen}\left(pp\right)$ to generate its secret key $isk$ and public key $ipk$ used to issue tickets for users.
• $\mathsf{PriSign}.\mathsf{IssuerReg}\langle \mathsf{I}(isk,ipk)\leftrightarrow \mathsf{CA}(msk,mpk)\rangle \to icred/\perp$: As shown in Figure 9, CA computes an SPS signature on the issuer’s public key and treats it as the issuer’s credential. The details of ${\mathrm{\Pi }}_5$ are shown in Supplemental Material E.2.
• $\mathsf{PriSign}.\mathsf{PolMakKeyGen}(msk,mpk)\to \left(\right\{ps{k}_i,$$pv{k}_i{\}}_{i\in [1,n]})$: CA runs $\left({\{ps{k}_i,pp{k}_i\}}_{i\in [1,n]}\right)$$\leftarrow \mathsf{TIPFE}.\mathsf{IssKey}(mp{k}_p,ms{k}_p,n,t)$ to generate keys for all policymakers.
• $\mathsf{PriSign}.\mathsf{IssPolKey}(ps{k}_i,vid,\overrightarrow{v})\to t{k}_{vid,\overrightarrow{v},i}$: The policymaker i runs $d{k}_{vid,\overrightarrow{v},i}\leftarrow \mathsf{TIPFE}.$$\mathsf{Extract}(ps{k}_i,vid,\overrightarrow{v})$ to issue a share of the policy key to a verifier with identity $vid$ and policy $\overrightarrow{v}$.
• $\mathsf{PriSign}.\mathsf{AggrPolKey}(vid,\overrightarrow{v},{\{d{k}_{vid,i},mp{k}_i\}}_{i\in [1,t]})\to t{k}_{vid,\overrightarrow{v}}$: The verifier $vid$ runs $d{k}_{vid,\overrightarrow{v}}$$\leftarrow \mathsf{TIPFE}.\mathsf{KeyAgg}(vid,$${\{d{k}_{vid,\overrightarrow{v},i},pv{k}_i\}}_{i\in [1,t]})$ to obtain a compact policy key.
• $\mathsf{PriSign}.\mathsf{UserKeyGen}\left(pp\right)\to (usk,upk,utk)$: A user runs $(usk,upk,utk)\leftarrow \mathsf{ABCT}.$$\mathsf{UserKeyGen}\left(pp\right)$ to create their private key, public key, and tracing key.
• $\mathsf{PriSign}.\mathsf{UserReg}\langle \mathsf{U}(uid,usk,upk,utk,{\left\{m_j\right\}}_{j\in [1,q]})\leftrightarrow \mathsf{CA}(msk,mpk,\mathcal{L})\rangle \to (ucred,{\mathcal{L}}^{\prime })$$/\perp$: CA and a user run $(ucred,{\mathcal{L}}^{\prime })\leftarrow \langle \mathsf{ABCT}.\mathsf{Issue}.\mathsf{U}(uid,usk,upk,utk,{\left\{m_j\right\}}_{j=1}^q)$$\leftrightarrow \mathsf{ABCT}.$$\mathsf{Issue}.\mathsf{I}(ms{k}_u,mp{k}_u,\mathcal{L})\rangle$ to create a credential for the user.
• $\mathsf{PriSign}.\mathsf{ObtTkt}\langle \mathsf{U}(usk,upk,ucred,{\left\{m_j\right\}}_{j\in [1,q]},\mathcal{D},\mathsf{CTX})$$\leftrightarrow \mathsf{I}(isk,ipk,icred)\rangle \to (pst,tkt,$$dsid,VP)/\perp$: As shown in Figure 10, I computes a ZKSoK ${\mathrm{\Pi }}_5$ to prove to the user that it has been authenticated by CA. After verifying I’s ${\mathrm{\Pi }}_5$ and credential $icred$, U computes a credential presentation $pst$ by executing $\mathsf{ABCT}.\mathsf{Show}$, then randomly selects a double-spend identity for the ticket, blinds it by executing $\mathsf{ABCB}.\mathsf{PreBlind}$, and sends $(pst,C)$ to I. I verifies the correctness of the user credential and chooses a validity period $VP$ for the ticket, then computes a ticket ${\tau }^{\prime }$ by executing $\mathsf{ABCB}.\mathsf{BlindSign}$ and returns $({\tau }^{\prime },VP)$. Finally, the user restores the ticket $tkt$ by executing $\mathsf{ABCB}.\mathsf{UnBlind}$.
• $\mathsf{PriSign}.\mathsf{Trace}(msk,\mathcal{L},pst)\to uid/\perp$: CA runs $uid\leftarrow \mathsf{ABCT}.\mathsf{Trace}(mp{k}_u,pst,\mathsf{CTX},\mathcal{L})$ to trace the user’s identity.
• $\mathsf{PriSign}.\mathsf{SignOn}(tkt,dsid,VP,\overrightarrow{u},\overrightarrow{v},mpk)\to tok/\perp$: As shown in Figure 11, U computes a ticket presentation $to{k}^{\prime }$ by executing $\mathsf{ABCB}.\mathsf{Show}$, then randomly selects an encryption key K and encrypts the presentation information $(to{k}^{\prime },dsid,VP,ipk)$ using the AES-CTR algorithm [39,40] to achieve token-hiding. Finally, U encrypts K using the attribute vector $\overrightarrow{u}$ that matches the policy $\overrightarrow{v}$, i.e., $<\overrightarrow{u},\overrightarrow{v}>=0$, to achieve designated verification, and returns $tok=(CM,CT)$.
• $\mathsf{PriSign}.\mathsf{Verify}(vid,tok,t{k}_{vid,\overrightarrow{v}},mpk)\to 0/1:$ As shown in Figure 12, the designated verifier with policy key $t{k}_{vid,\overrightarrow{v}}$ recovers key K by executing $\mathsf{TIPFE}.\mathsf{Dec}$ and decrypts the ticket presentation information $(to{k}^{\prime },dsid,VP,ipk)$ using the AES-CTR algorithm. Then, it checks whether $VP$ is within the validity period and checks all tickets with the same $dsid$ in the history to detect whether the ticket is double-spending. Finally, V verifies the correctness of the ticket presentation by executing $\mathsf{ABCB}.\mathsf{Verify}$.

6. Security Analysis

We define the following theorems to formalize that our construction satisfies all the desired security arrangements.

Theorem 2. 

Our PriSign scheme is correct.

Proof. 

Naturally, if the ABCT scheme, the ABCB scheme, the TIPFE scheme, and Groth’s SPS scheme satisfy correctness, then our PriSign scheme is correct. □

Theorem 3. 

Our PriSign scheme satisfies the unforgeability of credentials if the SDL assumption holds and the PS signature is unforgeable.

Proof. 

The proof is provided in Supplemental Material E.3.1. □

Theorem 4. 

Our PriSign scheme satisfies the unforgeability of tokens if the PS signature is unforgeable.

Proof. 

The proof is provided in Supplemental Material E.3.2. □

Theorem 5. 

Our PriSign scheme satisfies the unlinkability of credentials if the DDH assumption holds in ${\mathbb{G}}_1$.

Proof. 

The proof is provided in Supplemental Material E.3.3. □

Theorem 6. 

Our PriSign scheme satisfies the unlinkability of tokens if the ABCB scheme satisfies the same.

Proof. 

The proof is provided in Supplemental Material E.3.4. □

Theorem 7. 

Our PriSign scheme satisfies token-hiding if the TIPFE scheme satisfies attribute-hiding and the AES-CTR algorithm is CPA-secure.

Proof. 

In the PriSign.SignOn algorithm, we use the AES-CTR algorithm to hide the presentation of tickets and the TIPFE scheme to hide the AES encryption key. According to the definitions of attribute-hiding and CPA-secure, it can be directly concluded that our scheme is token-hiding. □

7. Performance Analysis

In this section, we present a performance analysis of PriSign from both the theoretical and experimental aspects.

7.1. Theoretical Analysis

In

Table 4. Computation overhead.

Algorithms	PriSign	[9]	[8]
Setup	$3t_{e_1}+(q+2)3·t_{e_2}+(k+1)3·t_{e_T}+13·t_{e_p}$	$1t_{e_1}+1t_{e_2}$	$1t_{e_2}$
IssuerReg.I	$11t_{e_1}+5t_{e_2}+2t_{e_p}$	$2t_{e_1}+2t_{e_2}+2t_{e_p}$	$2t_{e_1}+1t_{e_2}+2t_{e_p}$
IssuerReg.CA	$11t_{e_1}$	$2t_{e_1}$	$2t_{e_1}$
IssPolKey	$1t_{e_2}$	−	−
AggrPolKey	$t·t_{e_2}+t·k·t_{e_T}+t·t_{e_p}$	−	−
UserReg.U	$2t_{e_1}+(q+3)t_{e_2}+2t_{e_p}$	$2t_{e_1}+1t_{e_2}+2t_{e_p}$	$2t_{e_1}+1t_{e_2}+2t_{e_p}$
UserReg.CA	$3t_{e_1}$	$2t_{e_1}$	$2t_{e_1}$
ObtTkt.U	$17t_{e_1}+2(q-I+2)t_{e_2}+2t_{e_p}$	$(22+5J)t_{e_1}+2t_{e_2}+4t_{e_p}$	$(16+7J)t_{e_1}+2t_{e_2}+4t_{e_p}$
ObtTkt.I	$15t_{e_1}+(q+2)t_{e_2}+2t_{e_p}$	$(19+5J)t_{e_1}+3t_{e_p}$	$(17+5J)t_{e_1}+2t_{e_p}$
SignOn	$3t_{e_1}+(2k+1)t_{e_T}$	$6t_{e_1}$	$3t_{e_1}$
Verify	$2t_{e_2}+(k+1)t_{e_T}+3t_{e_p}$	$7t_{e_1}+1t_{e_2}+3t_{e_p}$	$8t_{e_1}+1t_{e_2}+2t_{e_p}$

J: the number of designated verifiers.

and

Table 5. Storage overhead.

Variates	PriSign	[9]	[8]
$msk$	$(q+k+6)|{\mathbb{Z}}_p|$	$2|{\mathbb{Z}}_p|$	$1|{\mathbb{Z}}_p|$
$mpk$	$3|{\mathbb{G}}_1|+(q+3)|{\mathbb{G}}_2|+(k+2)|{\mathbb{G}}_T|$	$6|{\mathbb{G}}_1|+4|{\mathbb{G}}_1|$	$4|{\mathbb{G}}_1|+2|{\mathbb{G}}_1|$
$isk$	$3|{\mathbb{Z}}_p|$	$1|{\mathbb{Z}}_p|$	$1|{\mathbb{Z}}_p|$
$ipk$	$2|{\mathbb{G}}_1|+3|{\mathbb{G}}_2|$	$1|{\mathbb{G}}_1|+1|{\mathbb{G}}_2|$	$1|{\mathbb{G}}_1|$
$icred$	$2|{\mathbb{G}}_1|$	$2|{\mathbb{Z}}_p|+1|{\mathbb{G}}_1|$	$2|{\mathbb{Z}}_p|+1|{\mathbb{G}}_1|$
$usk$	$1|{\mathbb{Z}}_p|$	$1|{\mathbb{Z}}_p|$	$1|{\mathbb{Z}}_p|$
$upk$	$1|{\mathbb{G}}_1|$	$1|{\mathbb{G}}_1|$	$1|{\mathbb{G}}_1|$
$ucred$	$2|{\mathbb{G}}_1|$	$2|{\mathbb{Z}}_p|+1|{\mathbb{G}}_1|$	$2|{\mathbb{Z}}_p|+1|{\mathbb{G}}_1|$
$pst$	$(q-I+3)|{\mathbb{Z}}_p|+4|{\mathbb{G}}_1|+1|{\mathbb{G}}_2|$	$(6+J)|{\mathbb{Z}}_p|+(9+6J)|{\mathbb{G}}_1|$	$(6+J)|{\mathbb{Z}}_p|+(9+6J)|{\mathbb{G}}_1|$
$tkt$	$2|{\mathbb{Z}}_p|+2|{\mathbb{G}}_1|$	$6|{\mathbb{Z}}_p|+8|{\mathbb{G}}_1|+1|{\mathbb{G}}_T|$	$6|{\mathbb{Z}}_p|+9|{\mathbb{G}}_1|$
$tok$	$2|{\mathbb{Z}}_p|+3|{\mathbb{G}}_1|+2|{\mathbb{G}}_T|$	$6|{\mathbb{Z}}_p|+12|{\mathbb{G}}_1|+1|{\mathbb{G}}_T|$	$6|{\mathbb{Z}}_p|+10|{\mathbb{G}}_1|$

J: the number of designated verifiers.

, the proposed PriSign system is compared with state-of-the-art ASSO systems [8,9] in terms of computation and storage overheads. Let $|{\mathbb{G}}_1|$, $|{\mathbb{G}}_2|$,$|{\mathbb{G}}_T|$ and $|{\mathbb{Z}}_p|$ be the element sizes in group ${\mathbb{G}}_1$, ${\mathbb{G}}_2$, ${\mathbb{G}}_T$ and ${\mathbb{Z}}_p$, respectively; here, $t_{e_1}$, $t_{e_2}$, $t_{e_T}$ and $t_p$ represent the time cost for the exponential in group ${\mathbb{G}}_1$, ${\mathbb{G}}_2$, ${\mathbb{G}}_T$ and the pairing computations, respectively.

Table 4 presents the storage cost of the algorithms in our PriSign system, including Setup, IssuerReg.I, IssuerReg.CA, IssPolKey, AggrPolKey, UserReg.U, UserReg.CA, ObtTkt.U, ObtTkt.I, SignOn, and Verify. Because the systems in [8,9] do not support policy issuing with thresholds, the performance comparison does not include IssPolKey and AggrPolKey. As shown in Table 4, even though our scheme supports token-hiding and designating verifiers, it is nonetheless able to achieve constant complexity $O\left(1\right)$ of service access (SignOn) and verification (Verify) under the selected parameter k. In addition, it takes only a single exponentiation operation in ${\mathbb{G}}_2$ for a policymaker to generate a policy key for a verifier (IssPolKey); while the computational complexity of the aggregate key is linear ($O\left(t\right)$) to the threshold value (AggrPolKey), t is fortunately small in actual deployments. Because the systems in [8,9] do not support attribute-based fine-grained access control, the computational cost of obtaining tickets and sign-on in their systems is independent of q. Obviously, when $q=0,J=1$, the computational cost of our system is close to that of the systems in [8,9].

Table 5 presents the computation cost of the algorithms in our PriSign system, including $msk$, $mpk$, $isk$, $ipk$, $icred$, $usk$, $upk$, $ucred$, $pst$, $tkt$, and $tok$. As shown in Table 5, the user credential $ucred$, ticket seller credential $icred$, ticket $tkt$, and access token $tok$ all have constant size in the PriSign scheme. The storage overhead primarily consists of the mast public key $mpk$, for which it is only necessary to store one copy for each user. In addition, when $q=0,J=1$ the storage cost of our system is close to that of the systems in [8,9], even with our system’s has additional support for token-hiding and policy issuing with thresholds.

7.2. Experimental Analysis

We implemented the PriSign scheme using MIRACL [41], Type-III pairing [32], and the Barreto-Naehrig curve (BN-256) [42], and tested the system’s performance at the AES-100 bit security level. The source code of our implementation is available at [10]. We ran our implementation on a personal laptop (HUAWEI Matebook 14) with an AMD Ryzen-5 4600H with a Radeon Graphics 3.00 GHz CPU, 16GB RAM, and 512GB SSD running the Ubuntu Kylin 16.04 operating system.

In Figure 13 and Figure 14, we show the computational and storage overheads of all algorithms at $q=10,I=3,n=5,t=3,k=5$, where each timing result is computed as the average over ten iterations.

As shown in Figure 13, the Setup algorithm in the PriSign scheme takes 53.2 s. For ticket seller registration, IssuerReg.I and IssuerReg.CA cost 85.2 ms and 18.6 ms, respectively. For policy key generation, IssPolKey and AggrPolKey cost 1.5 ms and 47.3 ms, respectively. For user registration, UserReg.U and UserReg.CA cost 13.2 ms and 6.2 ms, respectively. The most frequently used PriSign algorithms are ObtTkt, SignOn, and Verify. When obtaining a ticket, ObtTkt.U and ObtTkt.I cost 55.5 ms and 55.2 ms, respectively, while when accessing the service, SignOn and Verify cost 37.6 ms and 36.6 ms, respectively. The algorithm that consumes the most time is IssuerReg.I, which takes 85.2 ms; fortunately, it only needs to be executed once for each new issuer. In the algorithm for obtaining tickets, the time required by the user and the issuer is similar, at about 55 ms, while in the sign-on algorithm the time consumed by the user and the verifier is about 37 ms. The above conclusions are consistent with the results in Table 4. In practice, this millisecond time consumption is very friendly to both users and the server.

As shown in Figure 14, for the CA, the storage of private key $msk$ and public parameters $mpk$ in the PriSign scheme takes 840 bytes and 7616 bytes, respectively. For the issuer, the storage of the private key $isk$, public key $mpk$, and credential $icred$ takes 120 bytes, 1072 bytes, and 256 bytes, respectively. For the user, the storage of the private key $usk$, public key $upk$, and credential $ucred$ takes 40 bytes, 128 bytes, and 256 bytes, respectively. For obtaining tickets, the storage of the presentation and ticket takes 1184 bytes and 336 bytes, respectively. For the sign-on protocol, the storage of the token $tok$ takes 1520 bytes. We note that all storage consumption values are byte scale, which is not a burden on the users or the server.

In order to evaluate the performance in a real test, we compared the execution time with the system in [8,9]. In order to fairly compare performance, we used the following settings during testing: (1) because the systems in [8,9] do not support attribute-based fine-grained access control, we set $q=0$ and $I=0$ in the experiment; (2) because the systems in [8,9] require a fixed number of designated verifiers while ours does not need this to be specified, we set $J=1$ in the experiment; (3) the remaining parameters were set as $n=5,t=3,k=5$.

As shown in Figure 15, we compared the ObtTkt.U algorithm in our system to the systems in [8,9]. The computational overheads are 43.4 ms, 62.1 ms, and 65.5 ms, respectively, for our system and the systems in [8,9]. Our system is 30% faster than the system in [8] and 33.8% faster than the system in [9].

As shown in Figure 16, we compared the ObtTkt.I algorithm in our system with the systems in [8,9]. The computational overheads are 36.9 ms, 37.2 ms, and 48.9 ms, respectively, for our system and the systems in [8,9]. Our system performs as well as the system in [8], and is 24% faster than the system in [9].

As shown in Figure 17, we compared the SignOn algorithm in our system with the systems in [8,9]. The computational overheads are 45.2 ms, 2.3 ms, and 4.5 ms, respectively, for our system and the systems in [8,9]. Our system is required to perform TIPFE encryption operations due to the need to support token-hiding, resulting in higher computing consumption than the systems in [8,9]. However, our computing costs are nonetheless on the second scale, and as such are suitable for deployment in real-world applications.

As shown in Figure 18, we compared the Verify algorithm in our system with the systems in [8,9]. The computational overheads are 59.3 ms, 29.1 ms, and 38.7 ms, respectively, for our system and the systems in [8,9]. Although our system has a higher computational cost due to its support for token-hiding, the execution efficiency is nonetheless at the same level as the systems in [8,9], making it suitable for real-world applications.

8. Conclusions

In this paper, we introduce the notion of PriSign to solve the problem of fine-grained access control, token-hiding, and stability of verification services for cloud environments in an ASSO system. First, we redefine the system model of PriSign and provide formal security definitions, including unforgeability, unlinkability, and token-hiding. Second, we provide a concrete construction using the ABCT scheme from Section 5.2.1, the ABCB scheme from Section 5.2.2, the TIPFE scheme from Section 5.2.3, and the SPS signature scheme in [33]. Finally, we provide formal security definitions and proofs and describe our implementation of the algorithms used in the PriSign scheme on a personal laptop to demonstrate its practicability.

Note that there is a relatively higher computing overhead due to our adoption of TIPFE for token-hiding and policy issuing. To further address this problem, we intend to explore new efficient construction schemes for TIPFE in the future along with other approaches for achieving token-hiding.