Resources
- Identity Use Cases & Scenarios.
- FIDIS Deliverables.
- Identity of Identity.
- Interoperability.
- Profiling.
- Forensic Implications.
- HighTechID.
- Privacy and legal-social content.
- D13.1: Identity and impact of privacy enhancing technologie.
- D13.1 Addendum: Identity and impact of privacy enhancing technologies.
- D13.3: Study on ID number policies.
- D13.6 Privacy modelling and identity.
- D13.7: Workshop Privacy.
- D14.1: Workshop on Privacy in Business Processes.
- D14.2: Study on Privacy in Business Processes by Identity Management.
- D14.3: Study on the Suitability of Trusted Computing to support Privacy in Business Processes.
- D14.4: Workshop on “From Data Economy to Secure.
- D16.3: Towards requirements for privacy-friendly identity management in eGovernment.
- Mobility and Identity.
- Other.
- IDIS Journal.
- FIDIS Interactive.
- Press & Events.
- In-House Journal.
- Booklets
- Identity in a Networked World.
- Identity R/Evolution.
Unlinkable Delegation of Rights by DREISAM
If a customer uses personalised services in a single-stage business process, the threat to his privacy exists in the undesirable linking of his individual profiles. He can protect himself with identity management through a controlled release of personal data, so that his profiles appear independent of each other. However, this has so far not been technically possible with personalised services in a multi-stage business process. The DREISAM delegation system presented in the following is a usage control mechanism, with which a customer-controlled disclosure of personal data is now also achieved in multi-stage service processes. A customer must not transmit his secret authentication token, e.g. his secret cryptographic key kU, but an authorisation for the use of certain personal data or partial identities for a predetermined purpose. The added value of DREISAM is that a customer can be unlinkable for several delegations and thus over several transactions. A linking of the profiles resulting in each case on this customer is thereby hindered in that, at best, no identifying data accumulates in more than one profile. DREISAM extends current identity management systems.
DREISAM specifies a credential-based usage control mechanism for a delegation and use of personal data to a proxy. Through the agreed privacy policy, this usage control defines the framework in which disclosed personal data can be used by a proxy. A customer can control the disclosure of personal data, also via a proxy, through the use of anonymous credentials and thus protect himself from an undesirable combination of his profiles.
Section 6.1.1 presents the usage control model on which DREISAM is based. The protocol for a delegation of an authorisation for the use of personal data is specified in section 6.1.3. Section 6.1.4 focuses to the same degree on the revocation of a delegated authorisation.
Model of Usage Control for Privacy in Multi-stage Business Processes
Multi-stage business processes are characterised by a proxy of a customer having to obtain the customer’s personal data so that he can make use of subsequent services in the interests of his customer. Personal data of a customer is, on the one hand, the object of access and, on the other, an authorisation for the proxy to obtain access to services of a further service provider. There are several options for a customer to delegate personal data and with it the receipt of a relevant anonymous credential for a proxy. He can either delegate his secret authentication token for anonymous credentials, i.e. his secret key kU, issue an anonymous credential with the relevant data himself for his proxy, or have it issued by a certification authority.
The transmission of the secret key kU does not present a possibility due to the resultant loss of control of the customer over his identity. The second possibility also does not come into consideration. If a customer were to issue an anonymous credential for his proxy, then the customer is firstly identifiable by way of the digital signature of the credential and, secondly, these credentials must be accepted by the end service provider. The third possibility is therefore selected: a certification authority issues anonymous credentials for the personal data to be delegated and their attributes on behalf of the customer to his proxy. In addition, the customer sends an authorisation for the use of the personal data required to his proxy.
An authorisation applies to a certain amount of personal data, i.e. to a partial identity and not to the whole identity of the customer. With the delegation of an authorisation, a proxy is authorised to receive the specified partial identity of the customer and use it for a certain purpose. The purpose of use is defined by the conditions of an authorisation. As a countermove, a proxy is committed with regard to the handling of the partial identity received. The decision about the release of a partial identity to the proxy is made by the data provider managing the partial identities. Since personal data is used in the form of a credential and the proxy will therefore receive a credential on the partial identity, this decision is made by a certification authority. This involves the certification authority which will issue the credential for the proxy.
Whereas user-centric identity management to date is an access control mechanism for personal data and authorisations apply to the access to data, it is now by DREISAM possible to additionally apply it to the use of delegated data. The model is thereby expanding from access control to usage control. A general model for usage control was first defined by Park and Sandhu (Park and Sandhu, 2004). They extend the access control model with the components of obligations and conditions and thereby present decision factors for the use of systems and data, generally by objects. An obligation corresponds to a commitment by means of which it is examined whether obligatory requirements are fulfilled before or during a usage decision. Conditions, on the other hand, take into account environmental or system attributes such as the time or CPU-ID. The usage control model for the privacy in accordance with informational self-determination consists of two parts: the disclosure of personal data is specified by an access control model and the use of the disclosed data by a model of usage control.
The parties involved in the access control model are the customer, his proxy and a certification authority. Through a confirmation, a certification authority regulates the access to personal data by attesting the relationship between the data and a proxy for disclosure. Figure 6.1 shows these relationships.
Figure 6. Access control model for a disclosure of personal data.
As soon as the personal data requested is delegated to a proxy and he wants to use it as far as a further service provider is concerned, the data no longer constitutes the object of access but an authorisation for access to the further service. The usage control model from Figure 6.2 now applies to the security interests of the requested service provider. The conditions remain preserved in their role, however, due to their independency of subject and object of access, provided that there is no conflict with the interests of the service provider. The obligations are again directed towards a proxy, but are now called for by the requested service provider. Instead of a certification authority, the respective end service provider now takes over the usage control and thereby enforces its security interests.
Figure 6. Model of the usage control for the use of personal data by a proxy.
Access and Usage Rights in the Form of a Privacy Policy
The usage control of a customer’s personal data is regulated by his security interests. A customer defines his interests as rules in the form of a privacy policy. A rule applies to the data concerned, its recipient and the permitted ways of processing, i.e. to the purpose of a service process. The use of the data involved applies to the service provider, with whom a customer directly communicates and who assumes the role of a proxy in the case of a multi-stage service.
The proxy role is the central focus of the privacy policy. According to the terminology of usage control (Park and Sandhu, 2004), the subject is a service provider or proxy, the object is the requested personal data or its assertions and the types of rights then result from the assigned authorisations, conditions and obligations. A privacy policy together with an authorisation presents the relationship and defines the use of personal data as follows:
Proxy: The personal data released or its statement may only be delegated to the service providers specified here in their role as proxy. For this, the customer specifies a list of his proxies as subjects.
End service providers: A proxy may only release the personal data transmitted to him to certain types of services or service providers. The limitation is specified by a list of the recipients.
Number of permitted usages of personal data: If the frequency of the use of personal data is known to the customer before a delegation and he does not wish to agree to unrestricted utilisation, then he restricts the number of uses by an upper limit.
Re-delegation: At this point, the customer specifies whether his proxy may re-delegate the delegated authorisations and the pertaining data.
Validity: An authorisation for the personal data delegated by a customer is only valid for a certain period of time. The period of time is defined with a commencement and termination date.
The enforcement of a privacy policy depends on the interest of the service providers and the certification authority. In order for an enforceable privacy policy to ensue, interest conflicts between the parties must be detected and, if necessary, compromises be negotiated. The resultant authorisations should then no longer be able to be altered. In the following, the demands on authorisations and their realisation is addressed.
Authori
The following demands on an authorisation are derived from the privacy threats according to the threat analysis from chapter five:
Purpose-related use of an authorisation: A delegated authorisation should only be valid for the purpose of the service, i.e. it is linked to the identity of the proxy and that of the subsequent service provider, the required function call of his service or its type and the number of usages permitted for a specified time.
Restricted delegation of an authorisation: If a proxy relays his authorisation, it should only be valid if the customer has agreed to this transmission.
Revocation of an authorisation: A customer should be able to revoke an authorisation for a proxy at any time, if a proxy has turned out to be an attacker, the delegated task has been completed earlier than expected or the customer’s credential concerned has expired or been revoked.
Integrity of an authorisation: Assuming that an attacker cannot break a cryptographic primitive, an alteration of an authorisation should be able to be detected.
Delegation of the minimal authorisation: A delegated authorisation for the proxy should apply exclusively to the disclosure of the customer’s data that is necessary for the proxy’s task.
Enforceability of an authorisation: The access control decisions of a certification authority and usage control decisions of an end service provider should follow the restrictions of a delegated authorisation. Either a customer has to control these decisions or they should be verifiable by the customer afterwards.
The first requirement applies to the service provider and in his service as proxy. This is fulfilled by the public key specifications pkProxy of the proxy as his unique identifier, the unique transaction number TID of the pertaining service process, a timestamp of issuance and the validity time period with commencement and termination date. The customer has received the key pkProxy with the authentication of the proxy. Information about the delegation of an authorisation is recorded as a further attribute in the proxy credential. Furthermore, a proxy credential is clearly identified by a serial number. This is necessary, for instance, in the event of a revocation of an authorisation. The fourth requirement is fulfilled by an authorisation being realised as an attribute certificate (Farrell and Housley, 2002). Through the digital signature of a certificate, its contents are protected against a modification. An attribute certificate as authorisation is specified in the following as a proxy credential. The fifth requirement is fulfilled by the specification of the data to be delegated or the partial identity of the customer in a proxy credential. A revocation is made through a protocol.
In order that no profile can be made about the customer by means of his proxy credentials, they are issued by a certification authority. If a customer should otherwise issue proxy credentials, he digitally signs them with his private key skU and can consequently be linked by way of his digital signature or its verification with the corresponding public key pkU. A certification authority, on the other hand, replaces the customer in the certification paths for the verification of a proxy credential. From the end service providers’ viewpoint, a certification authority examines on their behalf whether the personal data or the specified attributes pertain to this customer and whether he is authorised to delegate it. A proxy credential is similar to a Kerberos V5 ticket-granting ticket (Kohl and Neuman, 1993). However, it does not contain any revealing data about the identity of the customer.
Execution of Usage Control
The execution of usage control applies both to a disclosure of personal data as well as to its use. As a disclosure is done by anonymous credentials, which are issued by a certification authority, this executes customer deciding with the attestation for a delegation of personal data. Once the data is disclosed, neither a customer nor a certification authority has the possibility to control the use of this data. Disclosed data could therefore be used by a proxy for other purposes as often as desired.
In order that data is not delegated at will and its unrestricted use is detected, a certification authority delegates requested data of the customer only after submission of a valid proxy credential and in the form of an anonymous one-show credential to the authorised service provider. The incentive for a proxy not to use an anonymous one-show credential several times lies in the integration of a secret of the proxy in such a credential and its publication in the event of multiple usages (Camenisch and Lysyanskaya, 2001). For this purpose, DREISAM encodes the secret cryptographic key kProxy of the proxy into an anonymous one-show credential. An end service provider detects a multiple usage of an anonymous one-show credential and should reject the proxy’s associated access enquiry. It can also come to unlimited usage if a proxy receives an anonymous one-show credential for each application. A certification authority therefore logs its issuance of anonymous one-show credentials.
In addition to kProxy, restrictions for use are integrated into an anonymous one-show credential that corresponds to the rules of the customer on the use of delegated personal data. The restrictions apply to the validity of the credential, the service providers allowed and the naming of the service functions permitted as well as the specification as to whether the personal data can be transmitted.
The verification of a delegation of personal data and the logging of the delegation is carried out by means of a list. This list, which is referred to in the following as a delegation list, is similar to the presentation of an access control matrix according to (Harrison, Ruzzo and Ullmann, 1976). The relationship between the access object, the object of protection and the type of rights certainly forms the basis for an access decision. However, these three objects are not firmly specified in the case of the delegation of personal data. They are determined by the customer for each delegation in his delegation application through his privacy policy and the personal data concerned. In addition, an entry of a delegation list refers to the transaction of the customer with his proxy and to the owner of the data to be transmitted, i.e. the customer. In order that a certification authority can solve a dispute between customers and service providers concerning a delegation, the pertinent credential of the customer is stored in an entry. For monitoring the frequency of the data transmitted to a proxy, the number of the transmissions involved for each delegation is recorded. An entry of a delegation list comprises the following attributes:
a unique transaction identifier (TID),
the pseudonym pseudonym(U,CA) of the customer, under which he is known to the certification authority,
his personal data to be transmitted or its attributes,
his anonymous credential credential(attributes, pseudonym(U,CA),CA),
his privacy policy for the transmission and use of personal data,
the name of the proxies who have already received anonymous one-show credentials for this data
for each proxy, the number of the anonymous one-show credentials issued.
Phases of a Delegation and a Revocation of an Authori
The combination of access control with usage control forms the model for the DREISAM delegation mechanism. This section introduces the model and the DREISAM protocols in detail.
Participants and Assumptions
The customer, as owner of his data, his proxy, a certification authority and a (end) service provider participate in the protocols of a delegation of an authorisation and its revocation. The revocation of a customer’s anonymity or that of his proxy takes place unchanged according to the protocol from (Camenisch and Lysyanskaya, 2001) and therefore requires a de-anonymisation party.
It is assumed that there is a PKI for anonymous credentials according to (Camenisch and Van Herreweghen, 2002). The customer trusts the certification authority involved that it examines the pertainability of attributes to a person according to its certification policy and thereupon issues credentials. The communication of the customer with the service providers is unobservable as far as third parties are concerned through the employment of anonymity services. It is furthermore assumed that the communication partners mutually authenticate themselves before a communication. Should a participant in the protocol detect an error in the protocol sequence, he will immediately inform his communication partner and terminate the protocol sequence. It is moreover assumed that the personal data to be delegated has already been attested by a certification authority and the customer has the respective anonymous credential according to (Camenisch and Lysyanskaya, 2001).
Phases of the Delegation of an Authori
A delegation of an authorisation for the use of personal data or its attributes and their application is carried out in four phases with DREISAM. Phase A considers the application of a proxy for personal data from the customer. Phases B and C implement the usage control for a disclosure and use of personal data, whereby a certification authority regulates access to the customer data received. The aim of phase B is the issue and delegation of an authorisation for a proxy, so that he can use the respective customer data and prove its authenticity without knowledge of the secret key kU. Phase C aims at the transmission of the requested customer data to his proxy. In this phase, the decision to disclose the data concerned is made by the certification authority depending on the authorisation of the proxy. Since the protocol runs within the framework of a PKI with anonymous credentials, the data, in the form of an anonymous one-show credential with its conditions for use stemming from the customer’s privacy policy, will be linked to the proxy in the event of a positive decision. With Phase D, a delegation is concluded. This phase aims at the purpose-related use of delegated data according to the security regulations of the customer and thus at the realisation of the two models of utilisation control with DREISAM. Figure 6.3 shows the time flow of the phases with the parties involved.
Figure 6. The protocol phases of a delegation of an authorisation for the use of personal data or its attributes with DREISAM.
Revocation Phases of an Authori
The aim of a revocation of an authorisation is that the customer data delegated to a proxy cannot be further used. A certification authority should no longer delegate the data concerned to the proxy after a revocation and a service provider should reject an access enquiry of a proxy using this customer data. A revocation therefore applies to the proxy credentials as well as to the anonymous credentials issued for him. The three phases of a revocation are shown in Figure 6.4.
Figure 6. The revocation of an authorisation with DREISAM in its phases.
The aim of the first phase is the initiation of a revocation with the evidence that applicant is authorised for the revocation. The application is placed at the same certification authority which issued the proxy credential to be revoked. This certification authority subsequently examines whether the applicant is authorised for the revocation. This is the case when he is at the same time the customer upon whose application the authorisation was issued or is the certification authority that accredited the personal data concerned of the customer.
The aim of the second phase is the execution of the revocation of the proxy credential and the pertaining anonymous credentials of the proxy. Current revocation mechanisms for conventional attribute certificates such as revocation lists (Ford and Baum, 1997), are implemented together with the mechanism for anonymous credentials, i.e. the use of a dynamic accumulator according to (Camenisch and Lysyanskaya, 2002).
The aim of the third phase is the publication of the results of a revocation. The revocation of the proxy credential is published as part of the updated CRL. The accumulator is distributed as part of the public key pkCA of the certification authority, via its directory service for example. The prime numbers of the valid anonymous credential is published in the entry Eadd and those of the revoked anonymous credentials in the entry Edelete of the directory service.
Delegation of an Authori
The information flow and the interactions between the parties involved in a delegation are described in the following according to the four phases of the protocol.
Phase A: Data Request of a Proxy
Phase A is carried out by the protocol steps 1-3, which are shown in Figure 6.5. In the first step, the customer requests a service from a service provider, who is later his proxy. In order to pre-emptively counteract an undesirable linkage of his transactions, he faces his proxy under a pseudonym. In this case, the pseudonym is pseudonym(U,Proxy). In the second step, the proxy requests certain data of the customer. In the third step, the customer decides about its release. The identity manager of the customer either makes the decision automatically through a predetermined regulation or the customer decides explicitly about the release through an interaction with his identity manager. If the customer decides for the release of the requested data, continuation is made with phase B of the protocol.
Figure 6. Request of a proxy for personal data.
Phase B: Issue of an Authori
Phase B is carried out by steps 4-14 as shown in Figure 6.6. In the fourth step, the customer requests a proxy credential for his proxy from a certificate authority. With the request, the customer transfers his rules for the delegation and use of the specified data. The rules are specified in his privacy policy for this transaction with the proxy. To protect himself from a linking of profiles over several transactions, the customer faces the certification authority under a pseudonym. This pseudonym is specified in the information flow with pseudonym(U,CA). With regard to the proof of the customer that the data to be delegated belongs to him and takes place in the tenth step and the structure of the evidence protocol from the anonymous credential system (Camenisch and Lysyanskaya, 2001), the pseudonym is generated in the fourth step. This generation is optional and is dispensed with if the customer has already agreed on a pseudonym with the certification authority and wishes to establish a connection with an earlier transaction via the pseudonym. In the fifth step, the certification authority requests the customer for proof of the relationship between this data and himself.
Steps six to nine prepare the evidence in step ten. They deal with the proof that the anonymous credential of the customer for the personal-data concerned has not been revoked. As already described, dynamic accumulators are used for a revocation of anonymous credential. For the proof of a non-revoked credential, these use a witness which is specified in the eighth step as witness w(e(credential(attributes,pseudonym(U,CA))),CA). e(credential(attributes,pseudonym(U,CA),CA)) of the prime number of the anonymous credential thereby corresponds to the personal data attributes of the individuals with the pseudonym pseudonym(U,CA). The witness refers to an accumulator accumulator(v,CA), which is issued and maintained by the certification authority. Whether the witness has to be updated at all, i.e. whether the accumulator has changed, is examined in steps six to eight. In the sixth step, the current accumulator is requested by the issuing certificate authority. To simplify matters and without loss of generality, it is assumed that it is a question of the same certification authority which was also assigned the delegation. Due to the structure of the anonymous credentials according to (Camenisch and Lysyanskaya, 2001) and assuming that the customer only uses transaction pseudonyms and does not pass on any clear identifying data such as his personal identity number, the certification authority cannot trace back the transactions of the issue of an anonymous credential with the delegation of personal data to the same customer. Since the current accumulator is an integral part of the public key pkCA of the certification authority, in the seventh step, pkCA is sent to the customer. In the eighth step, it is examined whether the witness is up-to-date. This takes place by means of the verification of the accumulator received, which has a serial number for this purpose. If the witness is not in line with the current accumulator, then it is updated in the ninth step. The update (u,e(U,CA)) methods defined are used for this. If the witness is up-to-date, then the ninth step is omitted.
In the tenth step, the customer ultimately proves his relationship with the data to be transmitted by means of an anonymous credential. The ownership of the respective witness and the association of the prime number e(credential(attributes, pseudonym(U,CA),CA),CA) with the current accumulator is proven by a zero knowledge proof procedure. The possibility of the customer sending this prime number to the certification authority for calculating the witness of the presented credential does not apply. Otherwise, the certification authority can trace back the issuance of the anonymous credential with the delegation of the data concerned by way of the prime number to the same customer. In the case where the certification authority does not maintain the accumulator concerned, it must request it from the certification authority CA’ responsible in the optional eleventh step.
If the credential is valid, then the certification authority adds an entry into its delegation list in the twelfth step. The list is used as an access control list for the issue of credentials for proxies, i.e. which authenticate themselves with a proxy credential. The access rights correspond to the policy of the customer. The relationship between the entry on the delegation list and the proxy credential is produced by the unique transaction identifier TID. In step 13, the certification authority issues the requested proxy credential for the specified proxy and sends it as confirmation of the procedure to the customer. The proxy credential applies to the public key pkProxy of the proxy which the customer receives during the authentication of the proxy before the start of the delegation protocol and has transmitted to the certification authority with the application in the fourth step. The customer forwards the proxy credential to his proxy at the end of phase B.
Figure 6. Request of the customer for a proxy credential for his proxy.
Phase C: Delegation of Personal Data
Phase C is carried out by steps 15-23, whose sequence is shown in Figure 6.7. In step 15, the proxy requests an anonymous credential for the personal data of the customer, to which the proxy credential of the proxy applies. The proxy proves his authorisation to use this data by producing the respective proxy credential. This contains his public key pkProxy. The proxy proves his relationship with the proxy credential through the digital signature of the application. In addition, he agrees on a pseudonym with the certification authority, to which his anonymous credential is linked. The pseudonym is specified in Figure 6.7 as pseudonym(Proxy,CA). Whether the proxy uses a transaction pseudonym is not taken into further account, as this work concerns the protection of the privacy of a customer. In step 16, the certification authority examines whether the credential of the proxy is valid and whether a release of the data concerned is permitted according to the privacy policy of the customer. This takes place through the comparison of the proxy credential received with the respective entry on the delegation list. The relationship between the proxy credential and the entry is established via the TID. If the credential of the proxy is valid and he is thus authorised for the requested use of the personal data of the customer, then the certification authority creates an anonymous one-show credential with this data, links it to the pseudonym pseudonym(Proxy,CA) of the proxy and sends the anonymous one-show credential to the proxy. The delegation is added to the entry on the delegation list.
Steps 17-22 relate to the issue of the anonymous one-show credential for the proxy. The usage rights for the use of the data are entered in the credential under the restrictions field. According to the model of usage control, this can involve both obligations and conditions for the use of this data. A further feature of this credential is the fact that it is a question of an anonymous one-show credential. Multiple use of an anonymous one-show credential is detected by the service where the one-show credential is used for the second time (Camenisch and Lysyanskaya, 2001). The incentive for a proxy to use a one-show credential once at the most lies in the encryption of a secret of the proxy, e.g. his private skProxy key, in the credential and its disclosure, conditional on design, in the event of multiple uses. The hidden motive of this measure is to increase the damage of a proxy in a replay attack and thus prevent this type of attack. Further attributes of the credential are the customer data delegates, the pseudonym of the proxy, the name of the certification authority and the period of time in which the credential is valid. The period of time is specified by a commencement and termination date. Step 18 adds the prime number e(Proxy,CA) of the anonymous one-show credential to the accumulator accumulator(v,CA) of the certification authority and step 19 to the directory service entry Eadd. Step 20 updates pk’CA by the old accumulator being replaced by the new version. Step 21 publishes the updated directory service entry E’add and the new version of pk’CA. The credential produced is sent in step 22 to the proxy together with the new version of the public key pkCA. The key pkCA is sent in the form of a key certificate in order to secure its authenticity. Finally, the proxy produces the witness for this credential. The current accumulator is extracted from pk’CA. Step 23 is optional, but should be executed before the initial use of the credential. It is thereby assumed that the authenticity of the customer data can be shown by the proxy.
Figure 6. Enquiry of a proxy at a certification authority for personal data in the form of an anonymous one-show credential.
Phase D: Use of Personal Data
The final phase D is carried out by steps 24-33 (cf. Figure 6.8). In step 24, the proxy requests the service of the target service provider and agrees with him upon the pseudonym pseudonym(proxy,end service). The reason for generating this pseudonym corresponds to that of step 16. By means of this pseudonym, the proxy proves to the end service provider in step 32 that the access data, i.e. the customer’s data match his identity for this transaction. In step 27, the end service provider requests precisely this evidence. Steps 26 and 27 refer to the examination of whether the proxy’s anonymous credential was revoked. This examination takes place in step 32. An accumulator value accumulator’(v,CA) is calculated and compared with the current accumulator value accumulator(v,CA). The target service provider requests the current accumulator value from the certification authority in step 26 and obtains it in step 27. With steps 28 and 29, the proxy obtains the current accumulator value of the certification authority by means of which he examines in step 30 whether the witness value witness w(e(credential(attributes,pseudonym(Proxy,CA),one-show, restrictions,…)),CA) is up-to-date. For this, a witness value witness w’ is calculated. The witness value witness w is up-to-date if it is equal to witness w’. In this case, step 31 is omitted. Otherwise the old witness value w is replaced by w’. Step 32 finally conveys the evidence that the access data belongs to the proxy by proving the real-time of the anonymous credentials. On the result of step 32 and the allocation of rights in the end service provider’s access control list, in step 33, the proxy is either granted or denied access to the desired service and therewith the function of the service.
Figure 6. Use of the customer’s personal data by his proxy for authentication to an end service provider.
Revocation of an Authori
The revocation of an authorisation for the use of the customer’s personal data can be the result of various incidents. The revocation initiator varies depending on the event that occurred. A certification authority thus revokes a customer’s authorisations and his delegated authorisations if the customer data concerned can no longer be related to him. Examples of this are the loss of his driving license, a removal and the customer’s change of address involved, the change in family status and the membership of a health insurance fund. In this case, the data transmitted is no longer up-to-date and therefore no longer corresponds to the customer’s physical identity. Depending on the relation of the application, the customer’s access rights to services and with them those of his proxy can change. Furthermore, the authorisations are revoked if the customer proves to be a fraud. The case where a customer revokes delegated authorisations arises when the purpose of the delegation has been fulfilled before the planned termination or his proxy abuses the delegated data. It is assumed in the following that a customer revokes a delegated authorisation. In the other event, the customer is replaced in the protocol sequence by the revoking certification authority or the protocol begins with phase B when it is a question of the same certification authority.
In general, a revocation of an authorisation applies to the pertinent proxy credential and all the anonymous credentials that have been issued on the basis of this proxy credential. It is furthermore the aim that no identifying data on the customer accumulates by means of which his transactions and thereby his profiles can be linked without his agreement. This goal is only pursued, however, when the customer is honest.
Phase A: Initiation of a Revocation
Protocol steps one to eight form the initial revocation phase of an authorisation. Figure 6.9 presents their sequence. In the first step, the respective proxy credential is transmitted with the revocation request to the certification authority. With the proxy credential specification the certification authority is able to identify the delegation concerned and the pertaining anonymous one-show credentials. The clear identification of the entry on the delegation list takes place via the TID. In addition, the customer specifies with the application the desired point in time (revocationTime) at which the authorisation and the anonymous credentials connected should be revoked. The customer faces the certification authority under the pseudonym pseudonym(U,CA). The pseudonym is identical to the pseudonym that the customer has used for the request for an authorisation. This does not affect the customer’s privacy since the transaction for a revocation must be linked with the request transaction for an authorisation in order to be able to identify the anonymous credentials of the delegation.
In the second step, the certification authority selects the anonymous one-show credentials and the proxy from the delegation list. For this, the TID is used which, at the same time, is the unique identifier of an entry in the delegation list. However, before a revocation is made, the certification authority makes sure that the customer with the pseudonym pseudonym(U,CA) is authorised for this revocation. The customer is therefore requested in the third step to prove the relationship between himself and his personal data, to which the revoking authorisation refers. Analogous to phase B of the DREISAM delegation protocol, the following steps apply to the examination and, if necessary, updating of the witness value w(e(credential(attributes ,pseudonym(U, CA),CA)),CA) and the proof of the anonymous credentials credential(attributes, pseudonym(U,CA),CA) for the pseudonym pseudonym(U, CA).
Figure 6. The customer initiates the revocation of an authorisation for the use of delegated personal data.
Phase B: Revocation of Credentials
The result of steps nine to twelve is the revocation of the credentials for delegated authorisation, i.e. the credential of the proxy, and for the data delegated to the proxy, i.e. his anonymous one-show credentials. All steps are carried out by the certification authority (see Figure 6.10). Since a proxy credential is produced in the form of an attribute certificate according to (Farrell and Housley, 2002), the revocation mechanism of a PKI can be used (Ford and Baum, 1997). Since the development of revocation mechanisms is not the central focus of this work, a Certificate Revocation List (CRL) is used. This revocation mechanism is not necessary for the basic functionality of the protocol and can be replaced by alternative mechanisms. In the ninth step, the certification authority adds the respective proxy credential to the revocation list. In the tenth step, all anonymous one-show credentials of a proxy that were issued on the strength of the revoked proxy credential in the ninth step are revoked. The following steps are executed for each of these anonymous proxy credentials:
Step 10.1: The prime number e of the anonymous one-show credential credential(attributes,pseudonym(proxy,CA),one-show,…, CA) is removed from the current accumulator accumulator(v’,CA) of the certification authority.
Step 10.2: The prime number e is removed from the directory service entry Eadd of the prime numbers of valid anonymous credentials and
Step 10.3: added into the directory service entry Edelete of the revoked anonymous credentials.
In the eleventh step, the certification authority updates its accumulator and subsequently adds it to his public key pkCA. If all the protocol steps of phase B have been correctly executed, then the delegation entry on the delegation list is marked as revoked with the point in time of the revocation (revocationTime). Later requests of a service for personal data for which the revoked proxy credential is used are seen as invalid.
Figure 6. The certification authority performs the revocation of the proxy credential and the pertaining anonymous credential.
Publication of the Revocation Results
The last phase publishes the revocation in steps 13-17 (see Figure 6.11). Step 13 releases the updated directory service entries for publication. A consistent database of the public directory service is ensured through the simultaneous publication of these values. In response to the initiator of the revocation, the certification authority returns the result of the revocation together with the up-to-date accumulator as part of pkCA. The result of the revocation is revoked in the event of success and otherwise denied. Step 15 is then carried out if the anonymous credential for the customer’s data has been revoked. In this case, the customer updates the witness value for this credential depending on the accumulator received from step 14. Step 16 sends the result of the revocation to the proxy so that he can update his witness values for the relevant anonymous credentials in step 17.
Figure 6. Publication of the revocation results.
Security Properties of
The assumption which has to been proven is that DREISAM (a) does not disclose any personal data of the customer, (b) the transactions of a customer cannot be linked, and (c) a proxy is only able to use customer’s personal data according to the purpose of the corresponding business process. Cases (a) and (b) refer to a controlled disclosure of personal data; case (c) refers to a prevention of abuse. Additionally, disputes must be resolvable to clarify liability.
Controlling Disclosure of Personal Data
Since DREISAM makes use of the identity manager iManager, a user is able to disclose his personal data as partial identities relating to the service provider and the service as well as stored personal data is the protected store of the iManager. Non-linkability of transactions is achieved by using a pseudonym only for one transaction and by using anonymous credentials. Non-repudiation of a delegation is achieved by the log in the delegation list of the corresponding CA. Non-repudiation of a service use is achieved by showing a credential and by the access log of the corresponding service provider. As the investigation on identity management systems, especially of IBM idemix, shows, a delegation of anonymous credentials implies that a customer lose control about his identity, DREISAM enables a customer to delegate specific personal data to a proxy by using proxy credentials. This empowers a customer to delegate least attributes necessary for the purpose of a proxy. The de-anonymisation mechanism of IBM idemix is used for revealing the identity of a customer or his proxy in case of fraud.
Preventing Abuse of Disclosed Personal Data
If a service provider grants access to his service to a proxy whose credential is not specified for this service, the service provider would grant access to an unauthorised party. This contradicts with the security interests of end service providers and his motivation to use an access control. From this contradiction it follows that end service providers will follow the restrictions of an anonymous one-show credential. Double-spending of a one-show credential is detected, if the end service provider checks on-line with a certification authority whether the shown credential has already been used. In the off-line case, such a double-spending cannot be prevented but it can be detected afterwards by the same way as in the on-line case. With respect to undesired re-delegation of a proxy credential, the certification authority would issue an anonymous credential for another party which is not mentioned in customer’s policy. It follows that this certification authority does not follow the certification policy and is not trustworthy. This contradicts the assumption of a trustworthy certification authority.
Solving Disputes
Disputes between a customer and a proxy relating to the use of personal data may occur in two cases. A proxy uses a delegated credential of the customer and denies its use or a criminal customer uses a credential in the name of a proxy and denies its use. A dispute is solved by a certification authority based on the transcript of a delegation transaction and the log of the corresponding end service provider with respect to the access queries. The certification authority compares the transcript of the credential use with the transcript of issued credentials to identify the identity of the cheater.
Applying
33 / 38 |