Anonymous Single Sign-on with Proxy Re-Verification

11/19/2018
by   Jinguang Han, et al.
0

An anonymous Single Sign-On (ASSO) scheme allows users to access multiple services anonymously using one credential. We propose a new ASSO scheme, where users can access services anonymously through the use of anonymous credentials and unlinkably through the provision of designated verifiers. Notably, verifiers cannot link service requests of a user even if they collude. The novelty is that when a designated verifier is unavailable, a central authority can authorise new verifiers to authenticate the user on behalf of the original verifier. Furthermore, if required, a central verifier is authorised to deanonymise users and trace their service requests. We formalise the scheme along with a security proof and provide an empirical evaluation of its performance. This scheme can be applied to smart ticketing where minimising the collection of personal information of users is increasingly important to transport organisations due to privacy regulations such as General Data Protection Regulations (GDPR).

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

04/19/2018

Anonymous Single-Sign-On for n designated services with traceability

Anonymous Single-Sign-On authentication schemes have been proposed to al...
09/11/2021

A Privacy-Preserving Logistics Information System with Traceability

Logistics Information System (LIS) is an interactive system that provide...
04/23/2018

It is Free and Always Will Be - Trading Personal Information and Privacy for the Convenience of Online Services

Internet users today are constantly giving away their personal informati...
12/02/2020

Analysis of a Decentralised Digital Token Architecture for Public Transport

Digitisation is often viewed as beneficial to a user. Where originally p...
06/01/2021

Intermittent Private Information Retrieval with Application to Location Privacy

We study the problem of intermittent private information retrieval with ...
11/27/2018

3PS - Online Privacy through Group Identities

Limiting online data collection to the minimum required for specific pur...
02/08/2018

Open Data, Grey Data, and Stewardship: Universities at the Privacy Frontier

As universities recognize the inherent value in the data they collect an...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Single Sign-On (SSO) is a mechanism that enables a user to access multiple services using only one credential. Existing SSO solutions include OpenID [1], SAML [2], and Kerberos [3], etc. SSO systems can reduce a user’s burden on maintaining authentication credentials.

In order to protect users’ privacy, anonymous SSO (ASSO) systems were proposed in [4, 5, 6, 7]. In these systems, a user’s personal identifiable information (PII) was addressed, but the unlinkability of the user’s service requests have not been considered. Recently, Han et al. [8] proposed a new ASSO scheme which protects the identity of both the user and her service requests. Their scheme allows users to obtain a ticket from a ticket issuer to access multiple intended services. The ticket consists of a set of authentication tags that can only be validated by the designated verifiers. Designated verifiers can validate the corresponding tags for them and cannot link a user’s service requests, even when they collude. A third party called central verifier can de-anonymise a user’s identity and trace her service requests.

In a transport application a ticket could represent the intended route of travel (e.g. from A to B to C). Traditionally, in the rail industry, tickets were paper based and hence anonymous. In the context of smart ticketing, which is one of the main digital strategies of the UK rail industry [9] and stores customers’ data used to buy tickets, it will be important to consider passenger privacy in order to minimise the collection of personal information to reflect the requirements of the recently introduced General Data Protection Regulations (GDPR) [10] but still be able to provide guarantees as to who owns and uses a rail ticket. Since rail journeys often involve the cooperation of several different train operating companies, who are independent entities, the use of a designated verifiers in a ticket authentication scheme means that passenger personal information leakage between different companies is prevented. However, the inclusion of a central verifier allows the relevant transport authorities to identify passengers and their journeys. This is important in the case of an emergency to enable transport authorities to know who the passengers are using their transport systems. It could also provide guards on a train access a user’s whole journey information in order to provide the best journey advice during travel if appropriate.

In [8], an authentication tag can only be validated by a designated service provider, hence a user cannot access the services if the service provider is off-line or unavailable. In a cloud environment and when a service provider is off-line, a user would expect to be redirected to an alternative provider offering a similar service. While for a transport application (in the case of disruption), a ticket should still be valid and authorised for use on a redirected route. For example, a journey from A to C via B could be redirected to go via D and/or E when B is disrupted. In such cases a user should not be required to buy or change her ticket in order to access the disrupted route. Moreover, in practice, the entities who hold the disruption information are disconnected from those who sell tickets. Therefore, rail authorities and train companies should manage and be responsible for the redirected travel routes and disruption information with minimal impact on users.

In this paper, we propose a new ASSO scheme which extends the scheme presented in [8] to allow a central authority to authorise another verifier to act as a proxy and validate the authentication tags for a service provider that is unavailable. Consequently, our ASSO with proxy re-verification scheme provides:

  • Proxy Re-verification: in the case that a designated verifier is unavailable, the central authority can assign another verifier to validate the user’s ticket on behalf of the original verifier.

while preserving the following features from [8]:

  1. Multiple Access: a user can use one ticket to access multiple distinct services;

  2. Anonymity: a user can obtain a ticket from a ticket issuer without releasing anything about her PII to the ticket issuer, especially, the ticket issuer cannot determine whether two ticket are issued to the same user or two different users;

  3. Unlinkability: a designated verifier can determine whether a user is authorised to access its service but cannot link a user’s different service requests nor collude with other verifiers to link a user’s service requests;

  4. Unforgeability: tickets can only be issued by ticket issuers and cannot be forged by other parties even the central authority;

  5. Traceability: only the central verifier can de-anonymise a user and trace the identities of the verifiers whose services the user is authorised to access;

  6. Double Spending Detection: designated verifiers can detect and prevent a user from making two authentication requests using the same authentication tag but cannot de-anonymise the user;

Contributions: Our main contributions in this paper are summarised as follows: (1) an ASSO with proxy re-verification scheme providing the above features is formally constructed; (2) the definition and security model are formalised; (3) the scheme has been implemented and an empirical efficiency analysis is presented; (4) the security of our scheme is formally reduced to well-known complexity assumptions.

The novelty of this paper is to prevent information leakage across multiple verifiers and implement proxy re-verification. To the best of our knowledge, our scheme is the first scheme to support users anonymously and unlinkably authenticating to multiple service providers and allowing authorised proxy verifiers to verify authentication on behalf of an original designated verifier when that verifier is unavailable.

I-a Related Work

In this subsection, we review the work which is most closely related to our scheme. Previous authentication schemes mainly address the anonymity of users and implement multiple authentications using one credential.

I-A1 Anonymous Single-Sign-On schemes

Elmufti et al. [4] proposed an ASSO scheme which is suitable to the Global System for Mobile communication (GSM). In [4], to access a service, a user needs to generate a new one-time identity and uses it to authenticate to a trusted third party (TTP). If the authentication is successful, the TTP forwards the user’s one-time identity to the service provider who provides the service. As a result, the service provider cannot infer the user’s real identity from this one-time identity. However, in our scheme, users can authenticate to service providers directly without the need of a TTP.

Han et al. [5] proposed a generic construction of dynamic SSO schemes where digital signature, broadcast encryption and zero-knowledge proof are adopted. In [5], after registering with the system, a user obtains a credential which is the encryption of a signature generated by the central authority on a set of service selected by the user and her public key. Consequently, only the service providers whose services have been selected by the user can decrypt the ciphertext and validate the signature. To prevent sharing a credential, a user needs to prove the knowledge of her secret key corresponding to the public key included in the credential. Hence, a user is anonymous only to the service providers who are not included in the credential. Nevertheless, unlike in our scheme, service providers know the user’s identity (public key) and link her service requests.

Wang et al. [6] proposed an ASSO scheme based on group signatures [11]. When registering to the central authority, a user is issued a group member key. Then, to access a service, a user generates a group signature by using her group member key. A service provider checks whether the user is authorised to access services by validating the correctness of the signature. Furthermore, the central authority can use the open algorithm in the group signature scheme to trace a user’s identity. Notably, a user can access all services in the system, while in our scheme a user can only access the selected services.

Lee [7] proposed an efficient ASSO scheme based on Chebyshev Chaotic Maps. When joining the system, an issuer (the smart card processing center) issues temporary secret keys to users and service providers. To access a service, a user interacts with a service provider to generate a session key by using their respective temporary secret keys. A service request is granted if and only if the session key can be generated correctly; otherwise, the request is denied. However, unlike our scheme, each service provider knows the identity of the user accessing his service. Hence, multiple service providers can profile a user’s service requests if they collude. Moreover, a user can again access all services in the system, while in our scheme a user can only access the selected services.

I-A2 Proxy Re-Encryption

Mambo and Okamoto [12] introduced the definition of proxy crytosystems which enable a delegator to delegate the decryption power to a delegatee. Later, Blaze [13] proposed an atomic proxy cryptography scheme where a semi-trusted third party called proxy can convert ciphertexts for one user into ciphertexts for another user if the third party is given a proxy key.

Introduced by Shamir [14], an identity-based cryptosystem is a public key cryptosystem where a user’ public key can be any arbitrary string and her secret key is obtained from a trusted central authority. Boneh and Franklin [15] first proposed a practical identity-based encryption (IBE) scheme based on paring. Green and Ateniese [16] introduced the concept of identity-based proxy re-encryption (IBPRE) where a proxy can convert a ciphertext for the original decryptor to a ciphertext for a designated decryptor if the proxy obtains a re-encryption key from the original decrytor. Han et al. [17]classified IBPRE schemes into two types according to the generation of re-encryption keys: (1) re-encryption keys are generated by the trusted central authority [18, 19]; (2) re-encryption keys are generated by the original decryptors [16, 20]. In [18, 19, 16, 20], given a re-encryption key, a proxy can convert all ciphertexts for the original decryptor to ciphertexts for the designated decryptor. The differences between our scheme and IBPRE schemes are: (1) a proxy is not required; (2) a re-key only enables a proxy verifier to validate tickets on behalf the original verifier in a specified period, instead of all tags.

I-A3 Designated Verifier Schemes

Introduced by Jakobsson et al. [21], a designated verifier signature (DVS) scheme is a digital signature scheme where a signature can only be verified by a single designated verifier and the verifier cannot convince others that a signature is from the real signer since the verifier can generate the signature by himself. Fan et al. [22] present an attribute-based DVS scheme where a signature can be verified by a group of verifiers whose attributes satisfies specified values. In our scheme, we adopt the high level concept of a designated verifier, i.e. given a valid authentication tag, only the corresponding designated verifier and the authorised proxy verifiers can validate it. The main difference between these DVS schemes [21, 22] and our scheme is that only the designated verifiers can verify a signature in DVS schemes, while in our scheme, everyone can verify a signature generated by the ticket issuer for a tag but they cannot know for whom the tag is generated except for the designated verifier of that tag.

Kuchta et al. [23] proposed an identity-based strong designated verifier group signature (ID-SDVGS) scheme which can provide the features of both designated verifier signatures and identity-based group signatures. In this scheme, all entities must obtain secret keys from a trusted third party called private key generator (PKG). When joining the group, each user obtains a member credential from the group manager (GM). Then, a user can use her credential to anonymously generate a signature which can only be verified by the designated verifier and can be opened/de-anonymized by the GM. Especially, the verifier cannot convince others that the signature is from the real signer since the verifier can generate the signature by himself. However, in our scheme, only the secret keys of ticket verifiers are issued by the central authority. The secret keys of other entities including the ticket issuer, users and the central verifier are generated by themselves. Authenticate tags can only be generated by the ticket issuer and its correctness can be publicly verified. Nevertheless, other entities cannot know for whom a tag is generated except the designated verifier.

I-A4 - time Anonymous Authentication Schemes

Anonymous authentication schemes enable a user to authenticate to a verifier without releasing her PII to the verifier. To limit the authentication time, Teranishi et al. [24] proposed a - time anonymous authentication (-TAA) scheme where users register with a central authority and obtain an anonymous credential. A verifier generates authentication tags. For each access, a user proves to the verifier that she has obtained a valid credential from the central authority and selects a fresh authentication tag. As a result, no party can identify a user if she authenticates no more than times, while any party can identify a user if she authenticates more than times. In [24], the central authority decides a user’s access permission and service verifiers do not have control on the access permissions.

Camenisch et al. [25] proposed a periodic -TAA scheme where a user can anonymously authenticate herself to a service verifier no more than times in a given time period. The authentication tags automatically refresh every time period. When a user makes an anonymous authentication request, she proves to a verifier that she has obtained a valid credential (CL signature [26]) from the central authority. Lastly, Camenisch et al. proposed an identity mixer scheme [27, 28] in which users need to obtain a credential for their attributes. To access a service, a user proves to the service verifier that she has the required attributes.

In all these schemes [24, 29, 25, 27, 28], authentication is not bound to a particular verifier, whereas in our scheme an authentication tag can only be verified by a designated verifier. Furthermore, -TAA schemes allow verifiers to de-anonymise a user’s identity when she has authenticated more than times, while in our scheme a service verifier can detect whether a user has used the tag (double spending) but cannot de-anonymise a user’s identity. Notably, our scheme allows a central verifier to de-anonymise a user and trace her service requests.

I-B Paper Organisation

The remainder of this paper is organised as follows: Section II provides a high-level overview of our scheme and its security requirements; Section III introduces the formal definition and security model; Section IV presents the preliminaries for our scheme; A formal construction of our scheme is given in Section V. Section VI and Section VII present the security proof and the performance evaluation of our scheme, respectively. Finally, Section VIII concludes this paper.

Ii Scheme Overview and Security Properties

The notation used throughout this paper is summarised in Table I.

Notation          Explanations Notation                   Explanations
A security parameter The -th ticket verifier
Central authority The service set of consisting of the
Ticket issuer identities of ticket verifiers &
Ticket verifier Public parameters
User A set of pseudonyms of
Central verifier The pseudonym generated for
The identity of An authentication tag for
The identity of An authentication tag for
The identity of A ticket issued to
The identity of The cardinality of the set
A negligible function in is randomly selected from the set
The credential of is computed by running the
The credential of algorithm with input
The credential of A secret-public key pair generation algorithm
The credential of A bilinear group generation algorithm
Master Secret Key PPT Probable polynomial-time
, Cryptographic hash functions A prime number
TABLE I: Notation Summary

Our ASSO with flexible verification scheme consists of the following entities:

  • a trusted central authority, , which initialises the system, issues credentials to other entities in the scheme and authorises proxy verification;

  • a user, , who wants to access some distinct services anonymously and unlinkabily;

  • a ticket issuer, , issues tickets to registered, yet anonymous users for a set of selected services;

  • a designated verifier, , who can only validates the authentication tags generated for him and cannot link a user’s service requests;

  • an authentication tag, , which is bound to a user and a designated verifier and is used to convince that is authorised to access its service;

  • a ticket, , which consists of a set of authentication tags generated for the designated verifiers of the requested services;

  • a central verifier, , which is another trusted third party which, given a ticket , can de-anonymise the identities of the user and trace her service requests.

Fig. 1: Pictorial description of our scheme

Ii-a Overview of proposed scheme

A simplified pictorial description of our scheme is presented in Fig. 1. initialises the system. When joining the system, , , and authenticate to the and obtain their credentials from . To buy a ticket, sends her service information consisting of a set of verifiers’ identity to . Subsequently, generates a ticket for . The ticket comprises a set of tags which can only be validated by the corresponding designated verifiers. When being validated by , sends the corresponding tag to . In the case that ’s service information needs to be traced, is allowed to trace the whole service information of given a ticket . Especially, when the original verifier is unavailable, can authorise a new verifier to validate the tag on behalf of .

Ii-B Security Properties of Our Scheme

Having defined the different entities and described how they interact, we now list the security properties of our scheme:

Anonymity: a user can obtain a ticket from a ticket issuer anonymously;

Unlinkability: a designated verifier cannot link a user’s different service requests nor collude with other verifiers to link a user’s service requests;

Unforgeability: tickets are generated by ticket issuers and cannot be forged by other parties even the central authority;

Traceability: given a valid ticket, can de-anonymise the ticket holder and trace her service requests;

Proxy Re-verification: in the case that a designated verifier is unavailable, can assign one or more verifiers to validate a user’s tag designated for ;

Double Spending: a designated verifier can detect whether a tag has been used or not, but cannot de-anonymise the user.

Iii Formal Definition and Security Requirement

In this section, we review the formal definition and security requirement of ASSO with proxy re-verification.The formal definition of ASSO with proxy re-verification is defined by using a series of algorithms and is referred to Appendix A.

Iii-a Security Requirements

The security model of our scheme is defined by the following three games.

Unforgeability. This is used to define the unforgeability of tickets, namely even if users, verifiers and the central verifier collude, they cannot forge a valid ticket. This game is formalised in Appendix B-A.

Unlinkability. This is used to define the unlinkability, namely even if some ticket verifiers collude with potential users, they cannot profile the whole service information of other users. We assume that and cannot be compromised because they can know a user’s whole service information by themselves. The game is formalised in Appendix B-B.

Traceability. This is used to formalise the traceability of tickets, namely even if a group of users collude, they cannot generate a ticket which would not catch as belonging to some member of the colluding group. We suppose that the ticket issuer is honest. This game is formalised in Appendix B-C.

Iv Preliminaries

In this section, preliminaries used in this paper are introduced.

Iv-a Bilinear Group

Let , and be cyclic groups with prime order . A map is a bilinear map/pairing if it satisfies the following properties [15]: (1) Bilinearity: For all , and , ; (2) Non-degeneration: For all and , where is the identity element in ; (3) Computability: For all and , there exists an efficient algorithm to compute .

Let be a bilinear group generator which takes as input a security parameter and outputs a bilinear group . Bilinear maps can be divided into three types [30]: Type-I: ; Type-II: but there exist an efficient map: ; Type-III: but there is no efficient map between and . Type-III pairings are the most efficient pairings [31]. Our scheme is based on Type-III pairings where the size of elements in is short (160 bits).

Iv-B Complexity Assumptions

Definition 1

(Discrete Logarithm (DL) Assumption [32]) Let be a cyclic group with prime order and be a generator of . Given , we say that the DL assumption holds on if all PPT adversaries can output a number such that with a negligible advantage, namely

The proof of the traceability property of our scheme is reduced to the assumption.

Definition 2

(Decisional Bilinear Diffie-Hellman (DBDH) Assumption [15]) Let where and be a generator of . Suppose that . Given a tuple , we say that the DBDH assumption holds on if all PPT adversary can distinguish from a random element with a negligible advantage, namely

The security of the Boneh-Franklin IBE used to implement flexible verification was reduced to the DBDH assumption.

Definition 3

(Decisional asymmetric Bilinear Diffie-Hellman (DaBDH) Assumption [31]) Let and , be generators of and , respectively. Suppose that . Given a tuple , we say that the DaBDH assumption holds on if all PPT adversaries can distinguish from a random element with a negligible advantage, namely

The DaBDH assumption is used to prove the unlinkablity of our scheme.

Definition 4

((JoC Version) -Strong Diffie-Hellman (JoC--SDH) Assumption [33]) Let . Given a -tuple , we say that the JoC--SDH assumption holds on if all PPT adversaries can output with a negligible advantage, namely where .

The unforgeability of our scheme is reduced to JoC--SDH assumption.

Iv-C Zero-Knowledge Proof

We follow the definition introduced by Camenish and Stadler in [34] and formalised by Camenish et al. in [35]. By we denote a zero knowledge proof on knowledge of integers , and such that and hold on the groups and , respectively. The convention is that the letters in the parenthesis stand for the knowledge which is being proven, while the other parameters are known by the verifier.

Iv-D BBS+ Signature

This signature was proposed by Au et al. [36]. Its security was reduced to the -SDH assumption in Type-II pairing setting in [36]. Recently, Camenisch et al. [37] reduced its security to the JoC--SDH assumption in Type-III pairing setting.

Theorem 1

(Camenisch et al. [37])The BBS+ signature is existentially unforgeable against adaptive chosen message attacks (EU-CMA) if the JoC--SDH assumption holds on the bilinear group .

Iv-E Boneh-Franklin Identity-Based Encryption

Boneh and Franklin [15] proposed the first IBE scheme based on the Type-I pairing: .

Theorem 2

(Boneh and Franklin [15]) This IBE scheme is secure against chosen-plaintext attack (CPA) if the DBDH assumption holds on the bilinear map group .

Abdalla et al. [38] observed that Boneh-Franklin IBE [15] is an anonymous IBE scheme where ciphertext does not release the identity of the receiver. Chatterjee and Menezes [31] transferred Boneh-Franklin IBE scheme from Type-I pairing setting to Type-III pairing setting, and claimed that the security of the transferred scheme can be reduced to DaBDH assumption. In this paper, the Boneh-Franklin [15] IBE scheme is applied to implement proxy re-verification.

V Construction of our scheme

V-a Formal Construction

The formal construction of our ASSO with proxy re-verification scheme including messages sent between its entities and their relevant computations is presented in Fig. 2, Fig. 3, Fig. 4, Fig. 5, Fig. 6, Fig. 7 and Fig. 8. Notably, Fig. 7 and Fig. 8 are new in our scheme compared to Han et al. ’s construction in [8] and Fig. 3, Fig. 4 have been modified to reflect the IBPRE scheme used.

V-B High-Level Overview

At a high level, our scheme works as follows.

Setup. initializes the systems and generates a master secret key and the corresponding public parameters . Actually, is used to issue credentials to , and when they join the system, while is used to issue secret keys to s.

Registration. When joining the system, , and generate their secret-public key pairs , and , and register with the by sending their identities and public keys , respectively. Finally, , and obtain their credentials , and from , respectively. Note, , and are generated by using the master secret key and are BBS+ signatures on the public keys , and , respectively. When joining the system, s only submit their identities to . uses the master secret key to generate a secret key for the identity of . This is one of the main differences in the scheme’s construction compared to Han et al. [8] where the verifiers generate their own secret-public key pairs. Moving this generation to the is required to facilitate the proxy re-verification. Furthermore, the generates a credential for which is a BBS+ signature on . stores , and sends them to .

Ticket Issuing. To buy a ticket, determines her service information consisting of the identities of the corresponding whose services wants to access. Furthermore, for each , generates a pseudonym using her secret key and proves to that she is a registered user and the pseudonyms are generated correctly ( ). If the proof is correct, for each , generates an authentication tag . Within the tag are used by to validate while are used by a proxy verifier to validate on behalf of in a specified time period TP. Since is embedded in it is used to restrict the time of proxy re-verification to reflect that time period. In a rail application, a could be the travel day printed on the ticket (e.g. September 1, 2018) and can be decided by the ticket issuer.

Additionally, within the tag are used by to de-anonymize ’s identity and trace her service requests. Note also that is the serial number of and is a BBS+ signature on . To prevent from combing the authentication tags in different tickets, generates another BBS+ signature on the ticket issue number . The ticket is .

Ticket Validation. When validating a ticket, sends its identity to . selects the corresponding tag , and then sends it to with a proof of the knowledge ( ) of the secrets included in the pseudonyms . validates the tag by checking the proof and the signature. However, in the case that needs to confirm whether is a designated verifier, sends and his credential to . Then, checks . If it holds, is a designated verifier; otherwise, is not. In this paper, we assume that is clear and does not need to confirm it. For example in the rail case, the verifier/station is clear to .

Ticket Trace. To de-anonymize a user and trace her service requests, initialises a set . Given a ticket , uses his secret key to de-anonymize from the pseudonyms for and traces the service request from . Finally, can determine ’s service requests by recording all the identities .

Proxy Key Generation. In the case that a verifier is unavailable, can authorize a proxy verifier to validate the tag in a ticket by issuing a re-key to . is generated by using both secret keys and . To limit the proxy verification period, a time period , which gets embedded in during the Ticket Issuing, is also embedded in so that only tickets within that period can be validated by the proxy verifier. To prevent an unauthorised verifier from claiming to be a legal proxy, the or another trusted third party should broadcast the proxy information to both and . For example, in a rail application, when a station is unavailable and an alternative plan is provided, both the user and the proxy need to be notified.

Proxy Ticket Validation. To verify a tag on behalf of , sends the identity to . returns the tag to and proves the knowledge included in . If the proof is correct, validates by using his secret key and the re-key . Both the user and the proxy verifier know that is a proxy for the verifier as discussed above. For example, in a transport application a public announcement would identify the alternative route and hence the corresponding proxy verifier to the user.

Setup runs with . Let be generators of and be generators of . Suppose that , and are cryptographic hash functions. selects and . computes and . The master secret key is and the public parameters are .

Fig. 2: Setup Algorithm

Ticket-Issuer-Reg Ticket Issuer: Central Authority: Selects and computes , The secret-public key pair is . Selects and computes Verifies:    . Keeps the credential as Stores . Ticket-Verifier-Reg Ticket-Verifier: Central Authority: Selects and computes Verifies: ; , ; . Keep the credential as and Stores . the secret key as . User-Reg User: Central Authority: Selects , and computes This secret-public key pair is Select and computes Verifies:    Keep the credential as . Stores Central-Verifier-Reg Central Verifier: Central Authority: Selects , and computes . The secret-public key pair is Selects and computes Verifies:    Keep the credential as Stores

Fig. 3: Registration Algorithm

Suppose that is ’s service set consisting of the identities of ticket verifiers and the central verifier .             User:             Ticket Issuer: Computes . Select and computes , , Verifies and . , , Selects , and computes . , For , selects , and computes , , . , , Computes the proof , and . The authentication tag is , where is the serial numbers of . Selects and computes and where is the serial number of the ticket. For , verifies The ticket is: , .            . ,