Franz-Stefan Preiss

A card requirements language enabling privacy-preserving access control

We address the problem of privacy-preserving access control in distributed systems. Users commonly reveal more personal data than strictly necessary to be granted access to online resources, even though existing technologies, such as anonymous credential systems, offer functionalities that would allow for privacy-friendly authorization. An important reason for this lack of technology adoption is, as we believe, the absence of a suitable authorization language offering adequate expressiveness to address the privacy-friendly functionalities. To overcome this problem, we propose an authorization language that allows for expressing access control requirements in a privacy-preserving way. Our language is independent from concrete technology, thus it allows for specifying requirements regardless of implementation details while it is also applicable for technologies designed without privacy considerations. We see our proposal as an important step towards making access control systems privacy-preserving.

Concepts and Languages for Privacy-Preserving Attribute-Based Authentication

Existing cryptographic realizations of privacy-friendly authentication mechanisms such as anonymous credentials, minimal disclosure tokens, selfblindable credentials, and group signatures vary largely in the features they offer and in how these features are realized. Some features such as revocation or de-anonymization even require the combination of several cryptographic protocols. These differences and the complexity of the cryptographic protocols hinder the deployment of these mechanisms for practical applications and also make it almost impossible to switch the underlying cryptographic algorithms once the application has been designed. In this paper, we aim to overcome this issue and simplify both the design and deployment of privacy-friendly authentication mechanisms. We define and unify the concepts and features of privacy-preserving attribute-based credentials (Privacy-ABCs) and provide a language framework in XML schema. Our language framework enables application developers to use Privacy-ABCs with all their features without having to consider the specifics of the underlying cryptographic algorithms—similar to as they do today for digital signatures, where they do not need to worry about the particulars of the RSA and DSA algorithms either.

Downstream Usage Control

Whereas access control describes the conditions that have to be fulfilled before data is released, usage control describes how the data has to be treated after it is released. Usage control can be applied to digital rights management, where the data are usually copyright-protected media, as well as in privacy, in which case the data are privacy-sensitive personal information. An important aspect of usage control for privacy, especially in light of the current trend towards composed web services (so-called mash-ups), is downstream usage, i.e., with whom and under which usage control restrictions data can be shared. In this work, we present a two-sided XML-based policy language: on the one hand, it allows users to express in their preferences in a fine-grained way the exact paths that their data is allowed to follow, and the usage restrictions that apply at each hop in the path. On the other hand, it allows data consumers to express in their policies how they intend to treat the data, with whom they intend to share it, and how the downstream consumers intend to treat the data.

Concepts and languages for privacy-preserving attribute-based authentication

Existing cryptographic realizations of privacy-friendly authentication mechanisms such as anonymous credentials, minimal disclosure tokens, self-blindable credentials, and group signatures vary largely in the features they offer and in how these features are realized. Some features such as revocation or de-anonymization even require the combination of several cryptographic protocols. The variety and complexity of the cryptographic protocols hinder the understanding and hence the adoption of these mechanisms in practical applications. They also make it almost impossible to change the underlying cryptographic algorithms once the application has been designed. In this paper, we aim to overcome these issues and simplify both the design and deployment of privacy-friendly authentication mechanisms. We define and unify the concepts and features of privacy-preserving attribute-based credentials (Privacy-ABCs), provide a language framework in XML schema, and present the API of a Privacy-ABC system that supports all the features we describe. Our language framework and API enable application developers to use Privacy-ABCs with all their features without having to consider the specifics of the underlying cryptographic algorithms-similar to as they do today for digital signatures, where they do not need to worry about the particulars of the RSA and DSA algorithms either.

Security and Trust through Electronic Social Network-Based Interactions

The success of a Public Key Infrastructure such as the Web of Trust (WoT) heavily depends on its ability to ensure that public keys are used by their legitimate owners, thereby avoiding malicious impersonations. To guarantee this property, the WoT requires users to physically gather, check each other’s credentials (e.g., ID cards), to sign the trusted keys, and to subsequently monitor their validity over time. This trust establishment and management procedure is rather cumbersome and, as we believe, the main reason for the limited adoption of the WoT. To overcome this problem, we propose a solution that leverages the intrinsic properties of Electronic Social Networks (ESN) to establish and manage trust in the WoT. In particular, we exploit dynamically changing profile and contact information, as well as interactions among users of ESNs to gain and maintain trust in the legitimacy of key ownerships without the disadvantages of the traditional WoT approach. We see our proposal as an effective way to make security and trust solutions available to a broad audience of non-technical users.

Fine-grained disclosure of access policies

In open scenarios, where servers may receive requests to access their services from possibly unknown clients, access control is typically based on the evaluation of (certified or uncertified) properties, that clients can present. Since assuming the client to know a-priori the properties she should present to acquire access is clearly limiting, servers should be able to respond to client requests with information on the access control policies regulating access to the requested services. In this paper, we present a simple, yet flexible and expressive, approach for allowing servers to specify disclosure policies, regulating if and how access control policies on services can be communicated to clients. Our approach allows fine-grain specifications, thus capturing different ways in which policies, and portions thereof, can be communicated. We also define properties that can characterize the client view of the access control policy.

An Architecture for Privacy-ABCs

One of the main objectives of the ABC4Trust project was to define a common, unified architecture for Privacy-ABC systems to allow comparing their respective features and combining them into common platforms. The chapter presents an overview of features and concepts of Privacy-ABCs and introduces the architecture proposed by ABC4Trust, describing the layers and components as well as the highlevel APIs. We also present the language framework of ABC4Trust through an example scenario. Furthermore, this chapter investigates integration of Privacy-ABCs with the existing Identity Management protocols and also analyses the required trust relationships in the ecosystem of Privacy-ABCs.

Matching Privacy Policies and Preferences:Access Control, Obligations, Authorisations, and Downstream Usage

This chapter describes how users’ privacy preferences and services’ privacy policies are matched in order to decide whether personal data can be shared with services. Matching has to take into account data handling, i.e. does services handle collected data in a suitable way according to user expectations, and access control, i.e. do the service that will be granted access to the data comply with user expectations. Whereas access control describes the conditions that have to be fulfilled before data is released, data handling describes how the data has to be treated after it is released. Data handling is specified as obligations that must be fulfilled by the service and authorisations that may be used by the service. An important aspect of authorisation, especially in light of the current trend towards composed web services (so-called mash-ups), is downstream usage, i.e., with whom and under which data handling restrictions data can be shared.

Practical Signing-Right Revocation

One of the key features that must be supported by every modern PKI is an efficient way to determine (at verification) whether the signing key had been revoked. In most solutions, the verifier periodically contacts the certificate authority (CA) to obtain a list of blacklisted, or whitelisted, certificates. In the worst case this has to be done for every signature verification. Besides the computational costs of verification, after revocation all signatures under the revoked key become invalid. In the solution by Boneh et al. at USENIX ’01, the CA holds a share of the private signing key and contributes to the signature generation. After revocation, the CA simply denies its participation in the interactive signing protocol. Thus, the revoked user can no longer generate valid signatures. We extend this solution to also cover privacy, non-trusted setups, and time-stamps. We give a formal definitional framework, and provide elegantly simple, yet provably secure, instantiations from efficient standard building blocks such as digital signatures, commitments, and partially blind signatures. Finally, we propose extensions to our scheme.

Cryptographic Protocols Underlying Privacy-ABCs

In this chapter we present the Cryptographic Engine which provides the cryptographic functionality used in the ABC Engine, such as issuance or presentation of credentials. We first describe the architecture of the Cryptographic Engine, explain the building blocks it uses, and explain how they are bound together. We then describe the cryptographic primitives that the library uses to instantiate those building blocks.