Title: ON MULTI-STAGE BUSINESS PROCESSES

The iManager does not consider multi-stage business processes. Applying the authentication protocol of the iManager leads to the situation as shown in Figure 5.16. Steps 1-9 are the same. The difference is in step 10. In order to use customer’s personal data of his partial identity B, his proxy has to be able to digital sign a message with customer’s private key skP_IB. Therefore, the customer delegates skPI_B it to his proxy in step 10. But by delegating skPI_B, the customer loses control on the use of his partial identity B.

Figure 5.16 Authentification of a customer by his partial identity in a business process with proxy.

Security Properties of

The iManager has been developed for preserving privacy in single-stage business processes. This identity manager empowers his customers to control the access on personal and identifying data by disclosing them via partial identities. The evaluation of its protocols and their application on multi-stage business processes shows the following properties of the iManager:

1. Secure data storage: Personal data and all partial identities of a customer are stored in the protected storage of his personal mobile device. Only the iManager has access to it.

2. Situation-dependent disclosure of personal data: The iManager recognises a situation by the current service, service provider, the requested data, and the current partial identity of a customer. A customer discloses personal data and therefore giving access to his data by selecting a partial identity with respect to a situation. Only the personal data of the selected partial identity will be given to the requesting service provider.

3. Unlinkability of transactions: The content of a partial identity is defined by a customer. That means that he is able chose whether identifying data is part of a partial identity. Since pseudonyms are part of a partial identity, a customer is able to use services with different identifiers. If two disjunctive partial identities are used for two transactions, these transactions and customer’s profiles and service providers seem to be independent with respect to the same customer. But if a customer uses a partial identity also for other transactions, these transactions can be linked by the public key pkPI_A and the digital signature of the customer (cf. to step 8 in the authentication protocol).

4. Non-repudiation of customer’s transactions: In step 8 of the authentication protocol, a customer shows the association of his certifies partial identity by using his correspondent private key skPI_A for a digital signature. Since a credential is an X.509 attribute certificate issued by a CA, a service provider verifies the authenticity of a partial identity by verifying this credential. By the trust relationship in a PKI to the CA and the digital signature of the CA and of the customer, a transaction is bound to a specific customer.

5. Revoking customer’s anonymity in case of fraud: A CA revokes the anonymity of a customer in case of fraud. As shown in the certification protocol, a CA knows the identity of a customer by verifying the relationship of a partial identity to a customer in step 2.

The iManager does neither support storing personal data externally nor a delegation of personal data or partial identities. Consequently, there is no usage control on disclosed personal data. As shown by the application of the authentication protocol on multi-stage business processes, a customer will lose the control on his delegated identity, if he delegates it to a service provider for further use. This service provider is able to impersonate the customer and to trace his past transactions in which the customer has used this partial identity.

Conclusion

The iManager aims primarily at a usable security tool for mobile security novices in order to preserve their privacy by controlling the disclosure of their personal and identifying data. A customer prevents an undesired identification, data collection and linking of profiles by using disjunctive partial identities, under the presumption that two transactions do not need the same or identifying data of a customer. But in multi-stage business processes, a customer will lose control on his delegated partial identities. Linkability and abuse by impersonation is the consequence.

Anonymous Credentials:

IBM idemix (identity mix) (Camenisch and Van Herreweghen, 2002) is an anonymous credential system that is based on protocols for anonymous credentials according to [Cam2001] and requires a PKI. Through the use of anonymous credentials, in his authentication towards service providers and certification authorities a customer is known exclusively by the pseudonym used and the attribute attested by the credential or the data disclosed. The system is used for the identity management system of the EU project Privacy and Identity Management for Europe (PRIME) (Camenisch, Shelat, Sommer, Fischer-Hübner, Hansen, Krasemann, Lacoste, Leenes and Tseng, 2005).

Transactions where the customer uses various pseudonyms appear separately from one another to the customer’s communication partner. Even a certification authority that issues a credential for a certain pseudonym does not recognise the same customer again if he verifies the possession of this credential towards the certification authority. The certification authority only knows that the customer possesses a credential with the proven attribute with the applied pseudonym and that this credential was issued by itself. A customer can determine himself with the authentication which personal data of a credential should be disclosed. In addition, IBM idemix has accountability mechanisms that allow a disclosure of a customer’s identity or the pseudonym of a customer under certain conditions.

IBM idemix is described in the following in excerpts from (Camenisch and Lysyanskaya, 2001; Camenisch and Van Herreweghen, 2002) on the basis of its basic protocols. It is then subsequently examined and evaluated with regard to privacy protection, particularly for a delegation of personal data.

The Basic System

The participants in an idemix-PKI are customers who receive credentials and identify themselves, service providers and certification authorities who examine and issue the credentials and a de-anonymisation provider who discloses the identity ort he pseudonym of a customer under certain conditions. A customer can therefore receive a credential from a certification authority and identity himself to a service provider with this credential. A credential is always linked to a pseudonym that was previously agreed upon between the customer and the respective certification authority. A credential can contain certain data of the customer, whereby the customer can determine himself on verification of a credential which certified data or its attributes are disclosed.

Initialisation and Assumptions

The registration of pseudonyms as well as the issue and examination of credentials take place by interactive protocols between the customer and the respective service provider. A customer U possesses a secret symmetric key kU to which his entire pseudonyms and anonymous credentials are linked. Certification authorisations and service providers each possess an asymmetric cryptographic key pair (pkX, skX) where X stands for the name of the service provider. A certification authority uses its private key skCA for issuing a credential. This credential can then be examined with the pertaining public key pkCA. For the verification of a credential, the customer uses the public key pkSP in the protocol with the service provider SP. IBM idemix assumes the following:

1. The customer does not trust any service provider not to generate a profile about him and without his consent. 

2. Private communication relationships between customer and service provider are reached as far as third parties are concerned by the use of anonymity services. 

3. A service provider authenticates himself towards the customer for each communication. 

4. Each communication between customer and service provider takes place confidentially, i.e. it is encrypted. 

5. If an error occurs during the course of a protocol by a protocol participant, then he informs the other protocol participant and then terminates the protocol. 

In the following, the principle of the protocols of the IBM idemix anonymous credential system is described in order to subsequently identify its security properties for use in business processes.

Issue and Verification of an Anonymous Credential 

The issue of an anonymous credential for a customer and its authentication with an anonymous credential takes place in four steps, whose course is shown in Figure 5.17. In the first step, customer U establishes a connection with the certification authority CA and agrees with it on a pseudonym(U,CA). If the customer is authorised to receive the requested credential to the data attributes, then the CA issues this credential by digitally signing the relation between the data attributes and the customer or his pseudonym(U,CA). The certification authority subsequently sends the resultant credential credential(attributes, pseudonym(U,CA),CA) to the customer U. The customer U can now identify himself with this credential towards the service provider SP. He previously agrees on a further pseudonym pseudonym(U,SP) with the service provider SP. The generation of this pseudonym is necessary to be able to verify the relationship between the pseudonym pseudonym(U,SP) and the credential credential(attributes, pseudonym(U,CA),CA). For this, a test value was calculated with the issue of credential for the pseudonym pseudonym(U,CA), which is again used for a credential verification and shows the relationship to the pseudonym pseudonym(U,SP). Verification of the credential takes place in the fourth step through a zero-knowledge proof. Customer U proves to the service provider SP that he is in possession of a valid credential credential(attributes,pseudonym(U,CA),CA), without disclosing the data of the credential and the secret symmetric key kU. In concrete terms, customer U proves the following:

1. He is in possession of a digital signature of the certification authority CA that refers to the maintained data or attributes of a customer with the pseudonym pseudonym(U,SP).  

2. He knows the secret key kU on which the pseudonyms pseudonym(U,CA) and pseudonym(U,SP) are based.

Figure 5.17 Sequence of an issue and usage of anonymous credential in the IBM idemix basic system.

The customer does not send the anonymous credential in plain text for verification but a cryptographic commitment (Brassard, Chaum and Crépeau, 1988). The confidentiality of the credential data is therefore ensured with a verified linking of this data to the assertion to be proven of the anonymous credentials. Together with the use of zero-knowledge proofs, IBM idemix prevents several verifications of the same credential being able to be linked together and with the issue of this credential of service providers and certification authorities. This is also the case when all service providers and certification authorities pool their profiles over all transactions. The customer is therefore only known to the service providers for the verification of a credential by the used pseudonym and the proven assertion of the credential. If the customer uses a new pseudonym for each transaction, then, under the previously specified assumptions, he is anonymous.

Extensions of Anonymous Credentials in the