Keywords

1 Introduction

Attribute-based credential systems, or ABC-systems, allow for strong yet privacy-preserving user authentication. In such a system, users can receive digital certificates (credentials) on pieces of the personal information (attributes) from an issuer. Such personal information may, for instance, include a user’s first name, surname, nationality, or date of birth. A user can now use a credential to prove to a verifier that it possesses certain attributes, without the need to reveal more information than what is absolutely necessary. For instance, a verifier might require that a user has a specific age, e.g., in order to receive an age discount. The user can now selectively reveal only her date of birth to the verifier, while keeping all other identifying information private, in a way that guarantees to the verifier that the revealed date of birth had indeed been certified by the issuer. Even more, certain schemes even allow a user to prove predicates over her attributes, e.g., allowing her to prove that she is older than 65 years, without revealing the precise birth date, thereby further increasing the privacy level.

Attribute-based credential systems have initially been envisioned by Chaum almost 40 years ago [12, 13], and have received significant attention since then, resulting in a variety of different schemes, supporting different functionalities. The most widely known solutions are Microsoft’s UProve [6, 25] and IBM’s Identity Mixer [7, 9, 10]. However, a large body of related work has been carried out over the last decades, including formal frameworks for ABCs [8], schemes allowing users to anonymously delegate parts of their rights to other users [2, 3, 11, 14], issuer-hiding credential schemes allowing user to remain anonymous across multiple issuers [4], ABC systems with distributed issuers [18, 32], ABCs bound to hardware tokens [1], cloud-based ABCs [21, 23], or distance-bounding schemes [5].

Furthermore, ABC systems have been analyzed in the context of various application scenarios, including car rental [7], vehicular ad-hoc networks (VANETs) [17], ticketing systems [22], eHealth [26], or course evaluation in high schools [24, 31].

Outline. The structure of this paper also follows the structure of the workshop held at the IFIP Summer School. In Sect. 2, we will introduce the fundamental concepts and cryptographic background of attribute-based credential systems to give an intuition on how such schemes work. In Sect. 3, we then introduce a demonstration scenario in the educational context, and present results from an initial user study carried out within the CyberSec4Europe project. Then, in Sect. 4, we introduce the OLYMPUS framework for distributed privacy-preserving identity management. We finally conclude in Sect. 5.

2 Concepts and Technologies

In this section, we will first introduce the basic processes and security and privacy properties of an ABC system, and then introduce the cryptographic building blocks from which such schemes can be built, and provide the basic intuition of the construction underlying most such schemes.

Fig. 1.
figure 1

Overview of entities in an ABC system.

Full size image

2.1 Entities and Processes

Figure 1 gives an overview of the different types of entities in an attribute-based credential system. The different processes in such a scheme can be described as follows:

  • Key generation. In a first step, all parties may generate local key material such as digital signature keys or encryption keys, depending on their role in the system. In most existing instantiations of ABC systems, in particular verifiers do not have a need for cryptographic keys.

  • Issuance. In the issuance phase, users may request certificates on personal attributes. Depending on the specific scenario, the issuer may certify arbitrary, self-claimed attributes, or perform rigorous validations, e.g., requiring in-person checks at an authority. After having agreed on the attributes to be certified, the user and the issuer engage in a potentially interactive protocol, at the end of which the user obtains a credential.

  • Presentation. In order to authenticate towards a service provider (also known as relying party or verifier), the user and the service provider agree on a so-called presentation policy, which, among others, defines the issuer accepted by the service provider, as well as the attributes to be revealed. The user then derives a presentation-token from her credential which she sends to the service provider, who may now decide to accept or reject the user’s presentation.

While these processes exist in any ABC system, also the following steps are available in many schemes found in the literature:

  • Inspection. In order to prevent abuse of anonymous authentication, a predefined party, known as inspector, may open presentation tokens, thereby revoking the user’s anonymity. The inspector can then compute a cryptographic proof that a given presentation token was issued by a specific user. The rules under which the inspector may be contacted by a service provider need to be agreed upfront with the user.

  • Revocation. Upon abuse, loss, or theft of a credential, different entities in the system may request revocation of a given credential, in which case any future attempt to authenticate using the given credential will let the service provider reject the presentation token.

Furthermore, additional processes and features can be found in the literature, including, e.g., advanced issuance, where attributes can be carried over from one credential to another without the issuer learning anything about the attribute, except for the fact that it was already including in a previous credential belonging to the same user.

2.2 Security and Privacy Goals

In the following, we provide informal descriptions of the security goals that need to be achieved by an ABC system. For formal definitions, we refer to the original literature, e.g., Camenisch et al. [8].

  • Correctness. This property requires that the ABC system functions as intended. That is, if all parties behave honestly during the key generation and issuance phases, a user will always be able to derive a presentation token for a given presentation policy, which will be accepted by the service provider.

  • Unforgeability. Intuitively, this property requires that no user is able to derive a valid presentation token for a given presentation policy, unless she has previously obtained a credential satisfying the presentation policy from the issuer. A bit more formally, we assume that an adversary may request arbitrary credentials on attributes of his choice, and also request arbitrary presentation tokens from other users, e.g., by taking the role of a corrupted service provider. Eventually, the adversary outputs a presentation token for a presentation policy of his choice. We now say that an ABC scheme is unforgeable, if the adversary is unable to generate a valid presentation token, if none of the obtained credentials satisfies the policy. Note that this notion of unforgeability implicitly also covers replay attacks.

    In the case that the ABC system supports revocation, the adversary may decide which credentials to revoke, and also succeeds with a forgery if he only knows revoked credentials satisfying the given presentation policy.

  • Privacy. Privacy in an ABC system covers multiple flavours. Firstly, privacy guarantees that the service provider does not gain any information about undisclosed attributes. Secondly, it requires that even if the service provider and the issuer collude or are controlled by the same entity, they will not be able to re-identify the user, i.e., it is infeasible to link issuance and presentation sessions, except by the information explicitly disclosed during these phases. Finally, privacy guarantees unlinkability of different presentation sessions by the same user. That is, a service provider cannot distinguish two presentation tokens from the same user from two presentation tokens computed by different users, as long as the attributes revealed during presentation are the same for these two users.

    Note that this latter property is not available in all ABC systems such as, e.g., UProve [6, 25], where presentations of the same credentials can be linked and thus privacy is only guaranteed if credentials are only used once.

Besides these mandatory requirements, many ABC systems also give additional security guarantees. For instance in the case of inspection, non-frameability guarantees that no set of colluding users, issuers, and inspectors, are able to generate a presentation token which, when opened by the inspector, will link to a certain user outside this set. However, a detailed description of these advanced properties is beyond the scope of this workshop summary.

2.3 Cryptographic Building Blocks

In the following we briefly describe the two central cryptographic primitives that are typically being used when constructing ABC systems, and give some intuition how such systems are often constructed.

  • Digital signatures. A digital signature scheme [20] is a cryptographic mechanism for ensuring the integrity and authenticity of a message. To do so, a signer generates runs a key generation algorithm, obtaining a secret and a public key. Using the secret key, the signer can now compute signatures on arbitrary messages, which can then be validated by a verifier using the signer’s public key.

    The unforgeability property of a signature scheme ensures that no adversary, having seen arbitrarily many signatures on messages of his choice, may come up with a valid signature on a previously unsigned message. Sometimes, a stronger notion of unforgeability is needed, requiring that the adversary cannot generate generate fresh signatures on previously signed messages either.

  • Zero-knowledge proofs of knowledge. A zero-knowledge proof of knowledge [11, 16, 19, 27] is a cryptographic protocol which allows a prover to convince a verifier that she knows a secret piece of information, without revealing anything more than what is already revealed by the statement itself. For instance, the prover may prove that she knows x such that \(y=g^x\) in some cyclic group where the discrete logarithm problem is hard, without revealing any information about x. In the context of ABC systems, we usually consider non-interactive zero-knowledge proofs, where the prover locally computes a proof, and sends it to the verifier, without the need for additional communication rounds.

The intuition behind many ABC systems, including, e.g., [4, 7, 9, 10], is now as follows. In the key generation phase, the issuer generates a key pair for a digital signature scheme. Upon issuance, the user and the issuer agree on a set of attributes \((a_1,\dots ,a_n)\), and the issuer computes a digital signature \(\sigma \) on \((a_1,\dots ,a_n)\). When computing a presentation token which discloses attributes \((a_i)_{i\in D}\), the user derives a zero-knowledge proof of knowledge \(\pi \), proving that she knows a digital signature \(\sigma \) on \((a_1,\dots ,a_n)\), while keeping \(\sigma \) and \((a_i)_{i\notin D}\) private. The service provider then simply checks the validity of the zero-knowledge proof.

To add inspection, the inspector computes a key pair for a public key encryption scheme. Upon issuance, a unique user identifier is embedded as an additional attribute \(a_{n+1}\), and the presentation token is enhanced as follows: the user computes a ciphertext c, and then generates a proof \(\pi \) showing that the user knows a signature \(\sigma \) on \((a_1,\dots ,a_n,a_{n+1})\), such that \(a_{n+1}\) is also contained in c; again, all information except for \((a_i)_{i\in D}\) are kept private.

Similarly, for revocation, on possibility is to embed a revocation handle as attribute \(a_{n+2}\), and let the revocation authority publish a list of revoked attributes. The user can then extend the proof \(\pi \) to additionally show that the revocation handle embedded in her credential is not contained in the given list. For details on constructions, we refer to the original literature.

3 Demonstration Case and Piloting Results

In this section, we will now introduce the concrete use case which is currently under ongoing development within the H2020 CyberSec4Europe projectFootnote 1, and present feedback from an initial user study which. While we only give a high-level summary here, we refer to the full reports for more details [28,29,30].

3.1 Demonstrator Background and Specification

In the early 2010s, a number of forged university degrees among civil servants was identified in Greece [15], where companies sold “degrees” on the Internet without requiring the buyer to do anything more than pay a fee. One way to combat this fraud could be the use of digital university certificates, which provide formal and tamper-proof proof of the courses taken and degrees obtained by a student. Motivated by the aforementioned incidents, the aim of this demonstrator within the H2020 CyberSec4Europe project is therefore to develop a platform that allows attribute-based credentials to be obtained from the university when passing an exam or obtaining a degree. These credentials can then be used in various scenarios, some of which are being developed as demonstrators within the project.

For example, when applicants apply for a PhD position at a university, they need to prove that they have certain degrees (e.g. a Bachelor’s or Master’s degree in a relevant field) and have taken certain courses to meet the formal requirements. To ensure the impartiality of the process at later stages, applicants may only want to prove that they meet the requirements, but not disclose any other sensitive information. For example, to avoid discrimination on the basis of age or gender, the applicant may wish to disclose their degree but not their full name, date of birth or the date on which the degree was issued; similarly, other forms of discrimination can be avoided by, for example, concealing the university that awarded the degree. Similar needs may arise when applying for a job where certain academic requirements must be met. Again, applicants may wish to withhold certain information, at least during the initial formal assessment of suitability, and only disclose it if invited. This also reduces the risk for the employer, as it never collects sensitive information about unsuccessful applicants, which could then be shared in the event of a data breach. Finally, anonymous credentials can also be useful, e.g., to prove to a public authority that courses have been taken with a sufficient number of ECTS credits to receive certain types of study allowance. However, again, it is not necessary to disclose the exact courses, grades, or number of ECTS credits taken.

3.2 The CyberSec4Europe Demonstrator

On a high level, the architecture chosen for the CyberSec4Europe demonstrator follows a natural approach, as can be seen in Fig. 2. The university serves as the identity provider, and employs all components necessary for issuing credentials to a user, who locally stores the received credentials. The Degree Verification System, as part of the job application portal, will later verify all presentation tokens received from a user during an application process. The inspector has currently not been implemented yet within our demonstrator, but will be located in a separate entity, which may or may not be controlled by the issuer.

Fig. 2.
figure 2

High-level overview of the CyberSec4Europe architecture.

Full size image

On the user side, a mobile app was implemented, which allows the user to obtain and manage her credentials, and which can be used to derive presentation tokens when revealing sensitive information to a service provider. Some impressions of this application are given in Fig. 3.

Fig. 3.
figure 3

Impressions of the graphical user interface.

Full size image

3.3 Evaluation Phase

In a first piloting round, the developed pilot was tested with 42 participants with different backgrounds (i.e., BSc and MSc candidates) to give feedback regarding usability, perceived privacy, etc. The participants had mainly computer science related backgrounds, however, without a special focus on cyber security. Future versions of the demonstrator case will also seek for feedback from participants with other backgrounds. About 67% of the participants were male and 33% were female. The age ranged from 22 years to 35 years, with an average of 28 years.

After an introduction to the technology and the demonstrator scenario, the participants were requested to perform a variety of tasks, such as obtaining digital credentials, and applying for a PhD position at the university. Subsequently, the participants were asked to answer a questionnaire which was divided into three main blocks:

  • The first set of questions aimed to understand whether the overall setup of the demonstrator was easy to understand, and whether the tasks where clearly communicated and explained to the students. Furthermore, we aimed at finding out whether from an efficiency and usability point of view, the developed solutions were acceptable.

  • The second set of questions aimed at understanding whether participants understood the privacy guarantees of the developed solution. Furthermore, we tried to find out whether participants are willing to trust such solutions, and whether they understand the added value of the technology for the specific use case, but also in general.

  • Finally, we asked whether it was clearly understood which attributes were actually revealed to the job application portal, and whether participants see the potential benefit in increasing compliance of service providers using privacy-enhancing identity management systems, in order to comply with legal regulations such as the GDPR.

On a high level, the feedback received from participants was positive, however showing slight biases, e.g., depending on the participants’ background and age, which will be further addressed in the next revision of the demonstrator case. For detailed evaluation result, we refer to Sforzin and Bobba [30].

4 The OLYMPUS Framework

In this section, we give an overview on the identity management solution developed in the H2020 OLYMPUS projectFootnote 2, and how it is applied to the use case that we are reviewing. This solution aims to offer advanced Single Sign (SSO) capabilities with special attention to privacy aspects. Concretely, the main focus is addressing the issues that traditional SSO solutions have in that respect, that mostly are caused by the fully trusted Identity Provider (IdP) that becomes a single point of failure:

  • A compromised (or malicious) IdP can impersonate users, gaining full access to all their accounts and personal data. Also, the user’s login credentials are jeopardized.

  • A compromised (or malicious) IdP can forge identities, effectively bypassing access control mechanisms of service providers that trust the IdP for authentication.

  • The IdP can track user behaviour, learning about which services the user interacts with and when they do it.

To tackle the root of the problem, the OLYMPUS identity management system distributes the task of the IdP among several partial identity providers. As the collaboration of all of them is necessary for performing their role, compromising one (or even all but one) identity provider is not enough to gain control over the system and carry out the aforementioned attacks. Apart from this, novel cryptographic mechanisms are applied to further mitigate the security risks and to boost user privacy and their control over their identity. As general and different scenarios as possible: minimizing hardware requirements, two complementary approaches, compatible (as much as possible) with standards and traditional technologies. Also, user-friendly (as it is a common issue of cryptographic approaches).

  • Minimizing the requirements on user hardware, offering user-friendly authentication using passwords without requiring trusted hardware or software.

  • A novel system compatible with traditional technologies that respects users’ privacy while remaining user-friendly is obtained

The OLYMPUS solution is completely open-source, and can be found in the project’s public repositoryFootnote 3. There, you can find all the necessary code to deploy your own identity providers, as well as the library code for clients and verifiers. The project’s documentation is linked within the repository, but you can also start to get used to the code base and its concepts through a guided use case demonstration available in a separate repositoryFootnote 4.

4.1 OLYMPUS Architecture and Roles

The ecosystem of the OLYMPUS identity management system (overview in Fig. 4, more details in [32]) involves three main participants: the virtual Identity Provider (vIdP), the user client and the relying party (RP).

Fig. 4.
figure 4

Simplified version of the OLYMPUS architecture.

Full size image

  • Virtual IdP: It is a set of entities (partial IdPs) that collaborate to perform the role of identity provider. Each partial IdP has three modules for the main functionalities:

    • Distributed authentication: account management and user login through password verification (and potentially multi-factor authentication). It is also a key component in the enrolment process, in which attributes from trusted external attribute providers are linked to the account.

    • Distributed credential module: Generates credential shares for the distributed p-ABC scheme. Each share is generated independently by each partial IdP (i.e., no communication or explicit collaboration is needed during the process).

    • Distributed token module: Generates token shares (RSA-like signature shares), which are part of the OLYMPUS “online” approach, leveraging PESTO.

  • User client: Provides common identity functionalities (registration, authentication, managing attributes...), abstracting from the distributed nature of the IdP. Apart from application logic and flows, it is in charge of cryptographic operations (like combination of signature shares) and secure management of credentials.

  • Relying party: Accepts OLYMPUS tokens (PESTO or p-ABC) for user authentication in order to perform attribute-based access control. The relying party will define and communicate policies that must be fulfilled for granting access (e.g., being over 18 or revealing the user’s name).

4.2 Application to the Use Case

The OLYMPUS virtual IdP is a great asset for ensuring privacy preservation for end users in the university use case. In particular, the p-ABC approach can be used to replace the Idemix [7] credentials used in the first-phase pilot, taking advantage of the improvements of OLYMPUS as an identity management system. More concretely, the p-ABC used in OLYMPUS is based on Pointcheval-Sanders multi-signatures (PS-MS), which are more efficient than the Camenisch-Lysyanskaya (CL) signatures used in Idemix. Additionally, PS-MS allow distributed issuance and the setup phase for the cryptography can be done independently by each partial identity provider. With the distribution of the IdP, we gain security against impersonation and forgery attacks. What is more, partial IdPs can be controlled by different legal entities, which leads to more beneficial conditions in terms of privacy and data control from the viewpoint of regulations like GDPR. However, it is true that deployment and management of the group of IdPs becomes more complex, especially in the case where multiple legal entities are involved, as agreements and contracts must be reached. Apart from the direct benefits of using the distributed scheme, the OLYMPUS infrastructure brings other technical advantages. First, it offers user-friendly account management and authentication, giving users familiar options like passwords and two-factor authentication. Also, the implementation is being integrated with W3C Verifiable Credentials specification, an emerging standard for representing digital credential, which encourages interoperability and adoption. However, Idemix has some functionalities that can be useful depending on the use case and are not supported by the current OLYMPUS implementation.

  • Blind issuance, where the issuer does not learn user attributes but only commitments over them (blindly signs them).

  • Other proof types, like (non)-membership.

  • Credential revocation and inspection

Nevertheless, following a modular approach these functionalities are also technically possible (some theoretical work has already been done in this direction) using the OLYMPUS tools.

5 Conclusion and Future Work

In this workshop, we presented the conceptual foundations of privacy-preserving identity management solutions. We then presented a concrete application scenario in the educational domain which is currently under development within the H2020 CyberSec4Europe project. We presented first evaluation results, and ongoing developments based on the results of the H2020 OLYMPUS project, which can achieve additional security and privacy guarantees compared to the previous iteration.

Using the synergies of these two projects not only allows us to enhance the demonstration case within CyberSec4Europe, but also improves and evolves the OLYMPUS identity management system with new capabilities. First, we aim to establish a trusted public information framework for IdPs, users and relying parties based on Distributed Ledger Technologies (first approximation can be found in [33]). In addition, we are working on adding new functionalities to the framework, enabling fine-grained credential revocation and adding support for credential inspection.