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 [35] by the OpenID foundation or Massachusetts Institute of Technology (MIT)’s Kerberos [33]) 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 [20]), requires service providers to minimise the use of PII.

Anonymous Single-Sign-On schemes [19, 26, 29, 38] 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 and not just 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 anonymous Single-Sign-On system was proposed by Elmufti et al. [19] 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. [26] 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. [38], 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 [29] 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 [29, 38], 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. [37] proposed a k-times anonymous authentication (k-TAA) scheme where the verifiers determine the number of anonymous authentication that can be performed. The k-TAA scheme provides the following two features: (1) no party can identify users who have been authenticated within k times; (2) any party can trace users who have been authenticated more than k times. The verifier generates k tags and for each authentication, a user selects a fresh tag. Nguyen et al. [34] proposed a similar dynamic k-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 k-TAA scheme which enables users to authenticate themselves to the verifiers no more than k times in a given time period but supports reuse of the k 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 [11] 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 k-TAA schemes [9, 34, 37], authentication is not bound to a particular verifier, whereas in our scheme authentication tags are bound to specific verifiers. Moreover, k-TAA schemes allow verifiers to determine a user’s identity who has authenticated more than k 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 [13] and the IBM identity mixer description of its features in [27] 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. [31] which provides strong user privacy and where a user can use an e-coupon anonymously no more than k 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 [28] 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 [21] 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 A, only service A’s verifier can establish its validity. As this property is conceptually similar to the designated signatures described in [21, 28], our verifiers are called designated verifiers. However, this is where the similarity ends with Jakobsson’s designated verifiers. Notably, in [28], 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: Sect. 2 provides a high-level overview of the scheme and its claimed security properties; Sect. 3 outlines the applicable security model; Sect. 4 introduces the cryptographic building blocks and notation used throughout this paper; Sect. 5 describes the formal construction of our while Sect. 6 presents the theorems for its security proof; Sect. 7 provides a performance evaluation of our scheme; and Sect. 8 concludes the paper with directions for future work. The full version of this paper in [25] contains detailed formal definitions, security models and proofs of the scheme.

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 Fig. 1, and define their purpose and roles: the Central Authority (\(\varvec{\mathcal {CA}}\)) is a trusted third party responsible for establishing the cryptographic keys and parameters used in the scheme and issues credentials to the other entities in the scheme; a User (\(\varvec{\mathcal {U}}\)) is someone who wishes to access some distinct services anonymously; the Ticket Issuer (\({\mathcal {I}}\)) issues tickets to registered, yet anonymous users for the requested services; a Designated Verifier (\(\varvec{\mathcal {V}}\)) is a verifier for a specific service that a user might want to access; the Central Verifier (\(\varvec{\mathcal {CV}}\)) is another trusted third party which is allowed to retrieve the identities of the user, \(\mathcal {U}\), and the verifiers, \(\mathcal {V}\)s, from the authentication tags present in a user’s ticket, \(T_U\); an Authentication Tag (\({{Tag}}_{V}\)) is both tied to a user, \(\mathcal {U}\), and a designated verifier, \(\mathcal {V}\) and is used to prove to the designated verifier that the user is a valid user and allowed to access the associated service; a Ticket (\({T}_{U}\)) contains the authentication tags for the services a user, \(\mathcal {U}\), has requested.

Fig. 1.
figure 1

Interaction of the various entities in our scheme

Full size image

Overview of Proposed Scheme

Figure 1 illustrates at a high-level how our scheme works. For its detailed formal construction, please refer to Sect. 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: If the user present the same tag twice then the verifier can warn the user that she is already logged in and that she should resume the already existing session or offer to terminate the previous session and start 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, \(Tag_V\) for verifier, \(\mathcal {V}\), only \(\mathcal {V}\) can validate it.

  • “Double-spend” detection: Any verifier, \(\mathcal {V}\), 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, \(T_U\), retrieve the user’s and the verifiers’ public keys (and hence their respective identities) from the authentication tags contained within \(T_U\).

In the next section, we provide the security models in which these properties hold while Sect. 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. Detailed formal security models as well as their proofs are presented in the full version of this paper [25] which also demonstrates the correctness of our scheme.

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”.

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.

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.

4 Preliminaries

In this section, we introduce the cryptographic building blocks 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.

Table 1. Syntax summary
Full size table

4.1 Bilinear Groups and Pairings

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

Let \(\mathbb {G}_{1}\), \(\mathbb {G}_{2}\) and \(\mathbb {G}_{\tau }\) be three cyclic groups with prime order p. A pairing is defined to be a bilinear, non-degenerative and computable map \(e:\mathbb {G}_{1}\times \mathbb {G}_{2}\rightarrow \mathbb {G}_{\tau }\)[7]. Given a security parameter, \(1^{\ell }\), we define \(\mathcal {BG}(1^{\ell })\rightarrow (e,p,\mathbb {G}_{1},\mathbb {G}_{2}, \mathbb {G}_{\tau })\) to be a bilinear group generation algorithm. Note that Galbraith, Paterson and Smart [22] classified parings into three basic types and our scheme is based on the Type-III pairing where the elements on \(\mathbb {G}_{1}\) are short (\({\approx }160\) bits). This was chosen because for all \(g\in \mathbb {G}_{1}\) and \(\mathfrak {g}\in \mathbb {G}_{2}\), there exists an polynomial-time efficient algorithm to compute \(e(g,\mathfrak {g})\in \mathbb {G}_{\tau }\) resulting in a 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 \(\mathcal {BG}(1^{\ell })\!\rightarrow \!(e,p,\mathbb {G}_{1},\mathbb {G}_{2}, \mathbb {G}_{\tau })\), h be a generator of \(\mathbb {G}_{1}\) and \(g,g_{0},g_{1},\cdots ,\) \(g_{n}\) be generators of \(\mathbb {G}_{2}\).

  • KeyGen: The signer selects \(x{\mathop {\leftarrow }\limits ^{R}}\mathbb {Z}_{p}\) and computes \(Y=h^{x}\). The secret-public key pair is (x, Y).

  • Signing: To sign a block message \((m_{1},m_{2},\cdots ,m_{n})\in \mathbb {Z}_{p}^{n}\), the signer selects \(w,e{\mathop {\leftarrow }\limits ^{R}}\mathbb {Z}_{p}\), and computes \(\sigma =(g_{0}g^{w}\prod _{i=1}^{n}g_{i}^{m_{i}})^{\frac{1}{x+e}}\). This signature on \((m_{1},m_{2},\cdots ,m_{n})\) is \((w,e,\sigma )\).

  • Verification: Given a signature \((w,e,\sigma )\) and \((m_{1},m_{2},\cdots ,m_{n})\), the verifier checks \(e(Yh^{e},\sigma ){\mathop {=}\limits ^{?}}e(h,g_{0}g^{w}\prod _{i=1}^{n}g_{i}^{m_{i}})\). If so, the signature is valid; otherwise, it is invalid.

Au, Susilo and Mu [2] reduced the security of the above signature to the q-SDH assumption (see Definition 2 below) in Type-II paring. Recently, Camenisch, Drijvers and Lehmann [8] reduced its security to the JOC-version-q-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 [36]; (2) proof of knowledge of equality of representation [15]; (3) proof of knowledge of a commitment related to the product of two other commitments [12]. We follow the definition introduced by Camenish and Stadler in [14] which was formalised by Camenish, Kiayias and Yung in [10]. By \(\text{ PoK: }\{(\alpha ,\beta ,\gamma ): \varUpsilon =g^{\alpha }h^{\beta }~\wedge ~\tilde{\varUpsilon }=\tilde{g}^{\alpha } \tilde{h}^{\gamma }\},\) proof on knowledge of integers \(\alpha \) \(\beta \) and \(\gamma \) such that \(\varUpsilon =g^{\alpha }h^{\beta }\) and \(\tilde{\varUpsilon }=\tilde{g}^{\alpha }\tilde{h}^{\beta }\) hold on the groups \(\mathbb {G}=\langle g \rangle =\langle h \rangle \) and \(\tilde{\mathbb {G}}=\langle \tilde{g} \rangle =\langle \tilde{h} \rangle \), respectively. The convention is that the letters in the parenthesis \((\alpha ,\beta ,\gamma )\) represent the knowledge which is being proven by using the other values to which the verifier can have access.

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 [24]). Let \(\mathbb {G}\) be a cyclic group with prime order p and g be a generator of \(\mathbb {G}\). Given \(Y\in \mathbb {G}\), we say that the discrete logarithm (DL) assumption holds on \(\mathbb {G}\) if for all adversary can output a number \(x\in \mathbb {Z}_{p}\) such that \(Y=g^{x}\) with a negligible advantage, namely

$$\begin{aligned} Adv_{\mathcal {A}}^{DL}=\Pr \left[ Y=g^{x}|\mathcal {A}(p,g,\mathbb {G},Y)\rightarrow x\right] \le \epsilon (\ell ). \end{aligned}$$

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

Definition 2

(q-Strong Diffie-Hellman (q-SDH ) Assumption [4]). Let \(\mathcal {BG}(1^{\ell })\rightarrow (e,p,\mathbb {G}_{1},\mathbb {G}_{2}, \mathbb {G}_{\tau })\). Suppose that g and \(\mathfrak {g}\) are generators of \(\mathbb {G}_{1}\) and \(\mathbb {G}_{2}\), respectively. Given a \((q+2)\)-tuple \((g,g^{x},g^{x^{2}},\) \(\cdots ,g^{x^{q}},\mathfrak {g})\in \mathbb {G}_{1}^{q+1}\times \mathbb {G}_{2}\), we say that q-strong Diffie-Hellman assumption holds on \((e,p,\mathbb {G}_{1},\mathbb {G}_{2},\mathbb {G}_{\tau })\) if for all probabilistic polynomial-time (PPT) adversary \(\mathcal {A}\) can output \((c,g^{\frac{1}{x+c}})\in \mathbb {Z}_{p}\times \mathbb {G}_{1}\) with a negligible advantage, namely \(Adv_{\mathcal {A}}^{q-SDH}=\Pr [\mathcal {A}(\mathfrak {g},g,g^{x},g^{x^{2}}, \cdots ,g^{x^{q}})\rightarrow (c,g^{\frac{1}{x+c}})]\le \epsilon (\ell ),\) where \(c\in \mathbb {Z}_{p}-\{-x\}\).

Definition 3

((JOC Version) q-Strong Diffie-Hellman (JOC-q-SDH) Assumption [5]). Let \(\mathcal {BG}(1^{\ell })\rightarrow (e,p,\mathbb {G}_{1},\mathbb {G}_{2},\) \(\mathbb {G}_{\tau })\). Given a \((q+3)\)-tuple \((g,g^{x},\cdots ,g^{x^{q}},\mathfrak {g}, \mathfrak {g}^{x})\in \mathbb {G}_{1}^{q+1}\times \mathbb {G}_{2}^{2}\), we say that the JOC- q-strong Diffie-Hellman assumption holds on the bilinear group \((e,p,\mathbb {G}_{1},\mathbb {G}_{2},\mathbb {G}_{\tau })\) if for all probabilistic polynomial-time (PPT) adversaries \(\mathcal {A}\) can output \((c,g^{\frac{1}{x+c}})\in \mathbb {Z}_{p}\times \mathbb {G}_{1}\) with a negligible advantage, namely \(Adv_{\mathcal {A}}^{JOC-q-SDH}= \Pr \left[ (c,g^{\frac{1}{x+c}})\leftarrow \mathcal {A}(g,g^{x},\cdots ,g^{x^{q}}, \mathfrak {g},\mathfrak {g}^{x})\right] <\epsilon (\ell ),\) where \(c\in \mathbb {Z}_{p}-\{-x\}\).

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

Definition 4

(Decisional Diffie-Hellman (DDH) Assumption [18]). Let \(\mathcal {BG}(1^{\ell })\rightarrow (e,p,\mathbb {G}_{1},\mathbb {G}_{2},\) \(\mathbb {G}_{\tau })\). Give a 3-tuple \((\xi ,\xi ^{\alpha },\xi ^{\beta },T)\in \mathbb {G}_{1}^{3}\), we say that the decisional Deffie-Hellman assumption holds on \((e,p,\mathbb {G}_{1},\mathbb {G}_{2},\mathbb {G}_{\tau })\) if for all probabilistic polynomial-time (PPT) adversaries \(\mathcal {A}\) can distinguish \(T=\xi ^{\alpha \beta }\) or \(T=M\) with negligible advantage, namely \(Adv_{\mathcal {A}}^{DDH}=|\Pr [\mathcal {A}(\xi ,\xi ^{\alpha },\xi ^{\beta }, T=\xi ^{\alpha \beta })=1] -\Pr [\mathcal {A}(\xi ,\xi ^{\alpha },\xi ^{\beta },T=M)=1]|<\epsilon (\ell )\) where \(M{\mathop {\leftarrow }\limits ^{R}}\mathbb {G}_{1}\).

Note that the DDH assumption is believed to be hard in both \(\mathbb {G}_{1}\) and \(\mathbb {G}_{2}\) for the Type-III pairing [23] 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 [23]). Let \(\mathcal {BG}(1^{\ell })\rightarrow (e,p,\mathbb {G}_{1},\) \(\mathbb {G}_{2},\mathbb {G}_{\tau })\). We say that the symmetric external Diffie-Hellman assumption holds on \((e,p,\mathbb {G}_{1},\mathbb {G}_{2},\) \(\mathbb {G}_{\tau })\) if the decisional Diffie-Hellman (DDH) assumption holds on both \(\mathbb {G}_{1}\) and \(\mathbb {G}_{2}\).

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 Set-up, (ii) Registration, (iii) Ticket Issuing, (iv) Tag Verification and (v) Ticket Tracing. Moreover, we provide details of the mathematical operations involved in these interactions. Formal definitions of the algorithms presented in this section can be found in the full version of this paper [25].

5.1 System Set-Up

Figure 2 shows the details of the system initialisation in which the central authority \(\mathcal {CA}\) generates a master secret key, MSK, and the required public parameters, PP. 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. 2.
figure 2

System set-up algorithm

Full size image
Fig. 3.
figure 3

Registration algorithm

Full size image

5.2 Registration

Figure 3 depicts the registration processes. When registering with the \(\mathcal {CA}\), \(\mathcal {I}\), \(\mathcal {V}\), \(\mathcal {U}\) and \(\mathcal {CV}\) use the PP and generate their own secret-public key pairs. They then send their identities and associated public keys to \(\mathcal {CA}\) which, after receiving a registration request from an entity, uses MSK to generate the corresponding credential for them. Note that only the ticket issuer has two public keys, \(Y_I\) and \(\tilde{Y}_I\). The first one is used to sign the tickets while the second one is used to validate the ticket.

Fig. 4.
figure 4

Ticket issuing algorithm

Full size image

5.3 Ticket Issuing

During the ticket issuing process (shown in Fig. 4), the user \(\mathcal {U}\) defines \(J_{U}\) 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 \(\mathcal {I}\), \(\mathcal {U}\) creates pseudonyms, \((P_V, Q_V)\), for each \({ID_V}\in J_{U}\) 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 \(J_U\) and the pseudonyms to \(\mathcal {I}\) to convince him that she is a registered user and created the pseudonyms. Once \(\mathcal {I}\) has received this information and verified the proof of knowledge, he generates an authentication tag \(Tag_{V}\) for each \({ID_V}\in J_{U}\) as well as an overall \(Tag_{CV}\) for \(\mathcal {CV}\) 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 \(\mathcal {V}\) or the central verifier, \(\mathcal {CV}\). 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 \(\mathcal {U}\) 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.

Fig. 5.
figure 5

Tag Verification algorithm

Full size image

5.4 Tag Verification

The tag verification process is shown in Fig. 5. When the user \(\mathcal {U}\) wants to access a service, the ticket verifier \(\mathcal {V}\) send his identity information to the user which \(\mathcal {U}\) uses to look up the corresponding tag, \(Tag_V\). In order to access the service, \(\mathcal {U}\) must submit a proof of knowledge of her secret key alongside the relevant authentication tag \(Tag_{V}\) to prevent users from sharing authentication tags. \(\mathcal {V}\) 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, \(\mathcal {I}\). Step 3 can only be verified by \(\mathcal {V}\) as it requires the private key of the verifier. Only if \(\mathcal {V}\) can complete all steps successfully, is the user granted access.

Fig. 6.
figure 6

Ticket trace algorithm

Full size image

5.5 Ticket Tracing

Lastly, in the case that a user \(\mathcal {U}\)’s whole service information \(J_U\) needs to be traced, the central verifier, \(\mathcal {CV}\), sends its identity to \(\mathcal {U}\) who is then required to submit the information, \(\Pi ^2_U\), \(Tag_{CV}\), (which is the same information as that of the Tag Verification 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, \(\mathcal {I}\), in case the user is not co-operating.

On receipt of this information, the central verifier first validates that the submitted tag \(Tag_{CV}\) passes the standard verification process (see Sect. 5.4) as the central verifier’s \(ID_{CV}\) is always included in \(J_U\). As discussed previously, this steps ensures that \(\mathcal {U}\) 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 the user who presented it. Using his private key, the central verifier can now compute the user \(\mathcal {U}\)’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 \(J_{U}\).

6 Security Analysis

In this section we present the theorems which establish the security of our scheme. Their proofs can be found in the full version of this paper [25].

Theorem 1

(Unlinkability). An anonymous Single-Sign-On for n designated services with traceability scheme in Figs. 2, 3, 4, 5 and 6 is \(\varvec{(\rho _{1},\rho _{2},\rho _{3},\epsilon '(\ell ))}\) -selectively unlinkable if the DDH assumption holds on the bilinear group \((e,p,\mathbb {G}_{1},\mathbb {G}_{2},\mathbb {G}_{\tau })\) with the advantage at most \(\epsilon (\ell )\), and \(H_{1}, H_{2}\) are secure cryptographic hash functions, where \(\varrho _{1}\) is the total number of verifiers selected by \(\mathcal {A}\) to query tickets, \(\varrho _{2}\) is the number of ticket validation queries, \(\varrho _{3}\) is the number of ticket trace queries, \(\epsilon (\ell )=\frac{\epsilon '(\ell )}{2}\).

Theorem 2

(Unforgeability). An anonymous Single-Sign-On for n designated services with traceability scheme in Figs. 2, 3, 4, 5 and 6 is \(\varvec{(\varrho ,\epsilon '(\ell ))}\) -unforgeable if the JOC-version-q-SDH assumption holds on the bilinear group \((e,p,\mathbb {G}_{1},\mathbb {G}_{2},\mathbb {G}_{\tau })\) with the advantage at most \(\epsilon (\ell )\), and \(H_{1},H_{2}\) are secure cryptographic hash functions, where \(\varrho \) is the total number of verifiers selected by \(\mathcal {A}\) to query tickets, \(\varrho \le q\), \(\epsilon (\ell )=(\frac{p-q}{p}+\frac{1}{p}+\frac{p-1}{p^{3}})\epsilon '(\ell )\).

Theorem 3

(Traceability). An anonymous Single-Sign-On for n designated services with traceability scheme in Figs. 2, 3, 4, 5 and 6 is \(\varvec{(\rho ,\epsilon (\ell ))}\) -traceable if the q-SDH assumption holds on the bilinear group \((e,p,\mathbb {G}_{1},\mathbb {G}_{2},\mathbb {G}_{\tau })\) with the advantage at most \(\epsilon _{1}(\ell )\), the DL assumption holds on the group \(\mathbb {G}_{1}\) with the advantage at most \(\epsilon _{2}(\ell )\), and \(H_{1}, H_{2}\) are secure cryptographic hash functions, where \(\epsilon (\ell )=max\left\{ \frac{\epsilon _{1}(\ell )}{2}(\frac{p-q}{p}+ \frac{1}{p}+\frac{p-1}{p^{3}}),\frac{\epsilon _{2}(\ell )}{2}\right\} \), \(\varrho \) is the total number of ticket issuing queries made by \(\mathcal {A}\) and \(\varrho <q\).

7 Benchmarking Results

In order to evaluate the performance of our scheme, it has been implemented in Java using a benchmarking framework [17] to extract the computational timings of the algorithms. The benchmark was executed on a Dell Inspiron Latitude E5270 laptop with an Intel Core i7-6600U CPU, 1TB SSD and 16 GB of RAM running Fedora 27. Our implementation makes use of bilinear maps using elliptic curves as well as other cryptographic primitives. The implementation of the scheme relies on the JPBC library [16] for the bilinear maps and uses the cryptographic functions provided by bouncycastle [30]. Note that the Java based implementation of the JPBC API [16] was used throughout.

Table 2. Benchmark results (in ms)
Full size table

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 using bilinear maps or generation of zero knowledge proofs). The bilinear map used in the protocol implementations was a Type F elliptic curve provided by the JPBC library where G is the group of points of the elliptic curve and \(|G|=p\) is its prime order whose binary representation requires r-bits. We chose to benchmark primes p with \(r=160\) bits and \(r=320\) bits using 2 or 3 verifiers per ticket. The number of verifiers only impacts on the issuing and ticket tracing phases while the size of r impacts on all phases. The generation of credentials by the \(\mathcal {CA}\) for the issuer, user and the (central) verifiers during the registration phase of the protocol is on average around 12 ms for \(r=160\) bits and 30 ms for \(r=320\) bits while the verification of those credentials by the various parties takes about 300 ms and 650 ms for 160 bits and 320 bits respectively. It can be seen from Table 2 that the current implementation of the our scheme is reasonably fast for elliptic curves when \(r=160\) (e.g. \({\approx }1.5\) s and \({\approx }250\) ms for ticket issuing and verification respectively) and still acceptable for \(r=320\) bits (\({\approx }4\) s and \({\approx }600\) ms for the same steps). Moreover, it should be possible to improve the performance of the code considerably by pre-computing static values off-line where possible and switching from the current Java-based version to using a Java-wrapper to the C-based implementation of the pbc libraries [32], instead.

8 Conclusion and Future Work

Previous Anonymous Single-Sign-On schemes usually protect the user’s identity from other verifiers but not always the issuer nor the verifier to whom the user needs to authenticate. However, previously, the identity of these verifiers has not been considered extensively and neither has the need to ensure that only a designated verifier can validate a given access request. In this paper we proposed an Anonymous Single-Sign-On scheme which enables users and verifiers to remain anonymous throughout while protecting the system from misbehaving users through a central verifier who can, if required, trace the identities of a user and her associated verifiers. Moreover, we provided a formal security model and proofs for the security properties of our scheme as well as an implementation demonstrating the feasibility of deployment.

In our scheme, a user can currently only authenticate to a verifier once as there is only one authentication tag for each verifier in a user’s ticket. If the user needs to authenticate herself to a verifier, \(\mathcal {V}\), multiple times, she must request additional tickets with the required authentication tag for \(\mathcal {V}\) from the issuer. Our scheme could alternatively be amended to allow multiple authentication tags per verifier in each ticket. In this case the scheme’s security model and proofs would need to be amended to support this.

Anonymous Single-Sign-On was the main motivational use case for our scheme, but there are other scenarios to which the could be applied, e.g. the purchase of tickets for tourist attractions, where being able to issue a ticket through an Android implementation would be appropriate. Initial results however demonstrate that the timings on an Android client are significantly slower, for example ticket validation can take \({\approx }200\) times longer than on the laptop. Future work will focus on improving the scheme’s performance further (especially on the Android platform) by moving from a pure Java-based implementation to a C-based version as well as performing pre-computations of static values required by proofs of knowledge where possible. Lastly, extending our scheme with an option for users to enable the controlled release of personal information to a given verifier, e.g. by letting a user control which verifier is allowed to de-anonymise her authentication tag, is another area of future research.