Web services often require users to authenticate. In the classic setup, this authentication step requires users to memorize a different username and password pair for each service, and requires each service operator to maintain its own secure database of user credentials. As memorizing many passwords quickly becomes impractical, users tend to reuse them across services (ives2004domino). This leads to increased risks in the event of password leakage from a single, poorly managed service.
Single Sign-On (SSO) platforms have been proposed as an answer to the complexity and fragility of authentication with individual passwords. SSO enables the use of a unique identity provided by an Identity Provider (IdP) trusted for securely storing authentication information. Users authenticate themselves to services (called Relying Parties–RP) with tokens provided by their IdP. SSO reduces the complexity of websites by providing a standard, well-defined, and secure interface for user authentication. Web developers can focus on implementing business logic instead of custom and error-prone authentication modules. While SSO introduces centralization in the management of identities and authentication, it also lowers the risk of password leakage. Moreover, it simplifies the integration and adoption of secure authentication approaches such as 2-factor authentication (2FA) or the W3C Web Authentication standard (WebAuthn) (bonneau2012quest; webauthn), and therefore increases the general security of the web (goode2012importance).
OpenID Connect (OIDC) is the dominant SSO solution. Major web players such as Google or Facebook play the role of IdPs, offering so-called social login features to RPs previously registered with their services. As of 2019, more than one million websites support SSO via OIDC (openid-adoption). However, while facilitating identity management, the wide adoption of OIDC raises concerns on its users’ privacy and on the availability of relying websites (openid-problems; social-login-or-not-login). First, an IdP is aware of its users’ every sign-on attempt to RPs. The nature of visited websites may reveal private information about users (krishnamurthy2007measuring) (e.g., about their faith, their political views, or an interest in information about a specific illness). This IdP can even link a specific user’s accounts on different RPs, allowing to further learn private information by correlating interests. Second, an RP can learn users’ identities (e.g., email or social media account) from the SSO interaction with the IdP, even though this is unnecessary for authentication. This information can in turn be used by RPs to track users, especially when several RPs collude. Third, IdPs in OIDC are single points of failure. If an IdP is offline, its users cannot sign on with any RP. Combined with the need for each RP to register with specific IdPs a prior, this makes it difficult fo small organizations (e.g. digital rights NGOs, local governments) to commit to 100% availability, hence preventing them from entering the market and offering an alternative to tech giants’ IdPs–an alternative that would be welcome to counter the current trend towards Internet consolidation (arkko2019considerations).
Motivations. Protecting the privacy of users in SSO systems requires removing the direct communication between the RP and the IdP, i.e. making it happen indirectly. This avoids the inference by an IdP of its users’ connections to RPs. For instance, SPRESSO (fett2015spresso) prevents RPs from collecting authentication tokens issued by IdPs by using the user’s browser as a forwarder of their interactions. It requires, however, that users provide their actual identity (i.e., email address) to all RPs. As a result, SPRESSO prevents IdPs from collecting users’ activities, but does not protect users against malicious or colluding RPs. On the other end of the spectrum, Sign In with Apple (sia) lets users use different pseudonym identities (redirected email addresses) across RPs, but does not protect their privacy against the IdP.
In addition to the limitations in privacy protection, SSO systems are generally synchronous. They require that the IdP be available to generate authentication tokens whenever an RP sign-on operation is needed. For instance, PRIMA (asghar2018prima) requires the IdP to sign RP-specific nonces for every sign-on operations. Ideally users should be able to sign on RPs even when their IdP is temporarily offline, as long as the services provided by RPs are available.
Contributions. We present the design, security analysis and evaluation of EL PASSO, a new SSO system that:
fully preserves users’ privacy and choices in disclosure of their personal information, protecting their identity from RPs and sign-on activity from IdPs;
ensures that any temporary unavailability of their IdP does not prevent users from logging onto RPs.
EL PASSO decouples the communication between RPs and IdPs and uses anonymous credentials to offer strong privacy guarantees to users against an adversary observing their IdP and any number of RPs. At the same time, it also provides accountability guarantees to RPs about users signing on their services. Users convicted of fraudulent behaviors (e.g. authors of hate speech or harassment in an online forum, or publishers of illegal content) are eventually identifiable by selected authorities—and only them—in cooperation with the IdP. Users may also provide authenticatable personal information, such as being above a minimal age or coming from a certain geographical area, without sharing their exact age or location with the RP.
EL PASSO is an asynchronous SSO (see Figure 1). The generation of authentication material by the IdP is decoupled in time from its use by the user to sign on at some RP. This is in contrast with the synchronous interaction in OIDC, SPRESSO (fett2015spresso) or PRIMA (asghar2018prima) that require both services to be available for signing on. EL PASSO uses two separate phases: (i) a setup phase where a user obtains a credential over their attributes from the IdP and (ii) a sign-on phase where the verification of that user’s credential happens directly between them and the RP, and where that user can decide which attribute(s) they wish to reveal to the RP.
EL PASSO implements PS signatures (pointcheval) to provide an efficient anonymous credential scheme that protects users’ privacy and prevents the creation of Sybil accounts while providing user accountability. In contrast with U-Prove (paquin2011u; paquin2011uc), credential size in EL PASSO is independent of the number of unlinkable uses, and therefore of the number of RPs. Users combine credentials obtained in the setup phase with an RP identifier and a secret resulting in an RP-specific identity token. The token includes any number of attributes that the user wishes to disclose. Its authenticity and correctness can be verified by the RP using public IdP information. Optionally, users can be requested to include an encrypted identity hint in the token. Thus when a user misbehaves, the RP can submit this hint with the proof of misbehavior to authorities, which may decrypt it and de-anonymize the user.
The main contribution of this work consists of developing a complete, efficient and practical system using proven cryptographic primitives. The design of EL PASSO aims at the ease of deployment at both RPs and IdPs, and ease of integration with complementary solutions for strengthening authentication security (i.e., 2FA and WebAuthn). It requires no specific hardware for the user, IdP or RP, nor does it require the use of additional third parties. To facilitate the emergence of novel, privacy-conscious IdPs, EL PASSO does not require prior registration by RPs to IdPs and favors instead decentralized trust relations between these entities.
Our security analysis shows that the EL PASSO provides strong privacy guarantees, disallowing IdPs, RPs, and any colluding sets of these entities, from tracking the access of users to RPs or correlating accesses by the same user to different sites. At the same time, EL PASSO also protects RP from malicious users, enabling the detection of sybil anonymous identities, and supporting accountability with provable personal attributes and reliable identity retrieval.
We implemented a complete prototype of EL PASSO, which we will open source with the unblinded version of this paper. It combines a plugin for the Mozilla Firefox browser implementing user-side operations and two services for the RP and IdP. Our evaluation using representative user devices (a laptop and a low-power Raspberry Pi) and Amazon EC2 instances indicates that EL PASSO performance, costs, and scalability make it amenable for deployment at a large scale. Sign-on operations only require one round-trip between the user and the RP, resulting in improved sign-on latency compared to OIDC. While computations are required at the user side, sign-on operations take only about a second on a low-power device, and 450ms on a laptop. In contrast to other platforms based on anonymous credentials(cl; lee2013aggregating; idemix; camenisch2002design; alpar2017irma; brickell2004direct; chen2010design; bernhard2013anonymous), such performance makes EL PASSO fit for real-world deployment also on mobile devices. Finally, RP and IdP scale vertically and horizontally in the cloud, and allow throughput of more than 200 setup phases or more than 50 sign-on phases per second using only a 4-core EC2 server.
Outline. We first define our model and design goals in Section 2. We review the principles and operation of OIDC in Section 3. We present an overview of the design of EL PASSO in Section 4. We present its detailed construction, starting with background on anonymous credentials and zero-knowledge proofs in Section 5, followed by the protocol in Section 6 and its implementation in Section 7. We provide a security analysis in Section 8. Our evaluation is given in Section 9. We review related work in Section 10 and conclude in Section 11.
2. Design Goals
only legitimate IdPs users can authenticate,
no one (including IdPs) can impersonate users
|intra-RP linkability||prevent creation of Sybils within a domain|
|tracking protection||IdP is not aware of user sign-ons|
|selective disclosure||users discloses only necessary attributes|
|inter-RP unlinkability||sign-ons across multiple RPs cannot be linked|
|provable personal attributes||user attributes are attested by IdP|
|reliable identity retrieval||identity of misbehaving users can be revealed|
|asynchronous authentication||user can sign on RPs even if their IdP is temporarily unavailable|
|no RP registration||RP does not have to register with IdP|
|no additional hardware||no additional elements are required|
We start by defining our system and our adversary model. We follow up by specifying our target properties for authentication, but also privacy, accountability, availability, and ease of deployment. These properties are summarized in Table 1.
2.1. System and Adversary Model
There are three types of parties in the system: relying parties, identity providers, and users. A set of Relying Parties (RPs) are interested in allowing their users to sign on without creating a specific username and password for their services. Identity Providers (IdP) are trusted by RPs for certifying the authenticity of users. RPs can choose which IdPs they trust, but IdPs cannot choose which RPs may use their services. Users trust IdPs for safeguarding their identity and attributes but do not wish them to know the RPs they connect to. Users may allow each RP learning a subset of their attributes, such as their email, phone number, real name, social security number, or personal address. They do not wish, however, colluding RPs to be able to gain more information than what they have been individually allowed to receive. We consider two types of adversaries:
Honest-but-curious. The first type of adversary wishes to break the privacy guarantees offered to the users. It is honest-but-curious, i.e. it does not modify the protocol but may correlate observations from multiple IdPs and RPs vantage points. It cannot control what happens at the user side.
Rogue user. The second type of adversary is a rogue user wishing to abuse the system and break constraints associated with personal authentication. This adversary may control, observe and modify all operations and communications happening on its own device. It cannot control honest RPs or IdPs, but may set up a malicious RPs for the purpose of collecting authentication information from other honest users. Using such malicious RPs, it is able to run code in the web browser of this honest user, but similarly to the threat model of OIDC, we consider that this code runs isolated (sandboxed) from the rest of the system and is only able to access URLs and websites displayed by the browser.
2.2. Target Properties for EL PASSO
EL PASSO aims at providing the following properties:
Authentication. Naturally, the most fundamental of all requirements is to provide personal authentication. EL PASSO only allows legitimate users registered with an IdP to sign up and sign on with an RP. Furthermore, it prevents any other entity in the system, including IdPs, from accessing existing user accounts created at RPs.
Authentication requirements also include the prevention of Sybil identities, where a given user would create multiple identities for the same domain. RPs can detect multiple authentication attempts using credentials issued by the IdP for the same user (intra-RP linkability). This property reduces the need for genuineness checks such as CAPTCHAs in the registration process and improves user experience.
Privacy. The goal of privacy protection is to disclose only the necessary information to prove the user’s authenticity, while preventing the collection of any other private information. EL PASSO ensures three complementary properties. First, it is unfeasible for IdPs to track the sign-ons activity of their users onto different RPs, to prevent profiling and the resulting leakage of personal information (krishnamurthy2007measuring) (tracking protection). Second, only information authorized by the user from his/her authentication profile is communicated to RPs. A user can specify a subset of his/her attributes to be revealed (e.g. email address, but not last name) when signing up (registering) and signing on an RP. It is, therefore, not required to reveal a user’s username at the IdP to log on some RP (selective attribute disclosure). Finally, in the absence of common information, it is impossible for an adversary to correlate multiple accounts created from the same credential on different RPs (inter-RP unlinkability). For instance, an account on one RP disclosing the real name of a user cannot be correlated with another account that only revealed the user’s address.
Accountability. EL PASSO enables accountability to abide by laws and online regulations. This allows anonymous sign-on in a new range of scenarios such as finance or electronic democracy. Accountability can be enabled or disabled for each new sign-on credential, depending on the requirements of a specific RP. It takes two complementary forms. First, it can be necessary that certain attributes about users be certified, even if the user does not wish to share them in the clear (provable personal attributes). For instance, the 2005 Gambling Act of the United Kingdom (gamblingact) requires users of online casinos and gambling services to be at least 18 years old, and holds online services responsible to enforce the regulation. In this example, EL PASSO can provide a certificate that a specific user is over 18 years old, while his/her actual age does not need to be revealed.
Second, in case a user engages in reprehensible behavior such as publishing illegal content or hate crimes, authorities should be able to eventually hold him accountable in cooperation with the IdP. EL PASSO supports such reliable identity retrieval with either a single identified authority or with multiple authorities. In the latter case, the cooperation from multiple administrative domains is needed to retrieve the identity, preventing abuse by any single party. The enablement of reliable identity retrieval is under the responsibility of each RP. Users should be made aware of the possible enablement of reliable identity retrieval by a RP and must, therefore, provide the necessary and valid material.
Availability. SSO services have been used by increasing number of online services and become a critical part of many information systems (sun2011makes). Even large, highly redundant systems may experience downtimes, as exemplified by the recent 14-hour disruption of Facebook’s services in March 2019 (facebook_outage) or the Amazon AWS outage in 2018 (awsdown). In EL PASSO, a user does not need to be authenticated by the IdP each time they sign on with an RP; instead, users acquire their credentials periodically and can connect to RPs even when the IdP is temporarily offline (Asynchronous authentication).
Deployment. To facilitate its wide adoption, an SSO platform should be easy to deploy and should integrate with RPs and user-side applications. EL PASSO does not require an RP to register itself to IdPs before being able to trust authentication information about their users. We note that a corollary of this property is that it should be impossible for IdPs to impersonate each other. Furthermore, the sign-on process is universal and RPs do not need specialized operations for a specific IdP (no RP registration). Instead, this trust is only based on RP policies and publicly-available information. This improves system automation and mitigates Internet consolidation (arkko2019considerations), as RPs becomes more independent, and new, smaller IdPs can more easily enter the market.
On the user side, EL PASSO does not require specific hardware (e.g. a trusted execution environment such as Intel SGX or ARM TrustZone), physical device (e.g. an external fingerprint reader or a smart card) or extra network services to offer its functionalities. Finally, user-side code is lightweight enough to run in a variety of legacy desktop or mobile environments (no additional hardware).
3. Analysis of OIDC
While OpenID Connect (OIDC) adheres to some of the design goals listed in Table 1, we identify the design choices of OIDC that are inconsistent with other key target properties111We also analyze alternative designs and research proposals in Section 10, and find no existing system that provides all the identified properties in Table 1.. In the following, we analyze OIDC and present a comparison, illustrated in Figure 1.
OIDC is built on top of OAuth - an access delegation protocol, commonly used as a means for users to grant RPs access to information stored at an IdP (hardt2012oauth). OAuth requires users to give their consent for data sharing once. Consequent data transfers happen between the RP and the IdP without user interaction. Such an approach allows an RP to access user data even when a user is offline. OIDC inherits this tightly coupled message flow. Initially, an RP must register with each IdP it wants to support. The RP receives a secret that will be used later to retrieve user information222OIDC specification also includes a discovery module allowing RPs to work with IdPs they did not register with beforehand and perform the registration process “on the fly”. However, this variant is not widely deployed.. Figure 2 details the OIDC protocol. When a user wants to sign on with a website held by an RP, they select one of the IdPs that are supported by that RP. The RP redirects the user to the chosen IdP including a list of requested attributes (e.g. email address, phone number). The user must then give their consent to share the requested information. If the access is granted, the IdP responds to the RP with an ID token containing the signed user’s identity (if using the “implicit flow”) or returns an access code allowing RPs to fetch the ID token (when using the “code flow”). The code flow requires the RP to use its secret obtained upon registration. It is suggested as the more secure way of fetching user information, as it does not expose the token to the user’s web browser and potentially malicious add-ons333There exists a third “hybrid” flow that we omit in this discussion as it does not influence the properties of the protocol..
Due to this coupling, the design of OIDC is intrinsically unable to provide user tracking protection. The property of selective disclosure is dependent on the goodwill of the IdP, and the lack of inter-RP unlinkability makes it possible for an adversary controlling multiple RPs to collect more information than allowed by the user. The synchrony in the generation of the authentication token by the IdP and its use with the RP, also prevents OIDC from providing asynchronous authentication, requiring the IdP to be always available for users to sign on RPs.
4. Overview of EL PASSO
In this work, we recognize an important role of the IdP as a trusted party in the system, able to reliably confirm users’ identities and hold them accountable if necessary. However, we decouple the communication between IdPs and RPs and enable users to asynchronously derive RP-specific tokens, based on a generator acquired from the IdP (Figure 1). The generation and use of tokens are divided into two asynchronous phases (Figure 3). In the setup phase, a user obtains an anonymous credential from their IdP. In the sign-on phase, the user prepares an RP-specific version of the credentials, decides what information to disclose and proves their authenticity to the RP. The setup phase is executed periodically (e.g. once a month), while the sign-on phase is executed each time the user logs in or creates an account on an RP.
Setup phase. The user first authenticates to their IdP and runs RequestID to request a credential from the IdP (➊) over a random attribute acting as user secret; is hidden from the IdP. Users can also specify which information they need to be embedded in their credentials, such as their email address, names, or age. If the IdP successfully authenticates the user, verifies the user’s knowledge of the secret , and knows the requested information about the user, it runs ProvideID to issue a credential embedding that information as well as a long-term pseudonym unique to the user and a timestamp marking the expiration date of the credential (➋). The IdP also keeps for the user in their database, where is a public parameter. The user locally runs UnblindID to unblind the received credential (➌). Importantly, the IdP (or anyone else) is unable to use the credential on behalf of the user as this would require knowing the user secret .
Sign-on phase. The user connects to the RP and executes ProveID to prove knowledge of the credential issued by the IdP (➍). In this process, (i) the user locally randomizes their credentials so that even if an attacker observes both the RP and the IdP, it cannot link it to a specific user of this IdP. (ii) The user provides the RP with the randomized credential and the expiration time , and selectively discloses any subset of information embedded in the credential. (iii) The user locally generates a group element uniquely derived from the user’s secret and the RP’s DNS domain name, and proves in zero-knowledge its correctness; the RP uses this group element as the user ID. Once the RP verifies the credential along with the proofs, they consider the user as authenticated (➏).
To verify that the credential was initially issued by a trusted IdP, an RP must collect the public key of this IdP; since the setup and sign-on phases are asynchronous, the RP can fetch the public key from the IdP domain directly, by issuing a GET request over HTTPS to the IdP444The IdP cannot correlate a previous setup phase with the current sign-on phase at this RP. This contrasts with synchronous designs such as SPRESSO (fett2015spresso) where the collection of public parameters must happen via Tor to prevent time-based attacks by the IdP.. This requires the IdP to be online for a sign-up operation (creation of a new account), but the RP can cache this public key for future sign-ons, enabling asynchronous authentication. Since the credentials are randomized (as part of ProveID) and the alias changes for each RP without leaking , a user can employ the same credential to authenticate to different RPs. At the same time, different sign-ons to different RPs are unlinkable even if observed by the same adversary. A user cannot create multiple accounts with a single RP since is bound to the user’s secret embedded in a credential and the RP’s DNS domain name; it is infeasible to create two different over the same RP’s DNS domain name from a single credential.
To mitigate risks of correlation of requests at different RPs by the honest-but-curious adversary, the time-stamp should be rounded or limited to denominations fixed by the IdP555Alternatively, instead of revealing the time-stamp upon execution of ProveID, the user can prove in zero-knowledge that the timestamp is greater than the current date (but this requires a potentially expensive range-proof).; e.g. specifying an expiration day, but omitting more detailed information such as hours, minutes and seconds.
Finally, if support for reliable identity retrieval is required by the RP, the user must provide and prove the correctness of an El-Gamal encryption of their long-term pseudonym encrypted under the public key of specific decryption authorities, as part of the ProveID operation. If the user misbehaves, the RP discloses to these decryption authorities, which decrypt it to recover , and then collaborate with the IdP to recover the identity of the user. EL PASSO supports flexible key management for decryption authorities—the ciphertext can be encrypted under a single key or use threshold encryption, where at least a threshold number of decryption authorities are needed to recover the user’s identifier.
We present our building blocks, anonymous credentials and zero-knowledge proofs, and our cryptographic assumptions.
5.1. Anonymous Credentials
Anonymous credentials (amac; pointcheval) allow the issuance of credentials to users, and the subsequent unlinkable revelation to a verifier. Users can selectively disclose some of the attributes embedded in the credential or specific functions of these attributes. EL PASSO requires a credential scheme providing short and computationally efficient credentials, re-randomization, unlinkable multi-show selective disclosure, and blind issuance (amac). An anonymous credential scheme can be defined by the set of algorithms below.
- ❖ Cred.Setup() ()::
define the system parameters with respect to the security parameter . These parameters are publicly available.
- ❖ Cred.KeyGen() ()::
run by the authority to generate their own secret key and public key from the public parameters .
- ❖ Cred.Issue() ()::
interactive protocol between the user and the authority; the user obtains a credential embedding the set of hidden attributes and the set of public attributes if they satisfy the statement . Cred.Issue is composed of three algorithms:
❖ Cred.PrepareBlindSign() (): run by the user to generate the blind factor , and the cryptographic material (embedding ) over which the authority blindly issues a credential.
❖ Cred.Sign() (): run by the authority to issue the blinded credentials over and , using their private key .
❖ Cred.Unblind() (): run by the user to unblind (using the factor ) to retrieve the credential .
- ❖ Cred.Prove() ()::
run by the user to compute a proof proving possession of a credential certifying that the private attributes and the public attributes satisfy the statement 666Note that may be different from . (issued by the authority identified by the public key ).
- ❖ Cred.Verify() ()::
run by any third party verifier to verify that the credential represented by the cryptographic material embeds as well as hidden attributes satisfying the statement , using the public key of the issuing authority.
All the algorithms receive the security parameter as input but we show it explicitly only for Cred.Setup. EL PASSO uses PS Signatures (pointcheval) as the underlying credentials scheme as it uses short, and computationally efficient credentials. We use PS Signatures for the generation of credentials by the IdP, and for the verification of credentials by RPs on both known messages (e.g., timestamp ) and hidden messages (e.g., user’s secret ).
5.2. Zero-knowledge Proofs
Zero-knowledge proofs are protocols allowing a prover to convince a verifier that it knows a secret value , without revealing any information about that value. The prover can also convince the verifier that they know a secret value satisfying some statements . Anonymous credentials extensively employ zero-knowledge proofs to provide users with certified secret values; users are successively able to prove to third party verifiers that they hold secret values certified by specific credentials issuers, and prove statements about those values without disclosing them. This enables, for instance, the property of provable personal attributes. A credential issuer may provide a user with a secret value representing their age; the user can then prove in zero-knowledge to a verifier that a specific credential issuer certified that their age is larger than 18, without revealing their real age .
EL PASSO uses non-interactive zero-knowledge proofs (NIZK) to assert knowledge and relations over discrete logarithm values. These proofs can be efficiently implemented without trusted setups using sigma protocols (schnorr)
, which can be made non-interactive using the Fiat-Shamir heuristic(RFC8235) in the random oracle model.
5.3. Cryptographic assumptions
EL PASSO inherits the same cryptographic assumptions as PS Signatures, which requires groups of prime order with a bilinear map and satisfying (i) Bilinearity, (ii) Non-degeneracy, and (iii) Efficiency. We use type-3 pairings because of their efficiency (galbraith2008pairings), and therefore rely on the XDH assumption which implies the difficulty of the Computational co-Diffie-Hellman (co-CDH) problem in and , and the difficulty of the Decisional Diffie-Hellman (DDH) problem in (bls). We also rely on a cryptographically secure hash function , hashing a string into an element of ; i.e. applying a full-domain hash function to hash this string into an element of (such as BLS (bls)).
6. EL PASSO Construction
We present the construction of EL PASSO satisfying all properties described in Section 2.2, and then discuss how to simplify it when reliable identity retrieval is not required or if the user wishes to sign on as guest without establishing an identity with the RP. We discuss the implementation of the protocol steps in Section 7 and their security guarantees in Section 8. EL PASSO primitives (see Figure 3) are defined as follows:
Bootstrapping the IdP. The following algorithms are executed only once, when bootstrapping the IdP.
- ❖ Setup() ()::
Describe the publicly-available system parameters with respect to the security parameter .
- ❖ KeyGen() ()::
Run by the IdP to generate their own secret key and public key from the public parameters .
Setup phase. We describe the algorithms implementing the setup phase of EL PASSO; these algorithms are executed periodically, when the user requests a credential from the IdP.
- ❖ RequestID() ()::
set and ; run = Cred.PrepareBlindSign(); output .
Run by the user to request a credential from the IdP, generating the cryptographic material embedding the user secret .
- ❖ ProvideID() ()::
set ; output = Cred.Sign().
Run by the IdP to provide the user with a blinded credential over , the user identifier , and some user attribute ; the credential has an expiration date , and is produced from the IdP’s secret key .
- ❖ UnblindID() ()::
set ; output .
The user locally unblinds the credential using the blinding factor , and outputs the credential .
Sign-on phase. We describe the algorithms implementing the sign-on phase; these algorithms are executed each time the users logs in or creates an account on an RP.
- ❖ ProveID() ()::
split into and , respectively containing the attributes to disclose and to hide from the RP. Set and ; pick a random and compute the El-Gamal ciphertext , where and are generators of , and is the aggregated public key of the decryption authorities; compute
(where is a hash function as defined in Section 5.3.) and the statement
compute = Cred.Prove(); output
Run by the user to show the RP a proof of ownership of a credential whose attributes satisfy the statement ; this proof is generated from the RP’s public domain , and from the parameters . The subset of hidden attributes satisfy the function .
- ❖ VerifyID() ()::
compute and use it to verify = Cred.Verify(); output if the verification passes and the time-stamp is not expired; otherwise output .
Run by the RP to verify that is a proof of knowledge of a valid credential (issued by the IdP identified by the public key ) whose attributes satisfy the statement ; the proof is verified using .
Removing reliable identity retrieval. In case support for reliable identity retrieval is not required by the RP (see Section 4), we can simplify the sign-on phase of the above scheme by omitting the ciphertext ; the statement would then become , and the zero-knowledge proof shorter by two field elements (if implemented, for instance, using Schnorr’s protocol (schnorr)).
Login as guest. In case the user wishes to sign on as guest without establishing a permanent used ID with the RP, and if the RP allows such guest sign-ons, we can simplify our scheme by omitting the group element ; the statement would then become , which shortens the proof by one field element. As a result, the RP has no way to distinguish multiple sign-ons from the same user (this follows directly from the unlinkability properties of the underlying credentials scheme). The interaction between the user and the RP is still anonymous and accountable.
Anonymous credentials. We implement EL PASSO using PS Signatures signatures as the underlying credential system because of its short credentials and efficient verification. Our prototype implementation of PS Signatures in Python is based on the description by Pointcheval and Sanders (pointcheval), over the curve MNT224 777Using a stronger curve, such as BLS381, is recommended for production. and using the cryptographic library pycharm (charm-crypto).
State overhead. We detail the state overhead that each party needs to maintain. EL PASSO requires the IdP to store their own key pair and a (42 bytes) for each of its users; RPs store the public key of each IdP they trust as well as the ciphertext (84 bytes) and group element (42 bytes) for each of their users. Since our implementation is based on PS Signatures, the size of the public key of the IdP increases linearly with the number of attributes, ranging from 758 bytes (for 3 attributes) to 3478 bytes (20 attributes), while the private key has a fixed size of 84 bytes. Users store all the input parameters of ProveID, that is, they store their attributes (, , , ), their credential (84 bytes), the public key of the IdP who issued the credential, and the public key (42 bytes) of the decryption authorities (when reliable identity retrieval is required). All parties are aware of the public parameters (generated by Setup). In the simplest scenario where there exits one IdP, one user, and one RP, assuming there are 3 attributes and reliable retrieval is needed, the total state required at the IdP, the user, and the RP are 884 bytes, 972 bytes, and 884 bytes, respectively.
8. Security Analysis
We start by analyzing the security of EL PASSO against the properties defined in Section 2.2
. We discuss next how to extend the security and the fault model. Finally, we discuss known attacks against incorrect OIDC implementations and the sensitivity of EL PASSO to similar attack vectors.
8.1. Security properties of EL PASSO
Authentication. EL PASSO preserves authentication against rogue users. Authentication relies on the unforgeability of the underlying credential system—it is unfeasible for rogue users to execute ProveID without holding a valid credential issued by the IdP. Furthermore, rogue users cannot connect multiple times to the same RP pretending to be different users. ProveID requires the user to provide the RP with a group element that is uniquely derived from the RP’s DNS domain name and the unique user secret . It is unfeasible to create more than one using the same credentials (i.e. the same secret attribute ) and the same domain; therefore, a user cannot register multiple accounts with one credential on the same RP. The blind issuance and zero-knowledge properties of the underlying credentials system guarantee that the user secret attribute is never revealed to the IdP (nor to any other party); hence an honest-but-curious IdP or a fake RP under the control of a rogue user cannot impersonate existing users and access existing accounts that these users have with other RPs.
Privacy Protection. EL PASSO provides privacy protection against honest-but-curious IdPs and RPs. The privacy guarantees of EL PASSO rely on the security (blind issuance and unlinkability) of the underlying credential scheme, and on the zero-knowledge property of the selected NIZK scheme. The blind issuance property of the underlying credential scheme ensures that RequestID does not leak any information about the secret attribute to an honest-but-curious IdP; and zero-knowledge ensures that ProveID reveals to honest-but-curious RPs no additional information about users’ attributes than what is selectively disclosed by the user. To complete the argument, note that (i) revealing does not leak , and changes indistinguishably for each website’s domain (assuming a random oracle); and (ii) the ciphertext hides (by the security of El-Gamal encryptions) under the assumptions of the underlying cryptographic primitives.
Accountability. EL PASSO guarantees reliable identity retrieval against rogue users. ProveID requires users to provide RPs with a ciphertext , and prove in zero-knowledge that it is correctly formed; therefore, RPs can check that is a valid encryption of the user’s long-term identifier when the user signs in, even without decrypting it. If the user later misbehaves, the RP can report to a subset of the decryption authorities (identified by the public key ) that can recover the user’s long term identifier , and then collaborate with the IdP to recover the user’s real-world identity.
When executing ProveID, users can only disclose or prove statements about attributes that are certified by the IdP (i.e. they cannot add, remove, or modify attributes); this follows from the unforgeability of the underlying credential system, and enables the property of provable personal attributes.
Availability. ProveID and VerifyID are executed as part of an interactive sign-on protocol between the user and the RP. The IdP does not take part in this protocol and therefore does not need to be available, provided that the public key is cached at the RP, which happens during user sign-up.
Deployment. RequestID, issueID and UnblindID are executed as part of an interactive protocol between the user and the IdP—the RP does not take part in this protocol and therefore does not need to register with (or be known by) the IdP. As a result, the IdP does not need to be aware of the existence of any RP, but RPs need to know the public key of the IdP in order to execute VerifyID.
8.2. Limitations and Extensions of Adversary Model
We now discuss limitations and possible extensions to the adversary model defined in Section 2.1.
First, EL PASSO only considers honest-but-curious IdPs; that is, arbitrarily malicious IdPs are not part of the threat model. An actively malicious IdP can break authentication by self-issuing credentials to impersonate specific users or create fake identities; and can break accountability by refusing to cooperate with decryption authorities. It cannot, however, access an existing user account with an RP, as this is bound to the user secret . We defer the protection against malicious IdPs to future work, e.g. by extending distributed SSO solutions, where a set of IdPs must collectively authenticate a user and provide it with shares of their identity (zhong2009novel; camenisch2019distributed).
Second, EL PASSO considers that the rogue user adversary may inject code through a malicious RP, to run in the browser of a target honest user, but that this code is sandboxed from the rest of the user environment. If the adversary can control the user device, e.g. by installing a malicious plugin in their browser, it may steal the credentials of that user (e.g. using a keylogger (holz2009learning)), authenticate with their IdP and impersonate them. It would be necessary under such an adversary to harden the authentication phase with the IdP. A first solution is to systematically require two-factor authentication (2FA) in the setup phase. As for OIDC implementations, which do not require re-authenticating with the IdP using 2FA for every sign-on operations, the frequency of 2FA is a compromise between convenience and security, and can be adjusted with timestamp upon issuance of the credential. We note, however, that the asynchronous nature of EL PASSO prevents re-using some of the existing safety checks performed at the IdP in OIDC implementations, such as checking for unusual origin locations of authentication requests. Such safety checks must, instead, be implemented at the RP side, possibly using provable personal attributes. A second solution is to use secure login solutions such as the W3C Web Authentication protocol, WebAuthn. This standard requires the use of an external trusted device, the authenticator, for storing private keys and verifying users identity (e.g. using biometrics or passcodes). The growing availability of Trusted Execution Environments such as Intel SGX or ARM TrustZone in user’s devices could help to implement authenticators and to generalize the use of public-key authentication with IdPs.
8.3. Sensitivity to Known Attacks on OIDC
We discuss attacks and exploits against incorrect implementations of OIDC (fett_extensive_2019), and the extent to which EL PASSO’s design prevents similar attack vectors.
A first category of attacks exploits the coupling between the RP and the IdP in OIDC. IdP Mix-Up Attacks (mainka_sok:_2017; jonesoauth) trick an honest RP to connect to a malicious IdP following the issuance of an access token, and repeating authorization codes from the user to this malicious IdP. EL PASSO uses a direct interaction between the user and the IdP, which is simpler to implement and reduces the potential for exploits.
A second category of attacks exploits the fact that in OIDC, a part of the communication between the IdP and an RP is relayed by the user browser using HTTP redirects. Code/Token/State Leakage (jones2017oauth; fett_web_2017), CSRF Attacks and Third-Party Login Initiation (fett2016comprehensive) are examples of exploits on incorrect OIDC implementations that do not properly check redirects or embed sensitive information such as ID tokens on redirection URLs. 307 Redirect Attack (fett2016comprehensive) similarly exploit the improper use of HTTP redirection codes. EL PASSO only uses direct interactions between the user device and the IdP, in the setup phase, or an RP, in the sign-on phase, again reducing the risk of improper implementation and exploits.
We evaluate the EL PASSO prototype on desktop and low-power devices for the user side and cloud resources for the RP and the IdP. We also compare with an OIDC implementation. We wish to answer the following research questions:
Are EL PASSO costs and latency adequate to replace OIDC as an SSO solution?
Does the use of cryptographic operations at the user side impair the deployment of EL PASSO on low-power devices, such as mobile phones or tablets?
What is the scalability of EL PASSO when using an increasing number of attributes in users’ profiles?
How does the implementation of the IdP and RP scale up when deployed in the cloud?
Setup. We deploy an IdP and an RP on two m5ad.xlarge instances on Amazon EC2 (4 virtual cores, 16 GB of RAM each), both in the Ireland EC2 region. We use two representative user devices: A Dell Latitude 5590 laptop with an Intel Core i7-8650U CPU and 16 GB of RAM, and a Raspberry PI model 3b (RPI). The RPI is a low-power device with an A53 quad-core ARMv8 CPU and 1 GB of RAM. It is representative of the performance of lower-end mobile devices such as phones or tablets. User operations (e.g., entering a username and password) are emulated and instantaneous, to focus on the performance of the protocol. We are open sourcing our implementation, benchmarking scripts, and measurements data to enable reproducible results888 https://github.com/Zhiyi-Zhang/el-passo .
Comparison to OIDC. In addition to EL PASSO, we deploy pyoidc (pyoidc), a complete implementation of OIDC. Both pyoidc and EL PASSO are implemented in Python. Note that the co-location of the RP and the IdP in the same EC2 zone also applies to the deployment of OIDC; we emphasize that this co-location is actually in favor of OIDC when measuring operation latencies. We evaluate pyoidc with its default settings where a standard Id token is included in the AuthN response and a single attribute is retrieved by the RP. All interactions in pyoidc and EL PASSO happen over HTTPS.
Latency and costs. We start with an evaluation of the latency of operations in EL PASSO and in OIDC. We use the laptop client, and credentials with the minimal number of 3 attributes , , and . We analyze the impact of changing the number of attributes in a later experiment. Figure 4 presents the complete latencies, as perceived by the user. These latencies include the latencies to and from the cloud, which we measured to be on average 20 ms round-trip. We present also the breakdown of computational phases in the two protocols in Figure 5, and the size of the payload of exchanged messages in EL PASSO in Figure 6.
For EL PASSO, we separate the asynchronous setup and sign-on phases, while sign-on in OIDC is a single, synchronous and coupled operation. We observe that authentication in OIDC takes less time than the two phases combined, in part because the RP and IdP are located in the same EC2 region999In most deployments, they would be deployed in different data centers, and the RP-IdP round-trip time would add to the overall latency.. However, the setup phase only takes place once per credential validity period, and in the majority of cases where credentials are already available at the user, perceived latencies for sign-on will actually be lower with EL PASSO than they are with OIDC.
The breakdown of computational operations in Figure 5 allow identifying the CPU time required by the different phases (note network latencies are not shown in the breakdown). OIDC does not require operations at the client but imposes most of its CPU time to the IdP. In contrast, EL PASSO requires little CPU time from the IdP, and only during the setup phase. Overall, computational costs are slightly higher for EL PASSO, but they are also more decentralized, impacting mostly users and RPs.
The amount of payload exchanged, shown by Figure 6, is reasonable. The largest payload is the sign-on request from the user to the RP, and is 1.8 KB in size. We conclude this first set of experiments with a positive answer to our first question: EL PASSO latencies and cost compare favorably to those of OIDC and would allow for deployment as an alternative SSO solution with negligible impact on performance or costs for users and operators of online services.
Performance on low-power devices. As the previous experiment has shown, EL PASSO requires computation and therefore CPU time at the user. We evaluate in this experiment whether these costs are acceptable for using it on low-power devices, such as mobile phones, tablets, or connected appliances. Our setup is the same as with the previous experiment, but using the RPI device instead of the laptop.
|Operation||Latency[s]||CPU time @ user [s]|
|EL PASSO Setup||0.77 (+190%)||0.16 (+297%)|
|EL PASSO Sign-on||1.00 (+125%)||0.38 (+490%)|
Table 2 compares the perceived latency using the RPI to those in Figure 4, and the total CPU time at the user, compared to Figure 5. We can observe that the CPU cost for the setup phase almost triples, yet remains low at 160 ms. For the sign-on phase, the cost is multiplied by 5, primarily due to the lower performance of cryptographic operations on the ARM CPU. Yet again, the overall CPU time remains within acceptable boundaries at less than 400 ms. The overall latency is impacted by both this increase in CPU time (except for OIDC), and the performance of the browser running on the RPI (including for OIDC). All operations succeed in a reasonable time, the longest being the sign-on taking a second on average, only slightly higher than OIDC compared to the previous experiment. This allows us to answer positively to our second question: The performance and costs of EL PASSO make it adequate as a solution for SSO, even when users are equipped with low-power or mobile devices.
Scalability in the number of attributes. We investigate the impact of the number of attributes embedded in user credentials on the computational cost of EL PASSO. The two first plots of Figure 7 show the evolution of CPU time with a growing number of attributes all of which are hidden from RP. Note that the case of 3 attributes corresponds to the data in Figure 5. As expected, the CPU time increases linearly for both the setup phase and sign-on phase (first and second plot, respectively). This increase is primarily due to the additional complexity of the ProveID operation, due to the need to, respectively create, and validate zero-knowledge proofs for more values. Yet, the total cost, even with 13 attributes, remains reasonable, less than a second of total CPU time. The third plot evaluates the cost of the sign-on phase when the user decides to hide an increasing number attributes from the RP, from a profile with 12 attributes: An abscissa value of 9 means, therefore, that the preparation of the credential for this RP only reveals 3 attributes101010Our design requires at least 2 attributes (, ) to be hidden from RPs. As expected, hiding more attributes increases the computational load in the ProveID and VerifyID parts of the algorithm, yet again requiring less than a second of total CPU time. We conclude, therefore, that EL PASSO scales sufficiently well with the number of attributes to be used in practical scenarios, where the identity of a user is formed of up to a dozen different fields, answering our third question.
Scalability of the IdP and RP. In this last experiment, we measure the scalability of the EL PASSO implementation in the cloud, for a large number of clients. We inject a growing number of precomputed requests in parallel from the laptop client and measure the achieved throughput and operation latencies. Figure 8 is a parametric plot showing the relation between the two measurements. The simpler operations required by the setup phase allow a single IdP node to handle up to 266 requests per second. The costlier sign-on phase at the RP lowers the number of operations per second to about 55111111We note that operations at the IdP and RP for different users are naturally disjoint-access parallel, if the user information is stored in a scalable NoSQL database. This allows scaling the IdP or RP horizontally as necessary.. These final measurements prove that EL PASSO, while involving privacy-preserving mechanisms can still be easily deployed on commodity cloud servers, and positively answer our fourth question.
10. Related Work
|System||Personal Authentication||Intra-RP Linkability||Tracking Protection||Selective Disclosure||Inter-RP Unlinkability||Provable Personal Attributes||Reliable Identity Retrieval||Asynchronous Authentication||No RP registration||Tools required|
|OpenID Connect (openid)||✗||✓||✗||✓||✓||✗||✗||None|
|Apple SignIn (sia)||✗||✓||✓||✓||✓||✗||✗||None|
|UProve (paquin2011u; paquin2011uc)||✓||✗||✓||✓||✗||✓||✓||None|
Tracking Protection UnlimitID and UnlimitID-based NextLeap rely on unlinkable credentials. However, the blinded credentials must be deposit by the users at IdP, potentially allowing IdP to perform user tracking. — Selective Disclosure OIDC, Apple SignIn and SPRESSO allow to disclose a subset of user information, but are unable to prove statements about their attributes (i.e. age ¿ 18). PRIMA supports proving statement about attributes only if they are expressed as additional attributes signed by IdP.
We review related work on SSO, starting with standards, and proceeding to discussions of privacy-preserving approaches. We also cover the WebAuthn standard and the use of anonymous credentials. We classify mainly discussed systems inTable 3 using the properties defined in Section 2 and summarized in Table 1. OIDC was already covered in Section 3.
SSO Standards. The Security Assertion Markup Language (SAML) (hughes2005security) is an XML-based authentication protocol, widely deployed before OIDC was standardized. It uses a message flow that is very similar to that of OIDC, therefore inherits its privacy vulnerabilities. Furthermore, SAML does not enable selective attribute disclosure and provides less flexibility to the developers than OIDC.
OIDC combines the previous Open ID identity management standard with the OAuth authentication protocol (hardt2012oauth). The privacy issues of these protocols were pointed out as being a result of the direct IdP and RP communication (openid-problems).
WebAuthn. The W3C Web Authentication standard manages the secure storage and use of individual private/public key pairs, one for each website. This mitigates the risks associated with password reuse and stealing. WebAuthn is a possible complement to SSO, to secure the user authentication on the IdP. WebAuthn requires support in user browsers, as EL PASSO. It considers a stronger fault model where the user device may also be corrupted and requires, therefore, a specific secure device, the authenticator, to securely store user credentials and authenticate users (e.g. using a fingerprint reader). The manufacturer of this device must be trusted by the user and websites. Thanks to its decentralized nature, WebAuthn naturally preserves its users from tracking. However, it does not provide accountability support.
Privacy-preserving SSO. Sign In with Apple (sia) is a tracking protection mechanism provided by Apple Inc. It uses randomized per-RP identifiers (alias email addresses) for users instead of permanent identifiers (e.g. actual email address). The IdP implements the email redirection. This solution provides inter-domain unlinkability. However, Apple has largely adopted OIDC for its implementation (openid-sia; sia). Thus the IdP-side privacy concerns also hold true for Sign In with Apple.
SPRESSO (fett2015spresso) decouples the communication between the RP and the IdP, letting the two parties communicate indirectly through a forwarder agent at the client. A user sign-on request to an RP is followed by a synchronous user request to the IdP for credentials. Similar to EL PASSO, the RP then obtains public information generated by the IdP for validation, if it does not already have a cached copy. The synchronicity of operations requires protection against time-based attacks, where the IdP could correlate requests from the user and the RP. The interaction between RPs and IdP must, therefore, happen through the Tor anonymization network. In contrast, EL PASSO does not require users to communicate with the IdP when signing on with an RP, thus preventing such an attack and allowing the RP to fetch information from the IdP directly. On the other hand, SPRESSO does not require using a stateful component at the client as EL PASSO does, which is required for its asynchronous operation.
UnlimitID (isaakidis2016unlimitid) builds attribute-based SSO credentials over aMAC (amac), used as pseudonyms. This allows inter-RP unlinkability, as IdPs are unable to track user activity over different RPs using different pseudonyms. UnlimitID follows the main flow of OIDC and requires users to deposit their anonymized pseudonyms at IdP before RPs can access them. This may allow the IdP to correlate the deposit of a pseudonym and its request by an RP, enabling tracking. The NextLeap project (halpin2017nextleap) intends to extend UnlimitID (isaakidis2016unlimitid) by storing identity and trust information in a blockchain, positioning that this would remove the need for RPs to explicitly register with IdPs, as is the case in EL PASSO.
PRIMA (asghar2018prima) decouples communications between RP and IdP and supports selective attributes disclosure on top of Oblivion (simeonovski2015oblivion). However, it requires contacting the IdP for every user sign-on and does not provide inter-RP unlinkability.
Anonymous authentication. Anonymous credentials such as CL Signatures (cl; lee2013aggregating) and Idemix (idemix; camenisch2002design) are useful in a number of privacy preserving applications like personal identity management (alpar2017irma), anonymous attestation (brickell2004direct; chen2010design; bernhard2013anonymous), and electronic cash (canard2015divisible). They provide blind issuance and unlinkability through randomization, which come with significant computational overheads, and large credentials size. Credentials size also grows linearly with the number of signed attributes, and are not aggregatable. IRMA (alpar2017irma) aims for a practical implementation of those schemes, but inherits from the above the limitations which makes it infeasible in practice. U-Prove (paquin2011u; paquin2011uc) and Anonymous Credentials Light (ACL) (acl) are computationally efficient credentials that can be used once unlinkably; therefore the size of the credentials is linear with the number of unlinkable uses. They can be used for SSO and enable asynchronous authentication, but are difficult to deploy in practice as the overheads increase linearly with the number of RPs a user wishes to connect. Furthermore, they do not allow an RP to distinguish different sign-on attempts by the same user, and cannot provide intra-RP linkability.
Anonymous password-authenticated key exchange (PAKE) solutions (viet2005anonymous; shin2010anonymous; yang2008new) allow users to authenticate using individual passwords at different websites (equivalent to RPs), while remaining anonymous. A connected user is indistinguishable from other users, yet can be authenticated as being one of the valid users–a different problem than the one we consider in this paper, where we want RPs to be able to identify which of their users is connecting without requiring that user to memorize a specific password. The aforementioned PAKE schemes require, however, the authentication server to perform an amount of computation that increases linearly with the number of users and require costly homomorphic encryption to resist off-line dictionary attacks (zhang2016practical).
In combination with anonymous credentials, multiple works propose to prevent (tsang2007blacklistable; camenisch2006win; brands2007practical) or limit (henry2011formalizing) login attempts of specific users without revealing their identities. While those platforms can block misbehaving users from accessing a specific RP, they are unable to hold these users accountable for their actions (e.g. when publishing hate speeches online). Finally, these blacklisting systems require significant computational and communication overhead, limiting their usability and deployability, which are essential goals for EL PASSO.
We presented EL PASSO, an SSO solution that decouples the interactions between IdPs and RPs to improve user privacy. The generation and use of authentication credentials in EL PASSO are asynchronous, allowing sign-on operations even if an IdP is temporarily offline. Our solution protects users from being tracked by either RPs or IdPs, and allows to disclose only the minimum user information required to sign on. While providing strong privacy protection, EL PASSO can also hold misbehaving users accountable in cooperation with law enforcement authorities. We believe that this property opens the perspective of using our system in a wide range of use cases where the use of anonymous credentials would otherwise be an issue, such as e-democracy or opinion forums. This work opens interesting perspectives for our future work. Notably, we wish to explore a tighter integration between EL PASSO and the W3C WebAuthn standard. We envision that delegating part of the protocol currently implemented in the browser plugin to a trusted device, equivalent to the WebAuthn authenticator, could lead to higher security while keeping the convenience of centralized management of identities. The implementation of such an authenticator could also leverage trusted hardware environments such as Intel SGX or ARM TrustZone.
This work is partially supported by the the National Science Foundation under award CNS-1629922, the Belgian FNRS project DAPOCA (33694591), and Facebook Calibra. The authors would like to thank Dahlia Malkhi and Ben Maurer for feedback on late manuscript.