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  by the OpenID foundation or Massachusetts Institute of Technology (MIT)’s Kerberos ) 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), 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. 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.  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. , on the other hand, propose an anonymous SSO based on group signatures . 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 . 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 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 ,  and , 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.  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.  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.  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  and the IBM identity mixer description of its features in  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.
There is some degree of similarity between our scheme and a number of multi-coupon schemes. Armknecht et al.  proposed a multi-coupon scheme for federated environments where multiple vendors exist. In , 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.  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.
Jakobsson in  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  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 , 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;
Overview of proposed scheme
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.
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.
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.
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.
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.
|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|
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 . Given a security parameter, , we define to be a bilinear group generation algorithm. Note that Galbraith, Paterson and Smart 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
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.
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 ; (2) proof of knowledge of equality of representation ; (3) proof of knowledge of a commitment related to the product of two other commitments . We follow the definition introduced by Camenish and Stadler in  which was formalised by Camenish, Kiayias and Yung in . 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.
(Discrete Logarithm (DL) Assumption ) 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.
(-Strong Diffie-Hellman (-SDH ) Assumption ) 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
((JOC Version) -Strong Diffie-Hellman (JOC--SDH) Assumption ) 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
The security of the BBS+ signature used in our scheme relies on both the (-SDH ) and JOC--SDH) assumptions.
(Decisional Diffie-Hellman (DDH) Assumption ) 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
Note that the DDH assumption is believed to be hard in both and for the Type-III pairing  used in our scheme which means that we actually makes use of the following stronger complexity assumption.
(Symmetric External Diffie-Hellman (SXDH) Assumption ) 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
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.
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
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
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
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, .
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.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 .
7 Benchmarking results
Our proposed scheme has been implemented () 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 () for the bilinear pairings and uses the cryptographic functions provided by bouncycastle ().
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 () 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|
|generate & ticket request||User||93||101||280||309|
|verify , generate ticket||Issuer||481||515||916||1044|
|Tag Verification - Verifier ()|
|retrieve & generate||User||13||34|
|Ticket Tracing - Central Verifier ()|
|retrieve ticket & ; generate||User||8||9|