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

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

Anonymous Single-Sign-On authentication schemes have been proposed to allow users to access a service protected by a verifier without revealing their identity which has become more important due to the introduction of strong privacy regulations. In this paper we describe a new approach whereby anonymous authentication to different verifiers is achieved via authorisation tags and pseudonyms. The particular innovation of our scheme is authentication can only occur between a user and its designated verifier for a service, and the verification cannot be performed by any other verifier. The benefit of this authentication approach is that it prevents information leakage of a user's service access information, even if the verifiers for these services collude which each other. Our scheme also supports a trusted third party who is authorised to de-anonymise the user and reveal her whole services access information if required. Furthermore, our scheme is lightweight because it does not rely on attribute or policy-based signature schemes to enable access to multiple services. The scheme's security model is given together with a security proof, an implementation and a performance evaluation.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

11/19/2018

Anonymous Single Sign-on with Proxy Re-Verification

An anonymous Single Sign-On (ASSO) scheme allows users to access multipl...
06/26/2019

Smart Contract Federated Identity Management without Third Party Authentication Services

Federated identity management enables users to access multiple systems u...
08/08/2021

An Anonymous On-Street Parking Authentication Scheme via Zero-Knowledge Set Membership Proof

The amount of information generated grows as more and more sensor and Io...
03/28/2019

An Approach to Identity Management in Clouds without Trusted Third Parties

The management of sensitive data, including identity management (IDM), i...
07/31/2018

Peripheral Authentication for Parked Vehicles over Wireless Radio Communication

Peripheral authentication is an important aspect in the vehicle networks...
10/29/2020

SANS: Self-sovereign Authentication for Network Slices

5G communications proposed significant improvements over 4G in terms of ...
01/26/2021

What's in Score for Website Users: A Data-driven Long-term Study on Risk-based Authentication Characteristics

Risk-based authentication (RBA) aims to strengthen password-based authen...
This week in AI

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

1 Introduction

Single-sign-on (SSO) systems are a user-friendly way of allowing users access to multiple services without requiring them to have different usernames or passwords for each service. SSO solutions (e.g. OpenID 2.0 [33] by the OpenID foundation or Massachusetts Institute of Technology (MIT)’s Kerberos [31]) are designed to make the users’ identities and possibly additional personal identifiable information (PII) available to the verifiers of the services which they wish to access. However, for some services, a verifier may not require the user’s identity (nor any associated PII), just that the user is authorised to access the desired service. Moreover, the introduction of more stringent obligations with regards to the handling of PII in various jurisdictions (e.g. GDPR in Europe[19]), requires service providers to minimise the use of PII.

Anonymous single-sign-on schemes[18, 24, 36, 27] exist which can protect a user’s identity, but may not do so for all entities within a scheme. Moreover, a user’s service request can be verified by all verifiers of a system rather than the one it is intended for which may pose a potential privacy risk to both the user and that verifier.

Our proposed scheme addresses these issues and provides the following features: (1) only one authentication ticket is issued to a user, even if she wants to access multiple distinct services; (2) a user can obtain a ticket from a ticket issuer anonymously without releasing anything about her personal identifiable information — in particular, the ticket issuer cannot determine whether two ticket requests are for the same user or two different users; (3) a designated verifier can determine whether a user is authorised to access its service but cannot link different service requests made by the same user nor collude with other verifiers to link a user’s service requests; (4) designated verifiers can detect and prevent a user making multiple authentication requests using the same authentication tag (“double spend”) but cannot de-anonymise the user as a result; (5) tickets cannot be forged; and (6) given a user’s ticket, a central verifier is authorised to recover a user’s identity as well as the identities of the verifiers for the requested services in the user’s ticket.

Our contributions are: a novel, anonymous single-sign-on scheme providing the above features; its associated security model and security definitions; a corresponding formal proof of its security as well as an empirical performance analysis based on a Java-based implementation of our scheme.

1.1 Related Work

We now look at previous research which is most closely related to our scheme in the areas of: i) Anonymous Single-Sign-On protocols, ii) anonymous authentication schemes, iii) multi-coupon schemes and iv) designated verifiers signature schemes.

Anonymous Single-Sign-On schemes

One of the earliest anonymous single-sign-on system was proposed by Elmufti et al.[18] for the Global System for Mobile communication (GSM). In their system, a user generates a different one-time identity each time they would like to access a service and, having authenticated the user, a trusted third party will then authenticate this one-time identity to the service provider. Consequently, the user is anonymous to the service provider but, unlike in our scheme, not the trusted third party who authenticated the one-time identity.

In 2010, Han et al. [24] proposed a novel dynamic SSO system which uses a digital signature to guarantee both the unforgeability and the public verification of a user’s credential. In order to protect the user’s privacy, their scheme uses broadcast encryption which means that only the designated service providers can check the validity of the user’s credential. Moreover, zero-knowledge proofs are used to show that the user is the owner of those valid credentials to prevent impersonation attacks. However, again unlike our scheme, the user is still known to the trusted third party which issued the credentials.

Wang et al. [36], on the other hand, propose an anonymous SSO based on group signatures [3]. In order to access a service, the user generates a different signature-based pseudonyms from her credentials and sends the signature to the service provider. If the signature is valid, the service provider grants the user access to the service to the user; otherwise, the service request is denied. The real identities of users can be identified by using the opening technique in [3]. While the user remains anonymous, their scheme (unlike ours) does not, however, provide designated verifiers, i.e. all verifiers can validate a user’s request.

Lastly, Lee[27] proposed an efficient anonymous SSO based on Chebyshev Chaotic Maps. In this scheme, an issuer, the “smart card processing center”, issues secret keys to users and service providers when they join in the system and to access a service, a user and service provider establish a session key with their respective secret keys. If the session key is generated correctly, the service request is granted; otherwise, it is denied. However, unlike our scheme, each service provider knows the identity of the user accessing their service.

While in [24], [36] and [27], a user can access any service in the system by using her credentials, in our scheme, a user can only access the services which she selects when obtaining a ticket but can do so while remaining completely anonymous to both issuer and service provider.

Anonymous authentication schemes

With respect to anonymous authentication solutions, we consider schemes whose primary feature is to support multiple anonymous authentication. As in our scheme, anonymous authentication enables users to convince verifiers that they are authorised users without releasing their exact identities.

Teranishi et al. [35] proposed a -times anonymous authentication (-TAA) scheme where the verifiers determine the number of anonymous authentication that can be performed. The -TAA scheme provides the following two features: (1) no party can identify users who have been authenticated within times; (2) any party can trace users who have been authenticated more than times. The verifier generates tags and for each authentication, a user selects a fresh tag. Nguyen et al. [32] proposed a similar dynamic -TAA scheme to restrict access to services not only the number of times but also other factors such as expiry date.

Camenisch et al. [9] proposed a periodic -TAA scheme which enables users to authenticate themselves to the verifiers no more than times in a given time period but supports reuse of the times authentication once the period is up. In this scheme, the issuer decides the number of anonymous authentication request a user can make in a given time period. When a user makes an anonymous authentication request, he proves to a verifier that he has obtained a valid CL signature from the issuer.

Note, however, that our scheme also prevents a verifier from establishing whether a user has used any of the other services thereby also guaranteeing verifier anonymity.

Furthermore, in all of these -TAA schemes [35, 32, 9], authentication is not bound to a particular verifier, whereas in our scheme authentication tags are bound to specific verifiers. Moreover, -TAA schemes allow verifiers to determine a user’s identity who has authenticated more than times while in our scheme multiple authentications to a single verifier is considered ”double spending” which a verifier can detect but which does not lead to the de-anonymisation of a user.

However, to prevent users from potentially abusing the system, our scheme allows for a central verifier who, given a user’s ticket, can extract from it both the user’s and verifiers’ public keys using the authentication tags contained within it and thus establish the identities of both the user and her associated verifiers.

Lastly, Camenisch et al. in [12] and the IBM identity mixer description of its features in [37] define a scheme that has similar properties to ours including that of a central verifier (called “inspector”) trusted to reveal a user’s identity. The scheme is based on users obtaining a list of certified attributes from an issuer and the users using a subset of their attributes to authenticate to verifiers. The distinguishing difference between their scheme and ours is that their verification of anonymous credentials is not bound to a designated verifier whereas our is.

Multi-coupon schemes

There is some degree of similarity between our scheme and a number of multi-coupon schemes. Armknecht et al. [1] proposed a multi-coupon scheme for federated environments where multiple vendors exist. In [1], a user can redeem multiple coupons anonymously with different vendors in an arbitrary order. To prevent double-spending of a coupon, a central database is required to record the transaction of each multi-coupon. The main difference to our scheme is that each coupon can be redeemed against any service provider while our authentication tags can only be validated by its designated verifier. Moreover, our “double-spend” detection is done by the verifier and does not require a central database.

Similarly, the schemes propose by Liu et al. [29] which provides strong user privacy and where a user can use an e-coupon anonymously no more than times before his identity can be recovered. However, the user’s coupons can be redeemed against any service rather than a designated verifier as our scheme provides.

Designated Verifiers

Jakobsson in [25] introduced the concept of a designated verifier which means that in a proof we ascertain that nobody but this verifier can be convinced by that proof while the authors in [20] present an anonymous attribute based scheme using designated-verifiers. In their work they focus on identifying multiple designated verifiers This is achieved through using the verifier’s private key in the verification so that no other third party can validate the designated verifier signature. We adopt the high level concept of a designated verifier in our approach, i.e. given a valid authentication tag for service , only service ’s verifier can establish its validity. As this property is conceptually similar to the designated signatures described in [25, 20], our verifiers are called designated verifiers. However, this is where the similarity ends with Jakobsson’s designated verifiers. Notably, in [26], a verifier cannot convince others that the signature is from the signer because the verifier can generate the signature by himself. In our scheme, everyone can check that the authentication tags are signatures generated by the ticket issuer.

In summary, while a number of previous authentication schemes address the anonymity of the user and multiple authentications, the novelty of our work is that we ensure no information leakage across verifiers, since authentication can only occur between a user and its designated verifier while also providing a central verifier who can de-anonymise the user and reveal the identity of the verifiers in case of a misbehaving user. To the best of our knowledge, our anonymous single-sign-on scheme using designated verifiers is the first which has been formally presented in term of definitions, security models and proven to be secure under various cryptographic complexity assumptions together with an empirical performance evaluation.

1.2 Paper Organisation

This paper is organised as follows: Section LABEL:sec:contributions provides a high-level overview of the scheme and its claimed security properties; Section 3 outlines the applicable security model; Section 4 introduces the mathematical concepts and notation used throughout this paper; Section 5 describes the mathematical construction of our while Section 6 presents the theorems for its security proof; Section 7 provides a performance evaluation of our scheme; and Section 8 concludes the paper with directions for future work.

2 Scheme overview and security properties

Entities in our proposed scheme

Before providing a high-level overview of our anonymous single-sign-on scheme, we first introduce the various entities in the scheme as shown in Figure 1, and define their purpose and roles:

  • Central Authority (): The is a trusted third party responsible for establishing the cryptographic keys and parameters used in the scheme and signing the public keys of the other entities in the scheme;

  • User (): Someone who wishes to access some distinct services anonymously;

  • Ticket Issuer (): This entity issues tickets to registered, yet anonymous users for the requested services;

  • Designated Verifier (): The is a verifier for a specific service that a user might want to access;

  • Central Verifier (): is another trusted third party which is allowed to retrieve the identities of the user, , and the verifiers, s, from the authentication tags present in a user’s ticket, .

  • Authentication Tag (): This tag is both tied to a user, , and a designated verifier, and is used to prove to the designated verifier that the user is a valid user and allowed to access the associated service;

  • Ticket (): A ticket which contains the authentication tags for the services a user, , has requested;

Figure 1: Interaction of the various entities in our scheme

Overview of proposed scheme

Figure 1 illustrates at a high-level how our scheme works. For the detailed mathematical construction of our scheme, please refer to Section 5. Conceptually, our scheme operates as follows:

  • Registration: The issuer, verifiers, central verifier and users all register with the CA.

  • Ticket Issuing: A user decides which services(and thus which verifiers) she wants to access and requests an appropriate ticket from the issuer.

  • Tag Validation: To access a service, the user presents the appropriate authentication tag to the service. The validity period and any other restrictions of the tag can be captured in the free text part of the tag or be a default set by the verifier. If a user’s tag is valid then the user is logged in to the service. Note that, unlike some other Single-Sign-On systems, the issuer does not need to be on-line for the tag validation to succeed.

  • “Double-Spend” detection: Should the user present the same tag twice then the verifier can warn the user that she is already logged in and should resume the already existing session or offer to terminate the previous session and continue with a fresh one.

  • Ticket trace: If a user is seen to abuse the service (e.g. violate the terms and conditions), the central verifier might be called upon to de-anonymise the user and determine any other services she has used.

Security properties in our proposed scheme

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

  • User Anonymity: In our scheme, users use pseudonyms whenever they interact with the issuer or a verifier. As such, the issuer cannot link a user across different ticket requests. Similarly, a user’s identity is also hidden from a designated verifier.

  • Authentication Tag Unlinkability: Apart from the central verifier and the issuer, no set of colluding verifiers can establish whether two or more different authentication tags came from the same anonymous user.

  • Verifier Anonymity: The verifier’s identify is protected from other users and verifiers, i.e. given an authentication tag, only the designated verifier can validate it and no other verifier (apart from the central verifier and the issuer) can determine for whom it is.

  • Designated Verifiability: Given an authentication tag, for verifier, , only can validate it.

  • “Double-spend” detection: Any verifier, , can detect when a user attempts to re-use an authentication tag but cannot de-anonymise the user.

  • Unforgeability: Neither tickets nor individual authentication tags can be forged by any colluding users or verifiers.

  • Traceability: There exists a trusted third party, a central verifier, who can, given a user’s ticket, , retrieve the user’s and the verifiers’ public keys (and hence their respective identities) from the authentication tags contained within .

In the next section, we provide the security models in which these properties hold while Section 6 contains the associated theorems which are used to prove those models.

3 Security Model Overview

We now present a high-level overview of the security models which are used to prove the security of our scheme. The models are defined by the following games executed between a challenger and an adversary.

Unlinkability Game:

This game covers the security properties of user anonymity, authentication tag unlinkability, verifier anonymity, designated verifiability and “double spend” detection. In this game verifiers and other users can collude but cannot profile a user’s whole service information. In other words, no party can link different tags to the same user and determine a verifier’s identity included in an authentication tag (thus proving verifier anonymity) except for the designated verifier, the ticket issuer or the central verifier. Moreover, for each authentication tag, the adversary can query its validity once, which in the context of this game addresses the properties of designated verifiability and “double spending”.

This game is formally defined in Appendix 0.B.1.

Unforgeability Game:

This game focuses on proving the unforgeability property of our scheme. Users, verifiers and the central verifier can collude but cannot forge a ticket on behalf of the ticket issuer.

This game is formally defined in Appendix 0.B.2.

Traceability Game:

This game focuses on the traceability property of our scheme. It shows that even if users, verifiers and the central verifier collude, they cannot generate a ticket which is linked to a user who has never obtained a ticket or a user who is not the real owner of the ticket.

This game is formally defined in Appendix 0.B.3.

4 Preliminaries

In this section, we introduce the mathematical concepts used by our scheme including bilinear groups, the BBS+ signature scheme, zero knowledge proofs and various complexity assumptions needed to ensure its security. The mathematical notation and symbols used throughout this paper are summarised in Table 1.

Syntax          Explanations Syntax                   Explanations
A security parameter The -th ticket verifier
Central authority The service set of consisting of the identities
Ticket issuer of ticket verifiers &
Ticket verifier Public parameters
User A set of pseudonyms of
Central verifier The pseudonym generated for the verifier
The identity of An authentication tag for the verifier
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 algorithm
The credential of with input
The credential of A secret-public key pair generation algorithm
The credential of A bilinear group generation algorithm
Master Secret Key prime numbers
cryptographic hash functions
Table 1: Syntax Summary

4.1 Bilinear Groups and pairings

In our scheme, bilinear groups are used to support the BBS+ signature scheme (defined in Section 4.2 below).

Let , and be three cyclic groups with prime order . A pairing is defined to be a bilinear, non-degenerative and computable map [7]. Given a security parameter, , we define to be a bilinear group generation algorithm. Note that Galbraith, Paterson and Smart [21]classified parings into three basic types and our scheme is based on the Type-III pairing where the elements on are short ( bits). This was chosen because for all and , there exists an polynomial-time efficient algorithm to compute resulting in an more efficient algorithm.

4.2 BBS+ Signature

Based on the group signature scheme [6], Au, Susilo and Mu [2] proposed the BBS+ signature. This signature scheme works as follows:

  • Setup: Let , be a generator of and be generators of .

  • KeyGen: The signer selects and computes . The secret-public key pair is .

  • Signing: To sign a block message , the signer selects , and computes . This signature on is .

  • Verification: Given a signature and , the verifier checks . If so, the signature is valid; otherwise, it is invalid.

Au, Susilo and Mu [2] reduced the security of the above signature to the -SDH assumption (see Definition 2 below) in Type-II paring. Recently, Camenisch, Drijvers and Lehmann [8] reduced its security to the JOC-version--SDH assumption (see Definition 3 below) for Type-III pairing.

4.3 Zero-Knowledge Proof

In our scheme, zero-knowledge proof of knowledge protocols are used to prove knowledge and statements about various discrete logarithms including: (1) proof of knowledge of a discrete logarithm modulo a prime number [34]; (2) proof of knowledge of equality of representation [14]; (3) proof of knowledge of a commitment related to the product of two other commitments [11]. We follow the definition introduced by Camenish and Stadler in [13] which was formalised by Camenish, Kiayias and Yung in [10]. By proof on knowledge of integers and such that and hold on the groups and , respectively. The convention is that the letters in the parenthesis represent the knowledge which is being proven by using the other values which the verifier can have access to.

4.4 Complexity Assumptions

The security of our scheme relies on a number of complexity assumptions defined in this subsection.

Definition 1.

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

The assumption is used in the proof of the traceability property of our scheme.

Definition 2.

(-Strong Diffie-Hellman (-SDH ) Assumption [4]) Let . Suppose that and are generators of and , respectively. Given a -tuple , we say that -strong Diffie-Hellman assumption holds on if for all probabilistic polynomial-time (PPT) adversary can output with a negligible advantage, namely

where .

Definition 3.

((JOC Version) -Strong Diffie-Hellman (JOC--SDH) Assumption [5]) Let . Given a -tuple , we say that the JOC- -strong Diffie-Hellman assumption holds on the bilinear group if for all probabilistic polynomial-time (PPT) adversaries can outputs with a negligible advantage, namely

where .

The security of the BBS+ signature used in our scheme relies on both the (-SDH ) and JOC--SDH) assumptions.

Definition 4.

(Decisional Diffie-Hellman (DDH) Assumption [17]) Let . Give a 3-tuple , we say that the decisional Deffie-Hellman assumption holds on if for all probabilistic polynomial-time (PPT) adversaries can distinguish or with negligible advantage, namely

where .

Note that the DDH assumption is believed to be hard in both and for the Type-III pairing [22] used in our scheme which means that we actually makes use of the following stronger complexity assumption.

Definition 5.

(Symmetric External Diffie-Hellman (SXDH) Assumption [22]) Let . We say that the symmetric external Diffie-Hellman assumption holds on if the decisional Diffie-Hellman (DDH) assumption holds on both and .

5 Scheme construction

In this section, we present a more detailed description of the interactions (cf. Fig. 1) between the entities of our scheme. These interactions are: (i) System Initialisation, (ii) Registration, (iii) Ticket Issuing, (iv) Tag Verification and (v) Ticket Tracing. Moreover, we provide details of the mathematical constructs used in these interactions. Formal definitions of the algorithms presented in this section can be found in Appendix 0.A.

5.1 System Initialisation

System Set-up: runs with . Let be generators of the group and be generators of . Suppose that and are two cryptographic hash functions. selects and computes . The master secret key is and the public parameters are .

Figure 2: System Set-up Algorithm

Fig. 2 shows the details of the system initialisation in which the central authority generates a master secret key, , and the required public parameters, .

Note: Once the system has been set up, all communication between the different entities in our scheme is assumed to be over secure, encrypted channels which can be established by the various entities using standard Public Key Infrastructure. This ensures that our scheme is not susceptible to simple Man-In-The-Middle attacks.

5.2 Registration

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

Figure 3: Registration Algorithm

Fig. 3 depicts the registration processes. When registering with the , , , and use the and generate their own secret-public key pairs. They then send their identities and associated public keys to which, after receiving a registration request from an entity, uses to generate the corresponding credential for them. Note that only the ticket issuer has two public keys, and . The first one is used to sign the tickets while the second one is used to validate the ticket.

5.3 Ticket Issuing

Ticket-Issuing Let is ’s list of the identities of verifiers which wants to access as well as             User:             Ticket Issuer: Computes Select and computes , , , , , Computes the proof Verifies and . Selects , and computes . For , selects and computes , , , , 111 consists of the system version information and all other information which can be used by verifiers to validate the tag, e.g. valid period, tag type, etc. and Let                    For the central verifier , selects , and computes and a) For , verify The ticket is: , where and are the serial numbers and . of and , respectively b) Verify and c) Keep secret

Figure 4: Ticket Issuing Algorithm

During the ticket issuing process (shown in Fig. 4), the user defines to be the set containing the identities of the ticket verifiers whose services she wants to access as well as the identity of the central verifier. In order to request a ticket from , creates pseudonyms, and , for each by using her secret key to protect the anonymity of the verifiers. She also produces a proof of knowledge of her credentials and submits this proof together with the set and the pseudonyms to to convince him that she is a registered user and created the pseudonyms. Once has received this information and verified the proof of knowledge, he generates an authentication tag for each as well as an overall for in case the ticket needs to be traced. Note that these tags are constructed using the public keys of the respective verifiers and thus can only be validated by the corresponding or the central verifier, . The ticket is formed from these individual tags. Note that each tag and the overall ticket are signed by the issuer using his private key while the integrity of the tags and the overall ticket is assured using hashes of their respective content. The ticket is sent back to who verifies the integrity of each tag and the overall ticket using the supplied hash values as well as that each tag and the overall ticket have been signed by the issuer.

5.4 Tag Verification

Tag-Verification User: Tag verifier: Computes Initialize a table if none exists already. and searches Computes and the proof:    If , aborts; otherwise, adds . in and checks: (1) The correctness of ; (2) ; (3) ; (4) . If (1), (2), (3) and (4) hold, the tag is valid; otherwise, it is invalid.

Figure 5: Tag Verification Algorithm

The tag verification process is shown in Fig. 5. When the user wants to access a service, the tag verifier send his identity information to the user which uses to look up the corresponding tag, . In order to access the service, must submit a proof of knowledge of her secret key alongside the relevant authentication tag to prevent users from sharing authentication tags. checks his table of previously received tags to ensure that the tag has not already been used previously (double-spend detection), before verifying the user’s proof of knowledge in Step 1. Step 2 checks the integrity of the tag using a hash function while Step 4 verifies that it has been issued by the ticket issuer, . Step 3 can only be verified by as it requires the private key of the verifier. Only if can complete all steps successfully, is the user granted access.

5.5 Ticket Tracing

Ticket-Trace             User:                     Central Verifier: Computes and searches Computes and the proof:    Firstly, verify is contained in ; . abort if this check fails Secondly, verify that the tag is valid by: (1) The correctness of ; (2) ; (3) ; (4) . If (1), (2), (3) and (4) hold, the tag is valid; otherwise abort as it is invalid. Finally, de-anonymise the user and her services by: (5) Let . For each in   (i) Compute: and .   (ii) Look up for ’s. Check:     (iiia) ;     (iiib) ;   (iv) If (c1) and (c2) hold, set ; otherwise abort   (v) verify remains the same for all tags (6) ; (7) . Provided (5), (6) and (7) can be computed, can determine that the service information of with public key is: ; otherwise, the trace has failed.

Figure 6: Ticket Trace Algorithm

Lastly, in the case that a user ’s whole service information needs to be traced, the central verifier, , sends its identity to who is then required to submit the information needed by the Ticket Validation algorithm as well as her overall ticket. Note that, provided a single tag is known, the whole ticket information could also be obtained directly from the issuer, , in case the user is not co-operating.

On receipt of this information, the central verifier first validates that the submitted tag passes the standard verification process (see Section5.4) as the central verifier’s is always included in . As discussed previously, this steps ensures that is a valid user and that the tag belongs to her. Once this steps has passed, the central verifier can then validate the integrity of the ticket and that the previously presented authentication tag is indeed part of the ticket which establishes that the ticket does indeed belong to user who presented it. Using his private key, the central verifier can now compute the user ’s public key as well as the public keys of all the verifiers contained within the authentication tags and thus determine the user’s identity and her service information .

6 Security Analysis

In this section we present the theorems which establish the security of our scheme.

Theorem 6.1 (Unlinkability).

An anonymous Single-Sign-On for designated services with traceability scheme in Fig. 2, Fig. 3, Fig. 4, Fig. 5 and Fig. 6 is -selectively unlinkable if the DDH assumption holds on the bilinear group with the advantage at most , and are secure cryptographic hash functions, where is the total number of verifiers selected by to query tickets, is the number of ticket validation queries, is the number of ticket trace queries, .

The proof of Theorem 6.1 follows from the unlinkability game in Appendix 0.B.1 and is formally proved in Appendix 0.F.

Theorem 6.2 (Unforgeability).

An anonymous Single-Sign-On for n designated services with traceability scheme in Fig. 2, Fig. 3, Fig. 4, Fig. 5 and Fig. 6 is -unforgeable if the JOC-version--SDH assumption holds on the bilinear group with the advantage at most , and are secure cryptographic hash functions, where is the total number of verifiers selected by to query tickets, , .

Theorem 6.2 is demonstrated by the unforgeability game in Appendix 0.B.2 and it is formally proved in Appendix 0.G.

Theorem 6.3 (Traceability).

An anonymous Single-Sign-On for n designated services with traceability scheme in Fig. 2, Fig. 3, Fig. 4, Fig. 5 and Fig. 6 is -traceable if the -SDH assumption holds on the bilinear group with the advantage at most , the DL assumption holds on the group with the advantage at most , and are secure cryptographic hash functions, where , is the total number of ticket issuing queries made by and .

Theorem 6.3 follows from the traceability game in Appendix 0.B.3 and its formal proof is given in Appendix 0.H.

7 Benchmarking results

Our proposed scheme has been implemented ([16]) on a Dell Inspiron Latitude E5270 laptop with an Intel Core i7-6600U CPU, 1TB SSD and 16GB of RAM running Fedora 27.

The implementation makes use of bilinear pairings using elliptic curves as well as other cryptographic primitives. As such the implementation of the scheme relies on the JPBC library ([15]) for the bilinear pairings and uses the cryptographic functions provided by bouncycastle ([28]).

7.1 Timings

Table 2 shows the results of the computational time spent in the various phases of our proposed scheme which required more complex computations (i.e. some form of verification or generation of proofs) . Note that the Java based implementation of the JPBC API ([15]) was used throughout.

The bilinear mapping used in the protocol implementations was a Type F elliptic curve where is the group of points of the elliptic curve and is its prime order whose binary representation requires -bits.

Protocol phase Entity (r,V), r=#bits; V=#verifiers
System Initialisation - Central Authority ()
initialise the system CA 1398 3385
Registration - Issuer ()
generate I credentials CA 12 45
verify I credentials I 641 979
Registration - User ()
generate user credentials CA 12 20
verify user credentials User 301 498
Registration - Central Verifier ()
generate CV credentials CA 9 23
verify CV credentials CV 269 497
Registration - Verifier ()
generate V credentials CA 10 23
verify V credentials V 290 623
Issuing phase
generate & ticket request User 93 101 280 309
verify , generate ticket Issuer 481 515 916 1044
verify ticket User 764 960 1960 2567
Tag Verification - Verifier ()
retrieve & generate User 13 34
verify & V 225 575
Ticket Tracing - Central Verifier ()
retrieve ticket & ; generate User 8 9