Title: ON LOYALTY PROGRAM WITH DELEGATION OF RIGHTS ON CUSTOMER’S DATA

The application of DREISAM in order to prevent linkability of customers’ profiles by merchants in this case study has two stages:

1. Premise: To prevent linkability when showing a loyalty card, anonymous credentials are used for realizing a loyalty card.

2. Unlinkable Delegation: DREISAM delegation protocol is used for delegating an access right in order to read a specific entry of customer’s profile at the loyalty program provider.

The application of the first stage is shown in Figure 6.12. In this case study, a customer has solely one loyalty card of one loyalty program. By using anonymous credentials, a customer is able to use his loyalty card with different pseudonyms and to hide identifying data, e.g. his card number, if it is not necessary for the service. If the card number is needed, e.g. to deposit premium points on customer’s profile, the card number is hidden in the showing protocol and it is sent to the loyalty partner provider via the merchants by means of an encrypted card number: enc(pkLoyalty program provider, Card ID || pseudonymSupermarket). If the encrypted card number, the cipher text, is in every transaction the same, merchants and the CA are able to trace this customer by this cipher text. To avoid linkability by the encrypted Card ID, the cipher text has to be randomised each time the loyalty card is going to be delegated. This can be achieved by using the encryption scheme of the payment protocol family iKP (Bellare, Gray, Hauser, Herzberg, Krawczyk, Steiner, Tudsik and Waidner, 1995). The plain text, Card ID and the associated pseudonym which the customer has used at the supermarket, is encrypted with a one-show random number (SALT) by an XOR-operation and finally asymmetrically encrypted with pkLoyalty program provider. The loyalty program provider does not need to know SALT in advance, since he is able to reconstruct it after he has decrypted enc(pkLoyalty program provider, Card ID || pseudonymSupermarket). So, only the loyalty program provider is able to encrypt the card number by his private key skLoyalty program provider and to know the relationship between pseudonyms of a customer and his unique card number which is used to identify the customer and the data base record of his profile.

The transactions in Figure 6.12 cannot be traced back to the customer by the merchants, if there is no intersection in the disclosed data. The customer uses different pseudonyms 4711’0815, 1024, and Abcd’23 in combination with his loyalty card as an anonymous credential. Since an anonymous credential hides its data, it is shown in Figure 6.12 in brackets.

Figure 6. Applying anonymous credential for a loyalty card to prevent linkability if showing a loyalty card.

The principle of an unlinkable delegation of rights by using DREISAM is shown in Figure 6.13. A certification authority extends the model with regard to the DREISAM model. The role of a certification authority is taken by a new organisation according to the model, even thought the loyalty program provider could also be in the role of the CA. The suggestion is to divide the loyalty program provider and the CA in two organisations. Firstly, the role of a CA is not the core competence of a loyalty program provider. Secondly, other loyalty program providers would probably not accept a CA who belongs to a competitor.

The trust relationships between the participants are as follows: 

1.  The loyalty program provider trusts the CA that the CA certifies the relationships between customers and loyalty card as well as between merchants and proxy credentials according to her certification policy.

2. Merchants trust the loyalty program provider that he issues valid loyalty cards.

3. Customers trust the loyalty program provider that he manages customers’ profiles confidentially and discloses them solely if the corresponding customer has given his authorisation and if this authorisation is valid. Furthermore, customers trusts the CA that she issues proxy credentials according to her certification policy.

The customer uses the pseudonym klf2007 in order to remain unlinkable between the transaction with the insurance company and those with the pharmacy in the past. After the request of a merchant (insurance company) for accessing the profile pharmacy of the customer (phase A of DREISAM), the customer requests the corresponding authorisation for the insurance company at a certification authority. The result of step two, which is phase B of DREISAM, is the authorisation for the insurance company realised by a proxy credential. A customer has to show that his pseudonym klf2007 belongs to the pseudonym used at the supermarket (4711’0815). Showing this relationship may not lead to disclose the customer’s pseudonym with regard to the supermarket to the CA. Otherwise the CA is able to identify customer’s profile at the supermarket. Latter can be achieved by using a key-oblivious verifiable encryption scheme similar to (Camenisch and Lysyanskaya, 2001). Showing the relationship between two pseudonyms in a PKI with anonymous credentials means to show that they are both based on the same secret key kCustomer. This authorisation is forwarded in step three. Step four represents phase C of DREISAM: the insurance company, a proxy of the customer concerning the access on customer’s profile at the loyalty program provider, requests the copy of customer’s loyalty card by showing his corresponding proxy credential as the authorisation for this copy. By getting the copy of customer’s loyalty card, the insurance company is allowed to access customer’s supermarket profile in step five. Step five represents phase D of DREISAM. The relationship between the pseudonym klf2007 and the Card ID is again introduced to the loyalty program provider by the encrypted Card ID together with a random number nonce: enc(pkLoyalty program provider, Card ID || pseudonymSupermarket)

Figure 6. Applying DREISAM for an unlinkable delegation of access right in principle.

Conclusion

DREISAM extends identity management by a usage control mechanism. It is now possible to specify a desired use of delegated personal data according to the privacy interests of customers. A customer remains thereby unlinkable so that he is further on able to decide on the access on his personal data. DREISAM makes thereby use of the identity manager iManager in combination with the anonymous credential system IBM idemix. However, a customer is able to specify the desired use of his data by an authorisation; he cannot control the enforcement of this authorisation, since he has no access on the information system of participating certification authority and service providers.

As shown in the case study Loyalty Program, DREISAM prevents profiling if a customer delegates access rights on his profiles, which are externally stored, to service providers. A loyalty program provider benefits from preventing undesired profiling of customers’ by using DREISAM in combination with identity management, since the loyalty program provider is the only provider who knows all profiles of each customer in a loyalty program, even if customers’ delegate access rights to loyalty program partners for personalised services.