Jan Camenisch

Maria Dubovitskaya

Anja Lehmann

Gregory Neven

Christian Paquin

Franz-Stefan Preiss

Concepts and Languages for Privacy-Preserving Attribute-Based Authentication

Keywords: Authentication, privacy, data-minimization, anonymous credentials, digital credentials

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

More and more transactions in our daily life are performed electronically and the security of these transactions is an important concern. Strong authentication and according authorization based on certified attributes of the requester is paramount for protecting critical information and infrastructures online.

Most existing techniques for transferring trusted user attributes cause privacy issues. In systems where an online identity provider creates access tokens on demand, such as SAML, OpenID, or WS-Federation, the identity provider can impersonate its users and can track a user's moves online. Systems with offline token creation, such as X.509 certificates and some WS-Trust profiles, force the user to reveal more attributes than strictly needed (as otherwise the issuer's signature cannot be verified) and make her online transactions linkable across different websites.

These drawbacks can be overcome with privacy-preserving authentication mechanisms based on advanced cryptographic primitives such as anonymous credentials, minimal disclosure tokens, self-blindable credentials, or group signatures [START_REF] Chaum | Untraceable electronic mail, return addresses, and digital pseudonyms[END_REF][START_REF] Brands | Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy[END_REF][START_REF] Camenisch | An efficient system for non-transferable anonymous credentials with optional anonymity revocation[END_REF][START_REF] Camenisch | Signature schemes and anonymous credentials from bilinear maps[END_REF][START_REF] Belenkiy | Randomizable proofs and delegatable anonymous credentials[END_REF][START_REF] Verheul | Self-Blindable Credential Certificates from the Weil Pairing[END_REF]. In these schemes, users obtain certified credentials for their attributes from trusted issuers and later derive, without further assistance from any issuer, unlinkable tokens that reveal only the required attribute information yet remain verifiable under the issuer's public key. Well-known examples being Brands' scheme [START_REF] Brands | Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy[END_REF] and Camenisch-Lysyanskaya's scheme [START_REF] Camenisch | An efficient system for non-transferable anonymous credentials with optional anonymity revocation[END_REF], which have been implemented in Microsoft's U-Prove [START_REF]Microsoft U-Prove[END_REF] and IBM's Identity Mixer [START_REF]Identity Mixer[END_REF], respectively. Both implementations are freely available and efficient enough for practical use, yet the real-world adoption is slower than one may hope. One possible reason for the slow adoption of privacy-preserving authentication technologies might be that the various schemes described in the literature have a large set of features where similar features are often called differently or are realized with different cryptographic mechanisms. Many of the features such as credential revocation, efficient attribute encoding, or anonymity lifting even require a combination of separate cryptographic protocols. This makes these technologies hard to understand and compare and, most importantly, very difficult to use.

To overcome this, we provide unified definitions of the concepts and features of the different privacy-preserving authentication mechanisms. We will refer to this unification as privacy-preserving attribute-based credentials or Privacy-ABCs. Our definitions abstract away from the concrete cryptographic realizations but are carefully crafted so that they can be instantiated with the different cryptographic protocols-or a combination of them. To enable the use and integration of Privacy-ABCs in authentication and authorization systems, we further present cryptography-agnostic definitions of all concepts as well as a language framework with data formats for, e.g., policies and claims. All languages are specified in XML schema and separate the abstract functionality expected from the underlying cryptographic mechanisms from the opaque containers for the cryptographic data itself. Thus, these languages allow application developers to employ Privacy-ABCs without having to think about their cryptographic realization, similarly to how digital signatures or encryption can be used today. The language described in this paper has been implemented in the ABC4Trust project (www.abc4trust.eu) and will be made available as part of a reference implementation of a Privacy-ABC system which will include a number of cryptographic solutions. The full language description and schema are available as a project deliverable [START_REF] Camenisch | H2.1 -ABC4Trust Architecture for Developers[END_REF].

Related work

Our work builds on the credential-based authentication requirements language (CARL) recently proposed by Camenisch et al. [START_REF] Camenisch | A card requirements language enabling privacy-preserving access control[END_REF]. CARL allows a service provider (verifier) to specify which attributes certified by whom a user needs to present in order to get access. Compared to our work, CARL defines only a small part of a Privacy-ABC system, namely the presentation policy, but does not consider how these attributes are transmitted nor how credentials are issued or revoked. Bichsel et al. [START_REF] Bichsel | A comprehensive framework enabling dataminimizing authentication[END_REF] have extended CARL to cover the transmission of certified attributes. Version 1 of the U-Prove protocols [START_REF]Microsoft U-Prove[END_REF] covers credential issuance and presentation but only supports selective attribute disclosure. It does not consider other features such as attribute predicates, inspection, key binding, (cryptographic) pseudonyms, or revocation.

Privacy-ABCs can be used to realize a privacy-respecting form of attribute-based access control. Traditional attribute-based access control [START_REF] Bonatti | A unified framework for regulating access and information release on the web[END_REF][START_REF]eXtensible Access Control Markup Language (XACML) Version 2[END_REF][START_REF] Wang | A logic-based framework for attribute based access control[END_REF], however, does not see attributes as grouped together in a credential or token. Thus our framework allows one to realize more specific and more precise access control policies. Also, role-based access control [START_REF] Ferraiolo | Role-based access control[END_REF][START_REF] Sandhu | Role-based access control models[END_REF] can be seen as a special case of our attribute-based setting by encoding the user's roles as attributes. Recent work [START_REF] Kirkpatrick | Privacy-preserving enforcement of spatially aware RBAC[END_REF] extended RBAC with privacypreserving authentication for the particular case of role and location attributes.

Bonatti and Samarati [START_REF] Bonatti | A unified framework for regulating access and information release on the web[END_REF] also propose a language for specifying access control rules based on "credentials". The language focuses on credential ownership and does not allow for more advanced requirements such as for example revealing of attributes, signing statements, or inspection. The same is true for the languages proposed by Ardagna et al. [START_REF] Ardagna | A privacy-aware access control system[END_REF] and by Winsborough et al. [START_REF] Winsborough | Automated trust negotiation[END_REF]. However, the latter allows one to impose attribute properties on credentials and its extension by Li et al. [START_REF] Li | Automated trust negotiation using cryptographic credentials[END_REF] supports revealing of attributes. The Auth-SL language [START_REF] Squicciarini | Auth-SL -A system for the specification and enforcement of quality-based authentication policies[END_REF] focuses on multi-factor authentication and enables the policy author to specify restrictions on the properties of the authentication mechanisms themselves, but not on attributes of individual users.

The language by Ardagna et al. [START_REF] Ardagna | Exploiting cryptography for privacy-enhanced access control[END_REF] can also be considered as a predecessor to our language in the sense that it focuses on anonymous credential systems and some of the advanced features. However, it considers only the presentation phase and is less expressive than ours, for instance, it cannot express statements involving attributes from different credentials.

VeryIDX [START_REF] Paci | VeryIDX -A privacy preserving digital identity management system for mobile devices[END_REF] is a system to prevent identity theft by permitting the use of certain identity attributes only in combination with other identity attributes. So-called verification policies specify which attributes have to be presented together. However, these policies are introduced only conceptually without any details on exact expressivity, syntax, or semantics.

Several logic-based and technology-neutral approaches to distributed access control have been proposed [START_REF] Appel | Proof-carrying authentication[END_REF][START_REF] Bowers | Consumable credentials in linear-logic-based access-control systems[END_REF][START_REF] Garg | A linear logic of authorization and knowledge[END_REF][START_REF] Li | Delegation logic: A logic-based approach to distributed authorization[END_REF]. However, none of these have been designed with Privacy-ABCs in mind. In particular, they do not support selective disclosure of attributes, proving predicates over attributes, or attribute inspection. Summarized, our language framework is the first that covers the whole life-cycle of Privacy-ABCs and also the first one unifying the full spectrum of their features.

Concepts and Features

Figure 1 gives an overview of the entities involved in Privacy-ABC systems and the interactions between them. The interactions are named according to their purpose. Depending on the technical realizations, these interactions will be realized differently and might occur multiple times using different protocols (we consider sending a single message also a protocol). These entities are users, issuers, verifiers, inspectors and revocation authorities. Each issuer generates a secret issuance key and publishes the issuer parameters that include the corresponding public verification key. Similarly, each inspector generates a private decryption key and a corresponding public encryption key, and each revocation authority generates and publishes its revocation parameters. We assume that all entities have means to retrieve the public keys of the issuers, revoca- tion authorities, inspectors, and verifiers. Users get issued credentials by issuers via the credential issuance protocol. A credential contains attributes that its issuer vouches for w.r.t. the user. A credential can also specify one or more revocation authorities who are able to revoke the credential if necessary for some reason. To issue a credential that is revocable, the user and/or the issuer might need to interact with the revocation authorize prior or during the issuance protocol. Using her credentials, a user can form a presentation token that contains a subset of the certified attributes, provided that the corresponding credentials have not been revoked. This process might require the user to retrieve information from the revocation authority. Additionally, some of the attributes can be encoded in the presentation token so that they can only be retrieved by an inspector. The user can attach inspection grounds specifying under this condition the inspector should reveal these attributes. Receiving a presentation token from a user, a verifier checks whether the presentation token is valid w.r.t. the relevant issuers' public keys and inspector public keys and the latest revocation information (thus, the verifier will interact with the revocation authority). If the verification succeeds, the verifier will be convinced that the attributes contained in the presentation token are vouched for by the corresponding issuers. Finally, if a presentation token contains attributes that can only be retrieved by an inspector and the inspection grounds are met, the verifier can interact with the inspector to learn these attributes.

Informally, a secure realization of a Privacy-ABC system guarantees that (1) users can only generate a valid presentation token if they were indeed issued the corresponding credentials that have not been revoked, (2) that attributes encoded in the presentation token for an inspector can indeed be retrieved by that inspector, and (3) that the presentation tokens do not reveal any further information about the users other than the attributes contained in them.

We now provide a brief explanation of the main features supported by Privacy-ABCs, with a focus on the ones that were not modeled so far in existing identity frameworks.

Pseudonyms

Each user can generate a secret key. However, unlike traditional public-key authentication schemes, there is no single public key corresponding to the secret key. Rather, the user can generate as many public keys as she wishes. These public keys are called pseudonyms in Privacy-ABCs. Pseudonyms [START_REF] Chaum | Untraceable electronic mail, return addresses, and digital pseudonyms[END_REF][START_REF] Lysyanskaya | Pseudonym systems[END_REF] are cryptographically unlinkable, meaning that given two different pseudonyms, one cannot tell whether they were generated from the same or from different secret keys. By generating a different pseudonym for every verifier, users can thus be known under different unlinkable pseudonyms to different sites, yet use the same secret key to authenticate to all of them.

While it is sufficient for users to generate a single secret key, they can also have multiple secret keys. A secret key can be generated by a piece of trusted hardware (e.g., a smart card) that stores and uses the key in computations (e.g., to generate pseudonyms), but that never reveals the key. The key is thereby bound to the hardware, in the sense that it can only be used in combination with the hardware.

There are situations, however, where the possibility to generate an unlimited number of unlinkable pseudonyms is undesirable. For example, in an online opinion poll, users should not be able to bias the result by entering multiple votes under different pseudonyms. In such situations, the verifier can request a special pseudonym called a scope-exclusive pseudonym, which is unique for the user's secret key and a given scope string [START_REF]Specification of the identity mixer cryptographic library[END_REF]. Scope-exclusive pseudonyms for different scope strings remain unlinkable. By using the URL of the opinion poll as the scope string, for example, the verifier can ensure that each user can only register a single pseudonym to vote.

Credentials and Key Binding

A credential is a certified container of attributes issued by an issuer to a user. Formally, an attribute is described by the attribute type that determines the semantics of the attribute (e.g., first name) and the attribute value that determines its contents (e.g., "John"). By issuing a credential, the issuer vouches for the correctness of the contained attributes with respect to the user. The credential specification lists the attribute types that are encoded in a credential. A credential specification can be created by the issuer, or by an external authority so that multiple issuers can issue credentials according to the same specification. The credential specification must be published and distributed over a trusted channel. How exactly this is done goes beyond the scope of our language framework; the specification could for example be digitally signed by its creator.

Optionally, a credential can be bound to a user's secret key, i.e., it cannot be used without knowing the secret key [START_REF] Lysyanskaya | Pseudonym systems[END_REF]. We call this option key binding. It is somewhat analogous to traditional public-key certificates, where the certificate contains the CA's signature on the user's public key, but unlike traditional public-key certificates, a Privacy-ABC is not bound to a unique public key: it is only bound to a unique secret key. A user can derive as many pseudonyms as she wishes from this secret key and (optionally) show that they were derived from the same secret key that underlies the credential.

Presentation

To authenticate to a verifier, the user first obtains the presentation policy that describes which credentials the user must present and which information from these credentials she must reveal. If the user possesses the necessary credentials, she can derive from these credentials a presentation token that satisfies the presentation policy. The presentation token can be verified using the issuer parameters of all credentials underlying the presentation token.

Presentation tokens derived from Privacy-ABCs only reveal the attributes that were explicitly requested by the presentation policy -all the other attributes contained in the credentials remain hidden. Moreover, presentation tokens are cryptographically unlinkable (meaning no collusion of issuers and verifiers can tell whether two presentation tokens were generated by the same user or by different users) and untraceable (meaning that no such collusion can correlate a presentation token to the issuance of the underlying credentials). Of course, presentation tokens are only as unlinkable as the information they intentionally reveal.

Rather than requesting and revealing full attribute values, presentation policies and tokens can also request and reveal predicates over one or more issued attributes. For example, a token could reveal that the name on the user's credit card matches that on her driver's license, without revealing the name. As another example, a token could reveal that the user's birthdate is before January 1st, 1994, without revealing her exact birthdate.

Issuance

In the simplest setting, an issuer knows all attribute values to be issued and simply embeds them into a credential. Privacy-ABCs also support advanced issuance features where attributes are blindly "carried over" from existing credentials, without the issuer becoming privy to their values. Similarly, the issuer can blindly issue self-claimed attribute values (i.e., not certified by an existing credential), carry over the secret key to which a credential is bound, or assign a uniformly random value to an attribute such that the issuer cannot see it and the user cannot bias it [START_REF] Brands | Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy[END_REF][START_REF] Camenisch | A signature scheme with efficient protocols[END_REF].

Advanced issuance is an interactive protocol between the user and the issuer. In the first move, the issuer provides the user with an issuance policy that consists of a presentation policy specifying which pseudonyms and/or existing credentials the user must present, and of a credential template specifying which attributes or secret keys of the newly issued credential will be generated at random or carried over from credentials or pseudonyms in the presentation policy. In response, the user sends an issuance token containing a presentation token that satisfies the issuance policy. Then the (possibly multi-round) cryptographic issuance protocol ensues, at the end of which the user obtains the new credential.

Inspection

Absolute user anonymity in online services easily leads to abuses such as spam, harassment, or fraud. Privacy-ABCs provide the option to add accountability for misbehaving users through a feature called inspection [START_REF] Chaum | Group signatures[END_REF][START_REF] Camenisch | Practical verifiable encryption and decryption of discrete logarithms[END_REF]. Here, a presentation token contains one or more credential attributes that are encrypted under the public key of a trusted inspector. The verifier can check that the correct attribute values were encrypted, but cannot see their actual values. The inspection grounds describe the circumstances under which the verifier may call upon the inspector to recover the actual attribute values.

The inspector is trusted to collaborate only when the inspection grounds have been met; verifiers cannot change the inspection grounds after receiving a presentation token, as the grounds are cryptographically tied to the token.

The presentation policy specifies which attributes from which credentials have to be encrypted, together with the inspector public keys and inspection grounds under which they have to be encrypted.

Revocation

Credentials may need to be revoked for several reasons: the credential and the related user secrets may have been compromised, the user may have lost her right to carry a credential, or some of her attribute values may have changed. In such cases, credentials need to be revoked globally and we call this issuer-driven revocation. Sometimes credentials may be revoked only for specific contexts. For example, a hooligan may see his digital identity card revoked for accessing sport stadiums, but may still use it for all other purposes. We call this verifier-driven revocation.

Revocation for Privacy-ABCs is cryptographically more complicated than for classical certificates, but many mechanisms with varying efficiency [START_REF] Lapon | Analysis of Revocation Strategies for Anonymous Idemix Credentials[END_REF] exist [START_REF] Camenisch | Dynamic accumulators and application to efficient revocation of anonymous credentials[END_REF][START_REF] Nguyen | Accumulators from bilinear pairings and applications[END_REF][START_REF] Brands | A practical system for globally revoking the unlinkable pseudonyms of unknown users[END_REF][START_REF] Camenisch | An accumulator based on bilinear maps and efficient revocation for anonymous credentials[END_REF][START_REF] Nakanishi | Revocable group signature schemes with constant costs for signing and verifying[END_REF]. Bar a few exceptions, all of them can be used for both issuer-driven and verifierdriven revocation.

We describe revocation in a generic mechanism-agnostic way and consider credentials to be revoked by dedicated revocation authorities. They are separate entities in general, but may be under the control of the issuer or verifier in particular settings. The revocation authority publishes static revocation authority parameters and periodically publishes the most recent revocation information. When creating presentation tokens, users prove that their credentials have not been revoked, possibly using non-revocation evidence that they fetch and update from the revocation authority. The revocation authority to be used is specified in the issuer parameters for issuer-driven revocation and in the presentation policy for verifier-driven revocation. When a credential is subject to issuer-driven revocation, a presentation token related to this credential must always contain a proof that the presented credential has not been revoked. Issuer-driven revocation is performed based on the revocation handle, which is a dedicated unique attribute embedded in a credential. Verifier-driven revocation can be performed based on any combination of attribute values, possibly even from different credentials. This allows the revocation authority for example to exclude certain combinations of first names and last names to be used in a presentation token.

Cryptographic Realization

Among the most prominent instantiations of Privacy-ABC systems are IBM's Identity Mixer [START_REF]Identity Mixer[END_REF] and Microsoft's U-Prove [START_REF]Microsoft U-Prove[END_REF]. Both systems currently support only a subset of the features presented here, but will be extended to support the full feature set as part of the ABC4Trust project. Here, we sketch how the different features can be realized cryptographically and give pointers to relevant related literature; a full security analysis of the combined system is beyond the scope of this paper.

At the core of a Privacy-ABC system is a signature scheme with efficient protocols to prove possession of signatures. Identity Mixer and U-Prove build on the Camenisch-Lysyanskaya [START_REF] Camenisch | A signature scheme with efficient protocols[END_REF] and the Brands [START_REF] Brands | Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy[END_REF] signature schemes, respectively, but also other schemes exist [START_REF] Camenisch | Signature schemes and anonymous credentials from bilinear maps[END_REF][START_REF] Au | Constant-size dynamic k-TAA[END_REF]. An issued credential is a signature (or, for single-show schemes such as [START_REF] Brands | Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy[END_REF], a batch of renewable signatures) under such a scheme on the user's attributes. Some schemes inherently support key binding [START_REF] Camenisch | A signature scheme with efficient protocols[END_REF][START_REF] Camenisch | Signature schemes and anonymous credentials from bilinear maps[END_REF][START_REF] Au | Constant-size dynamic k-TAA[END_REF], others can be extended by using a randomly chosen attribute as secret key [START_REF] Brands | Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy[END_REF].

Ordinary pseudonyms are cryptographic commitments [START_REF] Pedersen | Non-interactive and information-theoretic secure verifiable secret sharing[END_REF][START_REF] Damgård | A statistically-hiding integer commitment scheme based on groups with hidden order[END_REF] to the secret key; scope-exclusive pseudonyms can be realized as the output of a verifiable random function [START_REF] Dodis | A verifiable random function with short proofs and keys[END_REF][START_REF] Camenisch | Balancing accountability and privacy using e-cash[END_REF] applied to the secret key as seed and the scope string as input. Inspection can be obtained through verifiable encryption [START_REF] Camenisch | Practical verifiable encryption and decryption of discrete logarithms[END_REF] of the inspectable attributes. Revocation of Privacy-ABCs can be done through signed revocation lists [START_REF] Nakanishi | Revocable group signature schemes with constant costs for signing and verifying[END_REF], through dynamic accumulators [START_REF] Camenisch | Dynamic accumulators and application to efficient revocation of anonymous credentials[END_REF][START_REF] Nguyen | Accumulators from bilinear pairings and applications[END_REF][START_REF] Camenisch | An accumulator based on bilinear maps and efficient revocation for anonymous credentials[END_REF], or through efficient updates of short-lived credentials [START_REF] Camenisch | Solving revocation with efficient update of anonymous credentials[END_REF].

The glue binding all primitives together in a presentation token is provided by generalized zero-knowledge proofs of knowledge of discrete logarithms [START_REF] Schnorr | Efficient signature generation by smart cards[END_REF][START_REF] Camenisch | On the portability of generalized Schnorr proofs[END_REF] made noninteractive through the Fiat-Shamir transform [START_REF] Fiat | How to prove yourself: Practical solutions to identification and signature problems[END_REF]. These proofs are also used for equality predicates over attributes; inequality predicates are proved with range proofs [START_REF] Boudot | Efficient proofs that a committed number lies in an interval[END_REF][START_REF] Camenisch | Efficient protocols for set membership and range proofs[END_REF].

Language Framework

Given the multitude of distributed entities involved in a full-fledged Privacy-ABC system, the communication formats that are used between these entities must be specified and standardized.

None of the existing format standards for identity management protocols such as SAML, WS-Trust, or OpenID support all Privacy-ABCs' features. Although most of them can be extended to support a subset of these features, we define for the sake of simplicity and completeness a dedicated language framework which addresses all unique Privacy-ABC features. Our languages can be integrated into existing identity management systems.

In this section we introduce our framework covering the full life-cycle of Privacy-ABCs, including setup, issuance, presentation, revocation, and inspection. As the main purpose of our data artifacts is to be processed and generated by automated policy and credential handling mechanisms, we define all artifacts in XML schema notation, although one could also create a profile using a different encoding such as Abstract Syntax Notation One (ASN.1) [37] or JavaScript Object Notation (JSON) [START_REF] Crockford | The application/json media type for JavaScript Object Notation (JSON)[END_REF].

The XML artifacts formally describe and orchestrate the underlying cryptographic mechanisms and provide opaque containers for carrying the cryptographic data. Whenever appropriate, our formats also support user-friendly textual names or descriptions which allow to show a descriptive version of the XML artifacts to a user and to involve her in the issuance or presentation process if necessary.

For didactic purposes we describe the different artifacts realizing the concepts from Section 3 by means of examples. For the sake of space and readability, these examples do not illustrate all features described in the previous section; we refer the reader to [START_REF] Camenisch | H2.1 -ABC4Trust Architecture for Developers[END_REF] for the full specification. In what follows, we explicitly distinguish between user attributes (as contained in a credential) and XML attributes (as defined by XML schema) whenever they could be confused.

Credential Specification

Recall that the credential specification describes the common structure and possible features of credentials. For example, assume the Republic of Utopia issues electronic identity cards to its citizens containing their full name, state, and date of birth. Utopia may issue Privacy-ABCs according to the credential specification shown in Figure 2. The XML attribute KeyBinding indicates whether credentials adhering to this specification must be bound to a secret key. The XML attribute Revocable being set to "true" indicates that the credentials will be subject to issuer-driven revocation and hence have a built-in revocation handle. The assigned revocation authority is specified in the issuer parameters.

To encode user attribute values in a Privacy-ABC, they must be mapped to integers of a limited length. The maximal length depends on the security parameter (basically, it is the bit length of exponents in the group) and is indicated by the MaxLength XML attribute (Line 3), here 32 bytes. In our example, electronic identity cards contain a person's full name, state, and date of birth. The XML attributes Type, DataType, and Encoding respectively contain the unique identifier for the user attribute type, for the data type, and for the encoding algorithm that specifies how the value is to be mapped to an integer of the correct size (Lines 4,7,8). Attributes that may have values longer than MaxLength have to be hashed, as is done here for the name using SHA-256. The specification can also define human-readable names for the user attributes in different languages (Line 5).

Issuer and Revocation Parameters

The government of Utopia, that acts as issuer and revocation authority for the identity cards, generates an issuance key pair and publishes the issuer parameters, and generates and publishes the revocation authority parameters, which are illustrated in Figure 3.

The ParametersUID element assigns unique identifiers for the issuer and revocation authority parameters. The issuer parameters additionally specify the chosen cryptographic Privacy-ABC and hash algorithm, the credential specification that credentials issued under these issuer parameters will follow, and the parameters identifier of the revocation authority that will manage the issuer-driven revocation. The SystemParameters, CryptoParams, and KeyBindingInfo contain cryptographic algorithm-specific information about the public key. The revocation authority parameters can be used for both issuer-and verifier-driven revocation. They specify a unique identifier for the parameters, the cryptographic revocation mechanisms, and references to the network endpoints where the most recent revocation information and non-revocation evidence can be fetched.

Presentation Policy with Basic Features

Assume that a user already possesses an identity card from the Republic of Utopia issued according to the credential specification depicted in Figure 2. Further, assume that all residents of Utopia can sign up for one free library card using an online issuance service. To get a library card the applicant must present her valid identity card and reveal (only) the state attribute certified by the card. This results in the presentation policy depicted in Figure 4. We now go through the preceding presentation policy and describe how the different features of Privacy-ABCs can be realized with our language. We first focus on the basic features and describe extended concepts such as inspection and revocation in our second example.

Signing Messages. A presentation token can optionally sign a message. The message to be signed is specified in the policy (Fig. 4, Lines 2-4). It can include a nonce, any application-specific message, and a human-readable name and/or description of the policy. The nonce will be used to prevent replay attacks, i.e. to ensure freshness of the presentation token, and for cryptographic evidence generation. Thus, when making use of the nonce, the presentation policy is not static anymore, but needs to be completed with a fresh nonce element for every request.

Pseudonyms. The optional Pseudonym element (Fig. 4, Line 5) indicates that the presentation token must contain a pseudonym. A pseudonym can be presented by itself or in relation with a credential if key binding is used (which we discuss later).

The associated XML attribute Exclusive indicates that a scope-exclusive pseudonym must be created, with the scope string given by the XML attribute Scope. This ensures that each user can create only a single pseudonym satisfying this policy, so that the registration service can prevent the same user from obtaining multiple library cards. Setting Exclusive to "false" would allow an ordinary pseudonym to be presented. The Pseudonym element has an optional boolean XML attribute Established, not illustrated in the example, which, when set to "true", requires the user to re-authenticate under a previously established pseudonym. The presentation policy can request multiple pseudonyms, e.g., to verify that different pseudonyms actually belong to the same user.

Credentials and Selective Disclosure. For each credential that the user is requested to present, the policy contains a Credential element (Fig. 4, Lines 6-14), which describes the credential to present in detail. In particular, disjunctive lists of the accepted credential specifications and issuer parameters can be specified via CredentialSpecAlternatives and IssuerAlternatives elements, respectively (Fig. 4, Lines 7-9 and 10-12). The credential element also indicates all attributes that must be disclosed by the user via DisclosedAttribute elements (Fig. 4, Line 13). The XML attribute Alias assigns the credential an alias so that it can be referred to from other places in the policy, e.g., from the attribute predicates. Key Binding. If present, the SameKeyBindingAs attribute of a Credential or Pseudonym element (Fig. 4, Line 6), contains an alias referring either to another Pseudonym element within this policy, or to a Credential element for a credential with key binding. This indicates that the current pseudonym or credential and the referred pseudonym or credential have to be bound to the same key. In our preceding example, the policy requests that the identity card and the presented pseudonym must belong to the same secret key.

Issuance Policy. To support the advanced features described in Section 3, we propose a dedicated issuance policy. A library card contains the applicant's name and is bound to the same secret key as the identity card. So the identity card must not only be presented, but also used as a source to carry over the name and the secret key to the library card, and the library should learn neither of them during the issuance process. Altogether, to issue library cards the state library creates the issuance policy depicted in Figure 5. It contains the presentation policy from Figure 4 and the credential template that is described in detail below. Credential Template. A credential template describes the relation of the new credential to the existing credentials that were requested in the presentation policy. The credential template (Fig. 5, Lines 3-11) must first state the unique identifier of the credential specification and issuer parameters of the newly issued credential. The optional XML attribute SameKeyBindingAs further specifies that the new credential will be bound to the same secret key as a credential or pseudonym in the presentation policy, in this case the identity card.

Within the UnknownAttributes element (Fig. 5, Lines 6-10) it is specified which user attributes of the new credential will be carried over from existing credentials in the presentation token. The SourceCredentialInfo element (Fig. 5, Line 8) indicates the credential and the user attribute of which the value will be carried over.

Although this is not illustrated in our example, an attribute value can also be specified to be chosen jointly at random by the issuer and the user. This is achieved by setting the optional XML attribute JointlyRandom to "true".

Presentation and Issuance Token.

A presentation token consists of the presentation token description, containing the mechanism-agnostic description of the revealed information, and the cryptographic evidence, containing opaque values from the specific cryptography that "implements" the token description. The presentation token description roughly uses the same syntax as a presentation policy. An issuance token is a special presentation token that satisfies the stated presentation policy, but that contains additional cryptographic information required by the credential template.

The main difference to the presentation and issuance policy is that in the returned token a Pseudonym (if requested in the policy) now also contains a PseudonymValue (Fig. 6, Line 6). Similarly, the DisclosedAttribute elements (Fig. 6, Lines 10-12) in a token now also contain the actual user attribute values. Finally, all data from the cryptographic implementation of the presentation token and the advanced issuance features are grouped together in the CryptoEvidence element (Fig. 6, Line 17). This data includes, e.g., proof that the contained identity card is not revoked by the issuer and that it is bound bound to the same secret key as the pseudonym.

Presentation Policy with Extended Features

Assume that the state library has a privacy-friendly online interface for borrowing digital and paper books. Books can be browsed and borrowed anonymously using the digital library cards based on Privacy-ABCs. Paper books can be delivered in anonymous numbered mailboxes at the post office. However, when books are returned late or damaged, the library must be able to identify the reader to impose an appropriate fine. Repeated negligence may even lead to exclusion from borrowing further paper books while borrowing digital books remains possible.

Moreover, assume that the library offers special conditions for young readers that can be used by anyone below the age of twenty-six years. As library cards do not contain a date of birth, a user must prove to be below that age by combining her library card with her identity card. Altogether, for borrowing books under the "young-reader"-conditions, users have to satisfy the presentation policy depicted in Figure 7.

A presentation policy that is used for plain presentation (i.e., not within an issuance policy) can consist of multiple policy alternatives, each wrapped in a separate Presen-tationPolicy element (Fig. 7, Lines 2-34). The returned presentation token must satisfy (at least) one of the specified policies.

The example presentation policy requires two Credential elements, for the library and for the identity card, which must belong to the same secret key as indicated by the XML attribute SameKeyBindingAs.

Attribute Predicates. No user attributes of the identity card have to be revealed, but the AttributePredicate element (Fig. 7, Lines 30-33) specifies that the date of birth must be after July 16th, 1986, i.e., that the reader is younger than twenty-six. Supported predicate functions include equality, inequality, greater-than and less-than tests for most basic data types, as well as membership of a list of values. The arguments of the predicate function may be credential attributes (referred to by the credential alias and the attribute type) or constant values. See [START_REF] Camenisch | H2.1 -ABC4Trust Architecture for Developers[END_REF] for an exhaustive list of supported predicates and data types and note that an attribute's encoding as defined in the credential specification has implications on which predicates can be used for it and whether it is inspectable [START_REF] Camenisch | H2.1 -ABC4Trust Architecture for Developers[END_REF]Sec. 4

.2.1].

Inspection. To be able to nevertheless reveal the name of an anonymous borrower and to impose a fine when a book is returned late or damaged, the library can make use of inspection. The DisclosedAttribute element for the user attribute "...:name" contains InspectorPublicKeyUID and InspectionGrounds child elements, indicating that the attribute value must not be disclosed to the verifier, but to the specified inspector with the specified inspection grounds. The former child element specifies the inspector's public key under which the value must be encrypted, in this case belonging to a designated arbiter within the library. The latter element specifies the circumstances under which the attribute value may be revealed by the arbiter. Our language also provides a data artifact for inspection public keys, which we omit here for space reasons.

Issuer-Driven Revocation. When the presentation policy requests a credential that is subject to issuer-driven revocation (as defined in the credential specification), the cre-dential must be proved to be valid with respect to the most recent revocation information. However, a policy can also require the use of a particular version of the revocation information. In the latter case, the element IssuerParametersUID has an extra XML attribute RevocationInformationUID specifying the identifier of the specific revocation information. The specification of the referenced RevocationInformation is given in [START_REF] Camenisch | H2.1 -ABC4Trust Architecture for Developers[END_REF]. Presentation tokens can accordingly state the validity of credentials w.r.t. a particular version by using a RevocationInformationUID XML element in the corresponding Credential element.

Verifier-Driven Revocation. If customers return borrowed books late or damaged, they are excluded from borrowing further paper books, but they are still allowed to use the library's online services. In our example, this is handled by a VerifierDrivenRevocation element (Fig. 7, Lines 26-29), which specifies that the user attribute "...:name" of the library card must be checked against the most recent revocation information from the revocation authority "urn:lib:blacklist". Revocation can also be based on a combination of user attributes from different credentials, in which case there will be multiple Attribute child elements per VerifierDrivenRevocation. The presentation policy can also contain multiple VerifierDrivenRevocation elements for one or several credentials, the returned presentation token must then prove its non-revoked status for all of them.

Security Discussion

For our framework to be useful, the various parties need to be given security guarantees: a verifier wants to be sure that if a presentation token verifies then all the statements made in it are indeed supported by the issuer and have not been revoked. Furthermore, the verifier wants to be sure that inspection will succeed when needed. The issuer wants to have similar guarantees w.r.t. issuance tokens. The user wants assurance that her privacy is maintained, i.e., that no more information is leaked than what she willingly released in a presentation token.

Formally proving that such guarantees are fulfilled, provided the underlying cryptography is sound, is far beyond the scope of this paper and is the topic of future work. Likewise, we do not go into detail here on the complex trust relations between the different participants in a Privacy-ABC system, or on which particular privacy or security threats can arise when some of these participants collude. Since presentation policies can always ask to reveal much more information than strictly necessary, one could also consider adding yet another authority to the system to approve "reasonable" policies. Finally, in order to deploy a Privacy-ABC system, one also needs a public-key infrastructure (PKI) to certify issuer parameters, revocation authority parameters, and inspectors' public keys.

For the individual cryptographic building blocks, security proofs are given in the cryptographic literature, and Camenisch and Lysyanskaya give a proof for their credential system [START_REF] Camenisch | An efficient system for non-transferable anonymous credentials with optional anonymity revocation[END_REF]. However, proving the security for the different combinations of the building blocks has not been done, although there is no reason to believe that such combinations would not be secure. Thus, the first step in proving security of our language framework is to provide precise security notions that capture the high-level security properties stated above and to prove that the composition of the cryptographic building blocks as imposed by our languages achieves those. Next, one would have to show that the mapping of our languages to the concrete cryptographic realizations is sound. Only then one could attempt to formally prove that the security guarantees as stated above are fulfilled.

Conclusion

We presented a language framework enabling a unified deployment of Privacy-ABC technologies, in particular, of U-Prove and Identity Mixer. Our framework improves upon the state of the art [START_REF]Microsoft U-Prove[END_REF][START_REF] Camenisch | A card requirements language enabling privacy-preserving access control[END_REF] by covering the entire life-cycle of Privacy-ABCs, including issuance, presentation, inspection, and revocation, and by supporting advanced features such as pseudonyms and key binding. The framework offers a set of abstract concepts that make it possible for application developers to set up a Privacy-ABC infrastructure and to author policies without having to deal with the intricacies of the underlying cryptography.

In an upcoming companion paper, we demonstrate the soundness of our languages by providing a formal semantics that specifies the effects of issuing, presenting, verifying, inspecting, and revoking credentials on the user's credential portfolio and on the knowledge states of the involved parties. A complete description of our framework including the language description as well as the formal semantics is available as a technical report [START_REF] Camenisch | A language framework for privacy-preserving attribute-based authentication[END_REF].

The proposed language framework has been implemented as part of the ABC4Trust project, where it will be rolled out in two pilot projects. Preliminary tests indicate that our language framework adds a noticeable but reasonable overhead to the cryptographic routines, comparable to the overhead incurred by, for example, XML Signature [START_REF] Shirasuna | Performance comparison of security mechanisms for grid services[END_REF] with respect to the underlying signing algorithm.

Our language framework supports a number of different authentication mechanisms including the mentioned privacy-preserving ones but also standard mechanisms such as X.509. However, most of them will not support the full set of features but we are currently working on a protocol framework that allows the combination of different cryptographic mechanisms to address this.

Fig. 1 .

 1 Fig. 1. Entities and the interactions between them.

1 <CredentialSpecification 3 <AttributeDescriptions 4 <AttributeDescription 6 </AttributeDescription> 7 <AttributeDescription 8 <AttributeDescriptionFig. 2 .

 1346782 Fig. 2. Credential specification of the identity card.

4 <RevocationInfoReference 5 </RevocationInfoReference> 6 <NonRevocationEvidenceReferenceFig. 3 .

 4563 Fig. 3. Issuer and revocation authority parameters.

5 <Pseudonym 6 <Credential 13 <DisclosedAttribute

 5613 Alias="nym" Scope="urn:library:issuance" Exclusive="true"/> Alias="id" SameKeyBindingAs="nym"> AttributeType= "urn:creds:id:state"/> 14 </Credential> 15 </PresentationPolicy>

Fig. 4 .

 4 Fig. 4. Presentation policy for an identity card.

1 <IssuancePolicy> 2 <PresentationPolicy 3 <CredentialTemplate 7 <CarriedOverAttribute 8 <SourceCredentialInfoFig. 5 .

 123785 Fig.5. Issuance policy for a library card. The presentation policy on Line 2 is depicted in Figure4.

5 <Pseudonym 8 <Credential 9 ... 10 <DisclosedAttribute 11 <AttributeValue> 15 <CredentialTemplateFig. 6 .

 5891011156 Fig.6. Issuance token for obtaining the library card.

11 <DisclosedAttribute 29 </VerifierDrivenRevocation> 30 <AttributePredicate 31 <AttributeFig. 7 .

 112930317 Fig. 7. Presentation policy for borrowing books.

Acknowledgements

The authors thank Bart De Decker, Robert Enderlein, Lan Nguyen, and the anonymous referees for their valuable comments. The research leading to these results was supported by the European Commission under Grant Agreement 257782 ABC4Trust.


Anders Fongen
email: anders.fongen@ffi.no

Federico Mancini

Identity Management and Integrity Protection in Publish-Subscribe systems

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction and PubSub security principles

The integration of a security model into a Publish-Subscribe distribution system is the objective of this paper. Its implementation employs services from an Identity Management System and the Trusted Platform Module (TPM) hardware unit.

In a Publish-Subscribe (PubSub) system, the information is not disseminated based on the addresses (or any individual property) of the receivers, but on subscriptions, through which the receivers specify their interest for information. Two forms of subscriptions are prevalent: One is to associate the information elements with a set of topics which are used as selection criteria in subscriptions, the other is to specify conditions for information of interest (like ''currency==USD'' or ''temp>90F''). In this paper the first form will be used since this is the most widespread approach.

The concept of Identity Management (IdM) introduces services for assured management of identities and their associated attributes: Key pairs for signing, encryption and authentication, roles for access control purposes [START_REF] Sandhu | The NIST model for role-based access control: towards a unified standard[END_REF] and other attributes that can support application services. For the remainder of this paper, the term Attributes also includes the concept of Roles.

Attributes may express the authorization of an entity and they should therefore be attested by a trusted party called an Identity Provider (IdP). The data structure used for that purpose is the Identity Statement (IS), where the identity, keys and attributes are stored and protected by the signature of the trusted IdP. The IS is somewhat similar to a Public Key Certificate, but an IS has a shorter life time and contains attributes as well as the public key. The short lifetime of an IS eliminates the need for a revocation arrangement.

The PubSub distribution principle has been demonstrated to be highly scalable. It allows route aggregation, multicast employment, loose coupling between parties, message queuing and sometimes message ordering guarantees.

Security concerns

On the other hand, the PubSub principle also poses a set of security problems which are often overlooked, like:

-Is the published information to be trusted as unmodified and authentic? -Who is the publisher, and is it authorized to publish this information? -Will the publications only reach authorized and authenticated subscribers? -Who operates the message routers, and are the routers able to maintain privacy of subscriptions, and confidentiality and integrity of messages?

Protection of systems, including PubSub systems, is a multi-faceted problem. As Wang et al. [START_REF] Wang | Security issues and requirements for internet-scale publish-subscribe systems[END_REF] points out, it includes authentication, access control, information integrity, service integrity, confidentiality, accountability and availability. This paper focuses on how authentication and access control mechanisms provides information integrity and confidentiality, and how hardware-based units may support the need for service integrity.

The simple and widespread solution to authentication is to let every system keep its own registry of user names and passwords, an approach which is known to scale poorly and to create inconsistent and stale user information. A system based on centralized identity providers can offer a centralized registry and mutual authentication of client and service.

Access control in PubSub systems can be divided into those who enforce their policies either on connections, on subscriptions or on individual messages. The system being presented in this paper is the latter category, where each message being published is given an access policy which is checked for every subscriber before delivery.

Access control systems can be identity based, where privileges are assigned to individual users, or role based, where privileges are given to roles which again are assigned to users. Role Based Access Control [START_REF] Sandhu | The NIST model for role-based access control: towards a unified standard[END_REF] are known to scale better in terms of management resource requirements, but role engineering is necessary in order to avoid a combinatorial explosion of the role set. The use of RBAC access control in PubSub systems was investigated by Belokosztolszki et al. [START_REF] Belokosztolszki | Role-based access control for publish/subscribe middleware architectures[END_REF], but their work enforces the access policy only on subscription level. IBM's WebSphere MQ takes a similar approach, where access to "topics" (called nodes) are controlled by an ACL-based protection mechanism.

Our work extends, in some respects, the protection mechanism proposed by Fiege et al. [START_REF] Fiege | Security aspects in publish/subscribe systems[END_REF], where the use of Attribute Certificates controls the reception of individual messages, although our work pays more attention to the problems related to identity management and how the access control mechanisms can mediate the message flows.

In the context of a PubSub distribution system, the use of Identity Management may increase the trust in the integrity and the confidentiality of the messages, and the control of who can post and subscribe to messages. This can be done in a scalable manner with loose coupling between the responsible parties:

-The integrity of messages is the concern of the subscriber, which should be able to express publication requirements and verify the correctness of the content. -The confidentiality is the concern of the publisher, which should be able to specify the required authorizations for the subscriber to receive it. -The authenticity of identities (routers and clients) is the responsibility of the Message Routers, which serves as the contact point to the transport infrastructure and requires that all entities authenticate themselves prior to operation. -The integrity of identifiers, keys and attributes associated with an entity (subscriber or publisher) is the responsibility of the Authority, which operates an Identity Provider service for the purpose of issuing identity statements.

This "separation of concern" pattern reduces the necessary amount of coordination and control traffic, and offers a flexible arrangement for the expression and enforcement of the security requirements.

From an architectural perspective, access control adds an extra dimension to message routing in a PubSub system. There is a set of topics (hierarchical or orthogonal) associated with publications and subscriptions which mediate the message flow from publishers to subscribers. The additional requirement listed above can be distributed between routers so that messages do not travel further than necessary. There is no need to pass on a message if there are no authorized subscribers downstream (even if they subscribe to the given topics). Similarly, there is no need to pass on messages from publishers which are not approved by any downstream subscribers.

Integrity protection of routers

The descriptions in the previous sections indicate that the confidentiality of messages rely on the integrity of the message routers. If they fail to operate according to the subscription requirements in the messages, confidentiality may be compromised.

The approach taken in this paper is to employ hardware units called Trusted Platform Modules (TPM) to seal the configuration of the router nodes in order to detect malware etc. The TPM is non-bypassable and tamper-proof. The use of TPM will be discussed in Section 5.

Gismo IdM

The IdM prototype being presented in this paper was once developed with a service oriented, tactical environment in mind, with ample opportunities for cross domain operation and prudent networking protocols. In addition to the IdP services, it also offers a range of authentication protocols for use in different contexts. It is called Gismo IdM from a project called "General IT Security for Mobile Operations" at the Norwegian Defence Research Establishment. [START_REF] Fongen | Architecture patterns for a ubiquitous identity management system[END_REF] Gismo IdM supports the PubSub environment excellently.

The contribution of this paper is a novel security model for PubSub service environment and its implementation, which partly relies on the services from an IdM, partly on a hardware based integrity protection. The integration of access control in the message routing decisions has not been observed in existing publications.

The remainder of the paper is organized as follows: Section 2 gives an architectural overview of the PubSub system which is being presented. In Section 3 the mechanisms related to publication selection and forwarding are described. Section 4 gives a detailed presentation of the underlying identity management systems (Gismo IdM). Furthermore, a presentation of how the TPM hardware module can cooperate with the IdM in order to support service integrity is discussed in Section 5. The paper presents its conclusions and suggestions for further research in Section 6. -There are three types of actors: Publishers, Subscribers and Message Routers (simply called Routers for the remaining of the paper). A process can be both publisher and subscribers at the same time since they use the same interface. Figure 2 illustrates the representation of a subscription. It consists of a set of topic strings, which are to be interpreted in a hierarchical context: A subscription related to a node in the topic tree also includes all sub-topics under that node. The subscription also includes a logical expression that must evaluate to "true" with respect to the publisher's identity attributes: The subscription shown in the figure requires that the publisher either has the attribute nationality=''uk'' or sec clearance=''NATO secret''. Otherwise, the subscription will not apply to messages posted by that publisher.

Outline of the PubSub implementation

/news/security/incidents /alarms/ids/building-203 (sec_clearance="NATO secret") topics: publisher requirements:

(nationality="uk") or Subscription Fig.

Subscription representation

Publications are, in the same manner, annotated with a set of topic strings to describe its categories, and a boolean expression which must evaluate to "true" with respect to the attributes of the subscriber, called the subscriber requirement. Its function is to protect the confidentiality of the message, and it is the responsibility of the message routers to ensure that the confidentiality is not broken.

Functional requirements

As a basis for the design and analysis, the functional requirements to how an Identity Management system (IdM) will influence the properties of a PubSub system will now be described:

-The message flows from publishers to subscribers are mediated by topics of subscriptions and publications, as well as the identity attributes of the parties and the related attribute requirements. Messages will never be delivered to unauthorized subscribers or from unauthorized publishers. -Client (publishers and subscribers) to router connections and router to router connections must be mutually authenticated. -Cross domain authentication is possible where there are trust relations between the given IdPs. -Publications are signed for integrity protection, and the identity statement of the publisher is included with the message. -A subscription to one topic implies subscriptions to all sub-topics as well.

Non-functional requirements

To improve the scalability, resilience and reliability of the PubSub system, a set of nonfunctional requirements must be met:

-A router decision to stop a message on its way to the subscriber should be made as close to the publisher as possible, regardless if it is a matter of topics or authorizations. -There should be no revocation mechanism for the identity statements. ISes should be issued with so short lifetime that revocation becomes unnecessary. A connection is terminated if the ISes involved in authentication expires without being renewed. -There should be no need for configurations of the message routers except for loading their key pairs and enter the IP addresses of their link neighbors. No registration of client identities or topics need to take place. -In the case where topics are hierarchically organized, the syntax representation of a topic need to list all ancestor topics as well (e.g. a full "pathname" from the top of the topic tree).

Operational details

The operation of the system will now be explained at the detail level of algorithms and protocol transactions. Some important data structures will also be described.

The subscription object

A subscriber expresses interest in posted publications based on topics and logical expressions of attribute values. Their syntax definition is as follows: The attribute values which enter into the logical expressions are taken from the identity statement of the publisher. This grammar is simplified for the purpose of discussion, e.g., logical operands cannot use the ">" operator etc.

Subscription matching

Let P denote the set of all publications. The subscription a matches a set A of publications, A ⊆ P. A publication p is a member of A if the boolean function match(a, p) returns true, formally expressed in the following manner:

A = {p|match(a, p) = true}, p ∈ P (1)
The selection made by the match() function maintains the integrity aspect of the delivery mechanism: In addition to the topicality selection, the publisher must meet the requirements set by the subscriber. These requirements are evaluated on the attributes of the publisher's identity statement, which are assigned and sealed by the Authority and distributed by the Identity Provider (IdP).

Please observe that a subscriber will not receive a publication if it doesn't meet the requirements set by the publisher. These requirements are expressed as a boolean expression, included in the publication object and evaluated on the attributes found in the subscriber's identity statement.

Merging of subscriptions

An important operation on subscription objects is the merge operation, during which a set of subscriptions are joined into one which represents the equivalent selection criteria. The operation is essential when a router wishes to announce the subscription of all its clients. The merging process takes two subscription instances (a, b) and produces an aggregate subscription c: c = merge(a, b) (

Where the set C matched by c relates to A and B so that

P ⊇ C ⊇ A ∪ B ( 3
)
The merge function may create aggregate subscriptions which match superfluous publications. It is an assumption that the aggregate subscription can have a more compact representation if it is allowed a fraction of false positives, which we choose to call the spill. The spill set can be expressed by a set function in the following manner:

spill(a, b, c) = {x|x ∈ C, x ∈ (A ∪ B)} (4)
which is simply the differential set C\(A ∪ B). Since the spill represents a waste of communication bandwidth, the relation between the spill and the size of the aggregate subscription is interesting from an optimization perspective. It is reasonable to expect a size/complexity tradeoff of an aggregate subscription and the amount of spill, approximated by

|spill(a, b, c)| = k size(c) ( 5
)
(k is simply a scaling factor). This tradeoff can be dynamically adjusted in the routers, since this is where the merging function is calculated, and this is where excessive publications are identified.

The publication object

A publication (sometimes simply called a message) is created by a publisher and sent to a router. The router will deliver it to locally connected subscribers and to neighboring routers in accordance with the service semantics and the existing subscriptions. The different aspects of publication and subscription routing will be described later. In this section, only the structure of the publication object will be described.

A publication object represents a publication as it is passed through the system. The elements of the object enables the system to enforce the confidentiality requirements of the message, and the integrity requirements set by the subscriber. The elements of the publication object are:

1. The actual message content (any serializable object) 2. The topics of the message 3. The identity statement of the publisher 4. A boolean expression which expresses the requirements which the subscriber must meet 5. An unique value used for loop detection 6. The publisher's signature Through the inclusion of the publisher's identity statement and a signature, the subscriber can verify that the publisher meets the attribute requirements, and that the message is unmodified. The publisher is not allowed to include the identity statement, this is done by the router which remembers the identity statement from the authentication phase.

Routing tables

When a Message Router starts its operation, it will make connections to a number of other routers, based on its configuration. The population of routers thus forms a mesh networks, as shown in Figure 1, where there are indirect connections between some routers, and routing information becomes necessary.

The routes are constructed through the flooding of subscription objects, there are no separate routing messages in the system.

Every router will construct an aggregated subscription based on the subscriptions of all its connected clients, add a time stamp, and regularly pass it to all its router neighbors for the purpose of flooding. For the remainder of the paper, this structure is called the AggSub object.

Every router will keep a list of the AggSub objects it has received, and from which neighbor it came from. The time stamp of the object serves two purposes: To detect and discard duplicates during the flooding process, and to establish the best route based on the earliest AggSub object received.

A local timestamp is attached to every entry in this list, so that stale routes and disappeared routers will be removed from the list. The regular dissemination of AggSub objects serves as a leasing mechanism for liveness control.

The purpose of propagating not only the topics of interest, but also the attribute requirement is to discard unwanted/unauthorized publications as early as possible in its forwarding path. The advantages of doing this is twofold: (1) To avoid wasting bandwidth and (2) to reduce the exposition of messages to message routers that are possibly compromised.

Publication routing

The distribution and use of AggSub-lists for routing information is simple and avoids separate mechanisms for route construction and subscription dissemination. It does not avoid route cycles, so a mechanism to detect and abort looping of publication messages must be in place.

When a router receives a publication, either from a connected publisher or from a neighbor router, it will consult the tables of connected subscribers and the AggSub list to determine who to forward it to. Locally connected clients are given the publications individually since they are separately connected.

Routers who are entitled to receive the publication are passed the publication through the neighbor for that route. Each neighbor are given at most one copy, and the neighbor from whom the publication was received is given none.

Loops are detected through the inclusion of a UUID in the publication object which are temporarily remembered in the router. Duplicates are silently discarded.

Client subscription table This table is built dynamically based on the connected clients. Each row represents a client and the columns contain the following information:

-An object representing the TCP connection -The identity statement of the client -The subscription objects of the client During connection, the clients authenticate themselves through a protocol where the client demonstrates the possession of its private key associated with its identity statement. The client table is a trusted source of information about the clients and their subject attributes, a trust which is essential to the message passing mechanisms.

Identity Management details

The PubSub system being presented in this paper requires a trusted party which issues credentials and an infrastructure for the distribution of these credentials. The credentials are needed to authenticate a client or a router, and to attest the attributes associated with the subject for access control purposes. The message forwarding mechanisms described earlier in the paper is considered to be access control operations, since they support the requirements of message integrity and confidentiality.

Systems that support these operations are commonly known as Identity Management (IdM) systems. At one end of the IdM system range we find Single Sign On (SSO) systems with client-authentication only and strong coupling between the parties. At the other end of the range there are web-service oriented system which require validation of credentials in both ends of a connection, with the ability to operate in a cross domain environment with loose coupling between the management domains.

For the PubSub system being described in this paper, the existing Gismo IdM experimental IdM system was used as a trusted third party. A architectural view of the Gismo IdM can be seen in Figure 3. Its notable properties are:

-Identity statements contain subject identifier, subject attributes, subject's public key, issuer identifier, issuer's public key and an expiration time. -Identity statements are issued with a short lifetime. No revocation arrangement is therefore needed. -Identity statements are issued by an Identity Provider to subjects that are properly registered in, e.g., a PKI. The subject's private key and the IdP's public key must be pre-installed in the subject's computer for the identity statement to be useful. -Guest identity statements can be issued to subjects who can present an identity statement issued by an IdP to which there exists a trust relationship. Guest identity statements allow parties belonging to different management domains to authenticate themselves.

For the use of the Gismo IdM in a service oriented (SOA) environment in a military disadvantaged network some efficient authentication protocols were developed. They minimize the number of protocol round trips by piggybacking authentication data on the actual service request and service response, and they minimize the required state space in the server through nontraditional replay protection mechanisms. [START_REF] Fongen | Identity management without revocation[END_REF] One of these authentication protocols has been used in the PubSub system as a means for mutual authentication of router-to-router and router-to-client connection. Consequently, all clients and routers need to be registered with an IdM instance and have their key pair installed prior to connecting to a router.

Cross domain connections

In those cases where the parties of a connection belong to different domains, i.e., they trust different IdPs, they cannot directly validate each other's identity statements. In order to authenticate across IdM domains, guest identity statements were introduced. Figure 4 shows how a client X a from IdM domain a presents its identity statement, termed (Id x ) a , to the IdP of domain b. On the condition that there exists a trust relationship between the domains a and b, IdP b can issue a guest identity statement with the same content and its own signature. The guest IS is termed (Id x ) b and may be validated by any member of IdM domain b. For the opposite direction, authentication will require the identity statement IdP a issued by IdP b in order to construct a signature chain back to the trust anchor of a. This IS is termed (Id a ) b and is enclosed in the guest IS response.

Validate cert name (asynchronous operation)

Client X a IdP a PKI a IdP b Server F b (Id x ) a (Id x ) a (Id x ) b (Id b ) a (Id b ) a (Id x ) b + (Message+Nonce)S x (Id f ) b + (Response+Nonce)E x S f
Fig. 4. The authentication protocol for the PubSub service. There is no replay attack protection since they are not considered as threats, but the response need to be protected for reasons of response replay and information compromise.

Figure 4 also shows the details of the authentication protocol. The design choice has been to sign the request for integrity protection, and to encrypt the response as a means of replay attack protection. The response also contains the necessary information to authenticate the responder.

This protocol was developed as a service invocation protocol in [START_REF] Fongen | Identity management without revocation[END_REF], and has been used as a connection protocol in the PubSub system. The symmetric key which is used in the encryption of the response (as a part of the asymmetric encryption operation) is subsequently used for the protection of the message traffic.

Protection of message integrity

In addition to the control of the delivery mechanisms, the IdM-supplied credentials also offer the protection of publication integrity. As pointed out in Section 3.4 the publication object includes the identity statement of the publisher and a signature which seals the content of the message.

The receiver can check the integrity of the message and the authenticity of the publisher by verifying the signature and validating the identity statement.

Validation requires trust in the IdP of the publisher, which exist if they belong to the same IdM domain or to domains with a trust relationship. If, however, they belong to domains between which there exist a chain of trust relations, then the validation cannot take place. Trust relations are per definition lateral, not transitive.

Renewal of identity statements

In a SOA environment where services are short lived, i.e., they finish very soon after being invoked, it suffices to check authenticity and authorizations during invocations. In a long lived service environment, where the services are active for hours after invocation, the credentials should be checked for expiration during this period.

The PubSub system is a long lived service, where the connection to a router may be held active for hours and days. Since the credentials used during connection establishment have an expiration time shorter than that (typically a small number of hours), their validity should be monitored so no connection can be active if the credentials are expired or invalidated.

For the connection to be maintained across credential expiration periods, the identity statement must be renewed during a connection period. The owner of an identity statement must contact the IdPs before expiration to get a new issue and send it to all its connected neighbors (clients and routers). Re-authentication is not necessary.

The recipient of the identity statement should validate it and check that the subject attributes meet the connection requirements. It should also replace the old set of attributes so that new subscriptions and publications reflect this set.

Existing subscriptions may be incorrect with respect to the new attribute set. Subject attributes are not included in the subscriptions when propagated through the network (only topic information and publisher requirements are). Therefore, the flow of publications will not need to be altered due to the new identity statement. The new set of subject attributes will always be present in the router which connects the client and make sure that the publications are delivered to clients based on their most recent attribute set.

Trusted binding of Message router operation

The confidentiality of publications is the responsibility of the message routers, which means that they must be trusted to operate correctly and not leak information to unauthorized subscribers.

Even if a message router has correctly authenticated itself to its neighbors, one cannot exclude the possibility for a message router to be infected by malware, operate incorrectly or to have been compromised in some other way. To some extent, it might possible to strengthen the trust between nodes by resorting to a trusted binding between a node identity and its own hardware and software configuration.

The concept of trusted binding has been introduced by Hegland et al. [START_REF] Hegland | A framework for authentication in nbd tactical ad hoc networks[END_REF] as a way to reduce the burden of authentication in a network with low resources, and is tightly connected to the idea of transitive trust. If an entity A has authenticated and trusts an entity B, and B has a trusted binding with C, then A will also trust C without further need for authentication. In a way, this is what already happens in our framework: a message router A trusts another message router C because it presents a proof of authentication (the identity statement) issued by an IdP b , which A trusts. However, we want to extend this concept to be able to trust, besides the identity of a message router, also its integrity. We accomplish this by integrating a TPM based attestation component in our identity management framework.

A TPM (Trusted Platform Module) [START_REF]TPM Main Specification[END_REF], is a cryptoprocessor that enables a machine to perform, among other things, a trusted boot and thereafter to report in a trusted way (attest) its running software and hardware configuration to a third party. The trusted boot measures all software components being run on the machine (by computing the hash of their binaries) from the boot moment until the OS takes control, and stores these measurements in the TPM registers (PCRs) in a tamperproof manner. The measurements can then be signed with the TPM private key (which never leaves the TPM), and sent to a third party which can verify them against a database of approved configurations. The procedure is illustrated in Figure 5. This can allow an IdP to verify not only the identity of a message router, but also that it was booted with genuine and updated software. This extra information can then be added to the identity statement as a new subject attribute: {TMPintegrity=AssuranceLevel2}. Neighboring nodes may require this assurance in order to accept the nodes' participation in the router network and, possibly, to create clusters of routers with different assurance levels.

Similar work has been done with IdM systems based on Kerberos [START_REF] Leicher | Implementation of a trusted ticket system[END_REF] and OpenID [START_REF] Leicher | Trusted Computing enhanced OpenID[END_REF], although the main goal is to improve the user experience by eliminating the need for passwords.

One limitation of the trusted boot approach is that the trust in the system is built by the boot process and passed transitively to the OS, which takes over the system once the boot is finished. This means that after this point we should trust the OS to measure correctly itself and the processes it is running in order to perform a trusted attestation. Unfortunately, OSes are often quite large and complex and are likely to contain vulnerabilities that can be exploited by an attacker. Obviously, an infected machine cannot be trusted to report correct information about itself to a third party. Besides, if a system is compromised, the machine must be rebooted again in order to establish a new chain of trust. This is why the trusted boot is said to be based on a static root of trust. Fig. 5. This diagram shows an example of attestation process (at very high level) that leverages on both the TPM, a classical trusted boot process, and a TXT enabled Intel processor which can be used to execute Flicker microapplications in a trusted setting. In this case the microapplication is a virus/malware scanner that is run securely before sending the node integrity attestation to the Identity Provider. The result of the scan is also sent as part of the TPM attestation.

Although continuous monitoring and measuring of all the system in search for infections or malfunctions is unrealistic, research is ongoing to define new techniques that can help attesting the status of a running machine. Property based attestation is one example [START_REF] Nagarajan | Property based attestation and trusted computing: Analysis and challenges[END_REF]. A better alternative, however, might consist in using a dynamic root of trust. The recent Intel and AMD processors offer a special instruction that allows the system to create a secure and trusted hardware environment for the execution of some given code, even if the rest of running system is compromised [START_REF] Grawrock | The Intel Safer Computing Initiative: Building Blocks for Trusted Computing[END_REF]. Therefore, trust in the system can be established dynamically at any time, independent of the boot process. The TPM is also involved in this process so that a node can attest that a certain piece of code was executed securely.

In particular, a framework called Flicker [START_REF] Mccun | Reducing the Trusted Computing Base for Applications on Commodity Systems[END_REF] allows to write micro applications that can be run safely at any time even the current OS is compromised. A report about the code execution can also be generated and certified with the help of the TPM in a fashion similar to the attestation process.

Associated with the PubSub research, a study is ongoing to understand how a dynamic root of trust based application like Flicker can be integrated with our framework. Our aim is to design an identity management system where authentication and valid identity statements can be issued also if some nodes in the network are compromised, and would normally not be trusted. The remaining probability for incorrect operation may be subject to calculation on forwarding path length: The higher number of routers used in a forwarding path for information, the higher is the aggregated probability for incorrect operation. These calculations can also consider the strength of crypto algorithms in use, the number of COI domains involved etc. This paper has described a novel model for protecting integrity and confidentiality of messages in a PubSub system. Pivotal to the model are the services of an IdM, which supports the authentication and access control operations, and the integrity protection offered by a non-bypassable hardware unit called TPM.

A proof of concept prototype has been written in Java to study the functional aspects of the proposed PubSub principles. A deeper evalution in the context of a military information system is planned in the near future. Also, the protection mechanisms that rely on a TPM hardware unit is being developed for the time being as an ongoing research project.

Figure 1

 1 Figure1outlines the design of the proposed PubSub system. Observe the following properties:

Fig. 1 .

 1 Fig. 1. PubSub system design outline

  expr binary-operator expr | unary-operator expr operand = literal | attribute literal = string | number | true | false attribute = string unaryoperator = not | nameexists binaryoperator = == | > | ismember | hastoken | substring ...

Fig. 3 .

 3 Fig.3. The functional components of the Gismo IdM. Observe that the IdP serves one single COI, and the trust relations are formed between COIs, not domains. Key management is handled by the PKI whereas the attribute management is done by the IdPs on the COI level.

-

  All actors belong to one Community of Interest (COI).

	Identity
	Provider
	Publisher
			Publisher
	Message
	router	Message	Publisher
	Subscriber	router
			Publisher
	Message
	router
	Subscriber	Message	Identity
		router	Provider
	Subscriber
	Community of Interest		Subscriber
			Community of Interest

-The identities of the actors in a COI are governed by an Identity Provider (IdP) which issues Identity Statements upon request. The identity statements together with the (pre-loaded) private key enable the actor to authenticate itself when a connection is established.

-Messages (also called Publications) flow from one publisher to zero or more subscribers.