WO2009065428A1

WO2009065428A1 - Method for transferring information about a user in an identity management system

Info

Publication number: WO2009065428A1
Application number: PCT/EP2007/010205
Authority: WO
Inventors: Joao Girao; Amardeo Sarma; Joao Da Silva
Original assignee: Nec Europe Ltd.
Priority date: 2007-11-23
Filing date: 2007-11-23
Publication date: 2009-05-28

Abstract

A method for transferring information about a user in an Identity Management System, wherein the Identity Management System includes at least one Identity Provider (2) and one or more cooperating Service Providers (1), the method comprising the steps of, at a Service Provider (1), upon receipt of a service request from the user, requesting certain user information about the user from said at least one Identity Provider (2), and, at the Identity Provider (2), requesting said user information from an Assertion Provider (3) which has the relevant data by using Identity Management Protocols, and providing said user information to said Service Provider (1) in form of an assertion digitally signed by said Assertion Provider (3), is characterized in that a credential is generated on said user information and concatenated with said user information to produce said assertion, wherein said credential is constructed in such a way that it is verifiable without revealing by which party said credential has been generated.

Description

METHOD FOR TRANSFERRING INFORMATION ABOUT A USER IN AN IDENTITY MANAGEMENT SYSTEM

The present invention relates to a method for transferring information about a user in an Identity Management System, wherein the Identity Management System includes at least one Identity Provider and one or more cooperating Service Providers, the method comprising the steps of: at a Service Provider, upon receipt of a service request from the user, requesting certain user information about the user from said at least one Identity Provider, and at the Identity Provider, requesting said user information from an Assertion Provider which has the relevant data by using Identity Management Protocols, and providing said user information to said Service Provider in form of an assertion digitally signed by said Assertion Provider.

In recent years several Identity Management (IdM) Systems have evolved which take care of the management of the user's credentials in connection to different cooperating services and provide the ability to manage the provisioning of the user's identity from a central point. In current Identity Management Systems different protocols are employed, for example, OpenlD, SAML (Security Assertion Markup Language) developed by the OASIS (Organisation for the Advancement of Structured Information Standards), or Cardspace, to name just a few of the existing protocols. An important task of such Identity Management Protocols is to transfer pieces of information about a user between participating Service Providers which the user accesses for the purpose of some kind of service consumption.

A crucial problem in this context is the protection of the user's privacy. In order to meet with such privacy concerns in existing Identity Management Systems, information about a user is generally transferred between cooperating Service Providers in the form of so-called assertions, which are digitally signed pieces of user information. In terms of the present patent application, the entity which provides such an assertion is called Assertion Provider. In existing systems, Assertion Providers generally employ conventional asymmetric encryption schemes in order to digitally sign pieces of information about a user. As to what concerns the protection of user data and user privacy in the Internet, and in particular in Identity Management Systems, there are already technologies that focus on how assertions can be delivered from an Assertion Provider to a Service Provider without revealing the identity of the user. For example, idemix is a technology which protects a user's privacy in terms of anonymity and unlinkability by employing privacy enhanced PKI (Public Key Infrastructure).

It is an objective of the present invention to improve and further develop a method of the initially described type for transferring information about a user in an Identity Management System in such a way that, by employing mechanisms that are readily to implement, information about a user is protected as much as possible.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim, such a method is characterized in that a credential is generated on said user information and concatenated with said user information to produce said assertion, wherein said credential is constructed in such a way that it is verifiable without revealing by which party said credential has been generated

According to the invention it has first of all been recognized that the provision of digital signatures of user information, although intended to improve the privacy protection, entails an inherent security problem. Since the assertions are digitally signed, the problem poses that the verifier, in general the requesting Service Provider or the Identity Provider, might gain information about the signing Assertion Provider and, hence, indirectly about the user. According to the invention it has been further recognized that such leakage of information can be minimized or even completely avoided by generating a credential on the user information and merging it with the user information to produce the assertion, wherein the credential is constructed in such a way that it can be verified (by the Identity Provider or by the Service Provider, for example) without revealing by which entity said credential has been generated. In other words by employing such credential, unlinkability in terms of the Assertion Provider which has produced the assertion is realized. Thus, the method according to the invention prevents the information leakage occurring in the verification of assertions in prior art Identity Management Systems in which conventional asymmetric encryption schemes are employed. Furthermore, the method according to the invention is easily to be added on current Identity Management solutions since it does not directly impact the protocol itself. Insofar, no changing of the underlying IdM standard is involved, except on the signature generation and the verification phases.

As an example, one can consider a driver who wants to rent a car from a car rental agency. In this case, the car rental agency functions as Service Provider. The fact of whether or not the user has a valid driving licence constitutes an attribute of the user which requires confirmation by a third party. Since a driving licence is normally bound to the home location, the local DMV (Directorate of Motor Vehicles), which issued the driving licence, is the only entity that can verify the validity of that driving licence.

In the above case, according to Identity Management Systems known in the state of the art, the car rental agency (functioning as a Service Provider) would request an assertion as to the validity of the customer's driving licence from the DMV (thus functioning as Assertion Provider). Since the Identity Management Protocol itself is distributed, the signature on this assertion (which simply contains the user information "yes, customer disposes of a valid driving licence", or "no, customer does not dispose of a valid driving licence") would be from the local DMV. As the Service Provider, here the car rental agency, needs to verify the signature of the assertion, it would need the certificate for the employed signature. This way the car rental agency would learn which DMV signed the customer's driving licence. From this information the car rental agency can conclude where the customer is from. However, this information is completely irrelevant as regards the validity of the driving licence and, hence, unnecessary for the Service Provider's decision of whether to allow or deny the user access to the requested service.

At the very least, even if one removed all information from the certificate (which would make it harder for a Service Provider to trust the assertion), the Service - A -

Provider could still compare two different public keys related to two different signatures from two different users to know if their licences were from the same town/region or not.

It is to be noted that in specific scenarios the consequences of such information leakage might even be worse than in the example described above, i.e. information that is unnecessarily revealed (in terms of a pure confirmation of an assertion) can be more sensitive than information about a user's regional provenance. In this regard, one could think of services which, e.g., require the availability of a health insurance. In this case, the health insurance company would function as Assertion Providers, which, according to prior art, would sign the assertion by using a normal asymmetric encryption scheme. The verification of the signature by a Service Provider, for instance, would thus reveal - in addition to the availability of a valid insurance - the health insurance company itself. Thus, the Service Provider would know, for example, whether the user has a contract with a compulsory health insurance or with a private health insurance. In certain countries, for example in Germany, it is possible to infer, at least to a certain extent, the user's income from this information.

As what concerns a specific embodiment, the assertion includes a verifiable attribute of user, user preferences, and/or identification information. The verifiable attribute of the user may be, for example, the availability of a driving licence, of a credit card, or of a health insurance. In addition, a user attribute may refer to the information of whether the user has a certain age, e.g. whether the user is over 18 years old.

Advantageously, the credential on the assertion is automatically generated by either the Assertion Provider or by the Identity Provider. Generally, the Identity Provider will contact Assertion Providers in order to retrieve signed statements on the user's attributes and, as the case may be, on his authentication status. However, it is also possible that the Identity Provider himself acts as an Assertion Provider and provides the relevant data and generates a credential on the assertion. According to a preferred embodiment, the credential includes a signature generated on the basis of a group signature scheme. In a group signature scheme a set of private keys which are related to the same public key is distributed over a group. When a member of a group signs a message it is impossible to distinguish which member signed the message. This holds true even to other members of the group except the issuer of the keys. The group may be a group of Assertion Providers, in particular Assertion Providers which are capable to provide the same kind of information (e.g. certain age, availability of a certain kind of licence, etc.). In connection with the above given example the DMV (Directorate of Motor Vehicles) of a country may constitute such group and each local DMV office would have a private key belonging to the group. The private key distribution may be performed by the Identity Provider as the central entity of the IdM system.

Specifically, each Assertion Provider in a group of Assertion Providers may generate digitally signed assertions by employing its private key which it received in the distribution process. The verification of the assertion may be performed by the Identity Provider by employing of the group public key. After verification, the Identity Provider may forward the result of the verification to the requesting Service Provider. Alternatively, the Identity Provider may first forward the assertion to the requesting Service Provider, which then performs the verification of the assertion by employing the group public key. As regards the distribution of the certificate that contains the group public key, a Public Key Infrastructure (PKI) may be employed.

It is to be noted that a distribution of the same private key from a classical asymmetric key over the members of a group would achieve the same practical result but would be highly insecure since the corruption of one of this keys would require the complete change in the keys of the system including the public key. With the employment of group signature protocols this problem is minimized since a key from a member can be revoked.

To return to the above given example, when a local DMV receives a request it signs with its private key. Upon reception, the Service Provider can verify the signature by using the public group key of the countries DMV. This way, the Service Provider is given no possibility to learn anything about the specific location where the assertion comes from, or, more specifically, which local DMV provided the requested user information.

According to another preferred embodiment, the credential is generated on the basis of a zero knowledge protocol. By this means it is possible to achieve a verification of the credential without revealing by which party the credential was generated. In this context, an Assertion Provider will function as prover of the assertion and the Identity Provider or a requesting Service Provider my function as verifier of the assertion.

As regards a high level of reliability and trust it may be provided that the Assertion Providers include a Certification Authority, e.g. a governmental organisation or a public department.

There are several ways of how to design and further develop the teaching of the present invention in an advantageous way. To this end, it is to be referred to the patent claims subordinate to patent claim 1 and to the following explanation of a preferred example of an embodiment of the invention, illustrated by the figure. In connection with the explanation of the preferred example of an embodiment of the invention by the aid of the figure, generally preferred embodiments and further developments of the teaching will be explained.

In the drawings

the only Fig. illustrates an application scenario according to one embodiment of a method according to the present invention.

As shown in the Fig., a case were a group signature is supplied will be described as a specific example. Operation of the embodiment will be explained below.

As group signature, a system which J. Camenisch and M. Stadler introduced in a paper called "Efficient group signatures for large groups" in the international conference CRYPTON '97 is known. According to the specific embodiment illustrated in the Fig., a user first accesses a Service Provider 1 to start a service consumption. As already described above the Service Provider 1 may be a car rental station at which the user intents to rent a car. The accessing procedure is illustrated by the arrow labelled with character A.

As part of an authentication process (see arrow B) the Service Provider 1 requests a validation of the user from Identity Provider (or Identity Broker) 2. In addition to the validation, the Service Provider 1 requests an attribute of the user which in this case is the information of whether the user disposes of a valid driving licence or not. Additionally, user information with respect to the availability of a credit card may be requested as further user attribute.

In a next step (indicated by arrow C) the Identity Provider 2 contacts an Assertion Provider 3 in order to retrieve signed statements on the user's attribute or attributes requested by the Service Provider 1 and on the users authentication status. It is to be noted that it is also possible that the Identity Provider 2 himself functions as Assertion Provider 3. In the specific case described here the Assertion Provider 3 is the local DMV which issued the users driving licence.

Next, the Assertion Provider 3 verifies its database or contacts other Assertion Providers in order to retrieve the relevant data. Upon retrieval of the relevant data the Assertion Provider 3 digitally signs the piece of information by using its private key of a group signature. The private keys of the group signature may have been distributed among the country's local DMVs by the Identity Provider 2 using a PKI. The Assertion Provider 3 forwards the digitally signed information in form of an assertion to the Identity Provider 2 (see arrow D).

As indicated by arrow E, upon receipt of the assertion the Identity Provider 2 delivers the assertion to the Service Provider 1. The Service Provider 1 performs a verification of the assertion by using the public group signature key. Depending on the result of the verification, the Service Provider 1 either provides the service or returns an error to the user (indicated by error F). That is, in case the assertion contains information "yes, user has valid driving license" the user is allowed to rent a car. However, the car rental station will deny the user's request in case the assertion contains information "no, user does not have valid driving license".

It is to be noted that due to the employment of group signatures (instead of conventional asymmetric encryption schemes) neither the Service Provider 1 nor the Identity Provider 2 gain any knowledge beyond the pure information of whether the user has a valid driving licence or not. In particular, there is no information leakage as regards the specific assertion provider that provided the requested information. Thus, the user's privacy is fully preserved in all respects despite the fact that the requested information has been signed by the Assertion Provider 3 and that the signature has been verified by the Service Provider 1.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. A method for transferring information about a user in an Identity Management System, wherein the Identity Management System includes at least one Identity Provider (2) and one or more cooperating Service Providers (1 ), the method comprising the steps of: at a Service Provider (1 ), upon receipt of a service request from the user, requesting certain user information about the user from said at least one Identity Provider (2), and at the Identity Provider (2), requesting said user information from an Assertion Provider (3) which has the relevant data by using Identity Management Protocols, and providing said user information to said Service Provider (1 ) in form of an assertion digitally signed by said Assertion Provider (3), c h a r a c t e r i z e d i n that a credential is generated on said user information and concatenated with said user information to produce said assertion, wherein said credential is constructed in such a way that it is verifiable without revealing by which party said credential has been generated.

2. The method according to claim 1 , wherein said assertion includes a verifiable attribute of the user, user preferences and/or authentication information.

3. The method according to claim 1 or 2, wherein said credential is automatically generated by said Assertion Provider (3) or by said Identity Provider (2).

4. The system according to any of claims 1 to 3, wherein the Identity Provider (2) functions as Assertion Provider (3).

5. The method according to any of claims 1 to 4, wherein said credential includes a signature generated on the basis of a group signature scheme.

6. The method according to claim 5, wherein, in the context of said group signature scheme, a set of private keys is distributed among a group of Assertion Providers.

7. The method according to claim 6, wherein said group of Assertion Providers is specified in such a way that all members of said group are capable of providing the same kind of user information.

8. The method according to claim 6 or 7, wherein the private key distribution is performed by the Identity Provider (2).

9. The method according to any of claims 6 to 8, wherein an Assertion Provider (3) out of said group of Assertion Providers generates said digitally signed assertion by employing its private key received in the distribution process.

10. The method according to any of claims 5 to 9, wherein the Identity Provider (2) verifies said assertion by employing the group public key and forwards the result of the verification to the requesting Service Provider (1).

11. The method according to any of claims 5 to 9, wherein the Identity Provider (2) forwards said assertion to the requesting Service Provider (1 ), which then performs the verification of said assertion by employing the group public key.

12. The method according to any of claims 5 to 1 1 , wherein the certificate that contains the group public key is distributed by means of a Public Key Infrastructure (PKI).

13. The method according to any of claims 1 to 4, wherein said credential is generated on the basis of a zero knowledge protocol.

14. The method according to claim 13, wherein said Assertion Provider (3) functions as prover of said assertion and wherein the Identity Provider (2) or the requesting Service Provider (1 ) function as verifier of said assertion.

15. The method according to any of claims 1 to 14, wherein said Assertion Provider (3) or said group of Assertion Providers includes a Certification Authority.