1. Markulf Kohlweiss, Microsoft Research markulf@microsoft.com Microsoft Research, May 2010 1

2. User 2

3. 3445 7455 4397 3534 Personal data Location data age alice@email.com Access credentials Book purchases Political orientation Hobbies / obsessions Behavioral data Favorite news site UserService Providers Anonymous Credentials Laws of Identity 1. User Control and Consent 2. Minimal Disclosure for a Constrained Use Kim Cameron 3

4. 4 AliceBob Behavioral data Personal data Anonymous credentials Anonymous e-coins Anonymous data unidentified location data age>18 Someones e-book purchases Interactions using unlinkable pseudonyms Anonymous data I need to know something right? Have you subscribed? Are you old enough? I want to be anonymous.

5. User Identity Provider Service Providers I issue a digital identity card real human, subscription, age > 18, pseudonym, encrypted identity name surname age... unlinkable I want to selectively reveal data. I don’t want my actions to be linked. [Chaum85, Brands99, CL01] Camenisch, Lysyanskaya, 2001 5 5

6. 6 Alice Bob Behavioral data Personal data Access credentials I don’t want Bob to know what I am doing. CC number: 3465 7568 9867 3254 IP address: 207.46.197.32 Hello Alice. Use my service. I promise I won’t watch. Really!

7. CC number: 3465 7568 9867 354 User Service Provider I want to selectively and privately learn information Learns nothing about Alice’s query, except maybe that authorized (may include private payment) except maybe that authorized (may include private payment) IP address: 207.46.197.32 Benny Chor, Eyal Kushilevitz, Oded Goldreich, Madhu Sudan [Rabin, Chor et al.] 7

8.  Anonymity and Private Access needs to be balanced.  many extensions to basic system [CL02, CCS06, PKC09, JCS10,AIR01].  Will privacy protocols be less prone to errors than conventional protocols (e.g. key agreement)?  What about other privacy enhancing protocols? (RFID Authentication [LBV09], Oblivious Transfer [AIR01) Lee, Batina,.Verbauwhede 2009 Camenisch Lysyanskaya 2002 Aiello, Ishai, Reingold, 2001 8

9.  Until 1980s: Cryptography as a “craft”  design, bug, design...  when to stop?  More recently: Cryptography as a “science”  formalized goals: attacker model, security definitions  explicit assumptions: security of (ideal) building blocks, mathematical assumptions,  construction and rigorous analysis 9

10.  Cryptographic Definitions  Ideal functionality based definitions  Anonymous Credentials  U-Prove  Delegatable Anonymous Credentials  Private Computation  Location-based Services  Priced Oblivious Transfer  Privacy Preserving Smart Metering  Conclusions  Two approaches to data minimization 10

11. Description of building blocks, and specification of desired result 11

12. Alice & Others Bob Probabilistic Public-key Encryption 12

13.  Define security negatively:  Secure if no realistic attacker has advantage > ε.  Game between attacker and challenger  IND-CPA and IND-CCA games pk m 0, m 1 Enc(pk, m b ) b * = b 13

14.  Define security positively: Behaves as ideal protocol, except with probability ≤ ε.  Defined using ideal functionality, and proven by simulation  Adversary plays standardized game: goal is to make simulation fail with probability > ε 14

15. Alice & Others Environment Interface Network Interface Bob 15

16. Alice & Others Bob Environment Interface Network Interface Init:Dec: Enc: 16

17. Environment Interface Network Interface 17

18.  Zero-knowledge  Soundness 18 Verifier Prover Environment Interface Network Interface

19. Verifier Zero-knowledge proof protocol Prover Environment Interface Network Interface 19

20. Proof π common reference string Prover Verifier Environment Interface Network Interface / random oracle 20

21. Sender i Receiver mimi select i th message Environment Interface Network Interface 21

22. Bob Alice Environment Interface Network Interface 22

23. Gaining access to services without revealing ones identity 23

24.  Cryptographic Definitions  Ideal functionality based definitions  Anonymous Credentials  U-Prove  Delegatable Anonymous Credentials  Private Computation  Location-based Services  Priced Oblivious Transfer  Privacy Preserving Smart Metering  Conclusions  Two approaches to data minimization 24

25. 25 AliceBob Behavioral data Personal data Anonymous credentials Anonymous e-coins Anonymous data unidentified location data age>18 Someones e-book purchases Interactions using unlinkable pseudonyms Anonymous data I need to know something right? Have you subscribed? Are you old enough? I want to be anonymous.

26.  Identity as a proxy to check credentials  Username decides access in Access Control Matrix  Sometime it leaks too much information  Real world examples  Tickets allow you to use cinema / train  Bars require customers to be older than 18 ▪ But do you want the barman to know your address? 26

27. Alice Identity Provider Service Providers I issue a digital identity card name surname age... I want to selectively reveal data. I don’t want my actions to be linked. (x, y) such that x contains age > 18? y = [ age > 18 ] (real human subscriptionpseudonym encrypted identity) x = Based on zero-knowledge proofs unlinkable Cannot learn anything beyond age 27

28.  Multi-show (Camenisch & Lysyanskaya)  Random oracle free signatures for issuing (CL)  Blinded showing ▪ Prover shows that he knows signature on attributes with some property.  Cannot link multiple shows of the credential  More complex  Single-show credential (Brands & Chaum)  Blind the issuing protocol (blindly sign a commitment  Show the signature on commitment in clear ▪ Prover shows that commitment contains attributes with some property.  Multiple shows are linkable – BAD  Protocols are simpler – GOOD 28

29.  Cryptographic preliminaries  The discrete logarithm problem  Schnorr’s Identification protocol ▪ Unforgeability, simulator, Fiat-Shamir Heuristic ▪ Generalization to representation  Showing protocol  Linear relations of attributes  Issuing protocol  Blinded issuing 29

30.  Assume p a large prime  (>1024 bits—2048 bits)  Detail: p = qr+1 where q also large prime  Denote the field of integers modulo p as Z p  Example with p=7  Addition works fine: 1+2 = 3, 3+5 = 1,...  Multiplication too: 2*2 = 4, 2*4 = 1,...  Exponentiation is as expected: 2 2 = 4  Choose g in the multiplicative group of Z p  Such that g is a generator  Example: g=3(3 ∗ 3 = 9-7 = 2)  Subgroup: g=2(2*2*2=1) 0123456 326451 30

31.  Exponentiation is computationally easy:  Given g and x, easy to compute g x  But logarithm is computationally hard:  Given g and g x, difficult to find x = log g g x  If p is large it is practically impossible  Related DH problem  Given (g, g x, g y ) difficult to find g xy  Stronger assumption than DL problem 31

32.  Efficient to find inverses  Given c easy to calculate g -c mod p ▪ (p-1) – c mod p-1  Efficient to find roots  Given c easy to find g 1/c mod p ▪ c (1/c) = 1 mod (p-1)  Not the case N=pq (RSA security)  No need to be scared of this field. 32

33. Public: g, p Knows: x Knows: y=g x P->V: g w = a (first message) V->P:c (challenge) P->V: cx+w = r (response) Check: g r = y c a g cx+w = (g x ) c g w Random: w Alice (Prover) Bob (Verifier) 33

34. 34

35. 35

36. 36

37.  Schnorr’s protocol  Requires interaction between Alice and Bob  Bob cannot transfer proof to convince Charlie ▪ (In fact we saw he can completely fake a transcript)  Fiat-Shamir Heuristic  H[∙] is a cryptographic hash function  Alice sets c = H[g w ]  Note that the simulator cannot work any more ▪ g w has to be set first to derive c  Signature scheme  Alice sets c = H[g w, M] 37

38. 38

39. Alice (Prover) Bob (Verifier) Public: g, p Knows: x 1,..., x l Knows: h = g 1 X1 g 2 X2... g l Xl P->V: ∏ 0<i<l g w i = a (first message) V->P:c (challenge) P->V: r 1,..., r l (response) Check: (∏ 0<i<l g i r i ) = h c a l random: w i r i = cx i +w i Let’s convince ourselves: (∏ 0<i<l g i r i ) = (∏ 0<i<l g i x i ) c (∏ 0<i<l g w i ) = h c a 39

40. Public: g, p Knows: x 1,..., x l Knows: h = g 1 X1 g 2 X2... g l Xl P->V: ∏ 0<i<l g w i = a (first message) V->P:c (challenge) P->V: r 1,..., r l (response) Check: (∏ 0<i<l g i r i ) = h c a l random: w i r i = cx i +w i Let’s convince ourselves: (∏ 0<i<l g i r i ) = (∏ 0<i<l g i x i ) c (∏ 0<i<l g w i ) = h c a Alice (Prover) Bob (Verifier) 40

41. Alice (Prover) Bob (Verifier) Public: g, p Knows: x 1,..., x l Knows: h = g 1 X1 g 2 X2... g l Xl P->V: ∏ 0<i<l g w i = a (first message) V->P:c (challenge) P->V: r 1,..., r l (response) Check: (∏ 0<i<l g i r i ) = h c a l random: w i r i = cx i +w i Let’s convince ourselves: (∏ 0<i<l g i r i ) = (∏ 0<i<l g i x i ) c (∏ 0<i<l g w i ) = h c a 41

42. 42

43. Alice Identity Provider Service Providers I half-blindly issue a digital identity card I want to selectively reveal data. I don’t want my actions to be linked. Com(name, surname age...) Based on blind signatures unlinkable Cannot learn anything beyond age (x, h) such that x contains age > 18? x = attributes and opening for h 43

44. 44 Identity Provider Service Providers I issue a digital identity card name surname age... unlinkable Carol 1 Alice 2 2 unlinkable

45. Service Providers Carol Alice pk A sk S pk A sk B pk C sk A pk A sk B pk C sk A fresh nonce sk C using signatures: 45

46. Randomize Proofs Size of randomized proofs stays constant, no blowup 46

47.  Completeness, Soundness, Zero-knowledge  New property: Randomizability  Randomized proof looks like freshly generated proof  Construction for NP [GOS06] and efficient applications [GS08] 47 randomize Groth, Ostrovsky, Sahai Groth, Sahai

48. randomizemaul Dolev, Dwork, Naor 48

49. Service Providers Carol 1 Alice 49

50. Service Providers 11 2 2 maul & randomize 1 Carol Alice 50 maul & randomize

51.  Attribute based access control  Federated identity management  Electronic cash  (double spending)  Privacy friendly e-identity  Id-cards & e-passports  Multi-show credentials! 51

52. Obtaining a service without revealing behavioural information 52

53.  Cryptographic Definitions  Ideal functionality based definitions  Anonymous Credentials  U-Prove  Delegatable Anonymous Credentials  Private Computation  Location-based Services  Priced Oblivious Transfer  Privacy Preserving Smart Metering  Conclusions  Two approaches to data minimization 53

54. 54 AliceBob Behavioral data Personal data Access credentials I don’t want Bob to know what I am doing. CC number: 3465 7568 9867 3254 IP address: 207.46.197.32

55. 1 -out-of-n oblivious transfer Naor, Pinkas Camenisch, Neven, shelat 55

56.  Security properties 1. Location privacy 2. Database secrecy 3. Service privacy... 56

57.  Security properties 1. Location privacy 2. Database secrecy 3. Service privacy... 57

58. CC number: 3465 7568 9867 3254 BuyerVendor Initial deposit Learn content of e-book (nothing more) Learn commitment to new deposit := deposit - price of e-book (protocol hides item and price) IP address: 207.46.197.32 Aiello, Ishai, Reingold, 2001 [AIR01] 58

59. (m 1, p 1 )... (m n, p n ) p 1... p n dep access? i check: dep-p i ≥ 0 b mimi if b=1, dep:=dep-p i else abort Initialization phase Transfer phase Buyer Vendor 59

60. Meter (Electricity, time) (Gas, time) User Utility Provider Policy Dynamic rates per ½ hour Fixed plan of rates (Non-linear rates -- taxation) Electricity readings per ½ hour Payment Bill 60

61.  USA: Energy Independence and Security Act of 2007  American Recovery and Reinvestment Act (2009, $4.5bn)  EU: Directive 2009/72/EC  UK: deployment of 47 million smart meters by 2020 BUT: “The Dutch First Chamber considers the mandatory nature of smart metering as an unacceptable infringement of citizens’ privacy and security” 61

62.  Meter readings are sensitive: Toward Technological Defenses Against Load Monitoring Techniques Thomas Nicol, Student Member, IEEE, Thomas J. Overbye, Fellow, IEEE 62

63. Open Readings { …, (i, cons i, open i ) … } Blind Readings {… i, C i = g cons i h open i, …} sign Prove Bill =  i rate i  cons i Open’ =  i rate i  open i Verify (Verify all signatures)  i C i rate i = g Bill h Open’ User Bill =  i rate i  cons i Meter Provider Reveal!Hide! ACCEPT or REJECT rate cons Commitments ?: (1) Hiding (2) Binding 63 Blind readings & Bill, Open’

64.  Proofs & definitions in the UC model  Ideal functionality defining metering & billing.  Proof that our protocols are indistinguishable from the ideal functionality (+ simulator).  Proven under standard assumptions about primitives: ▪ Commitments, signatures, ZK proofs 64

65. 65 Alice Bob Behavioral data Personal data Anonymous credentials Anonymous e-coins Anonymous data unidentified location data age>18 Someones e-book purchases Interactions using unlinkable pseudonyms Anonymous data I need to know something right? Have you subscribed? Are you old enough? I want to be anonymous.

66. 66 Alice Bob Behavioral data Personal data Access credentials I don’t want Bob to know what I am doing. CC number: 3465 7568 9867 3254 IP address: 207.46.197.32

67. 3445 7455 4397 3534 Personal data Location data age alice@email.com Access credentials Book purchases Political orientation Hobbies / obsessions Behavioral data Favorite news site UserService Providers Anonymous Credentials Laws of Identity 1. User Control and Consent 2. Minimal Disclosure for a Constrained Use Kim Cameron 67

68. 68

69.  Propose to add noise to bill.  Justify use of noise using differential privacy  Maintain hidden account of noise contributions  Prove that account always positive  Negative noise = rebate  Support deposits  Compatible with anonymous e-cash: anonymous settlement of bill without ever revealing it. 69

70. Verify signatures and proof  i C i rate i C noise = g Bill h Open’ Bill =  i rate i  cons i + noise Open Readings { …, (i, cons i, open i ) … } Blind Readings {… i, C i = g cons i h open i, …} sign Prove Bill =  i rate i  cons i Open’ =  i rate i  open i Blind readings C i & {Bill, Open’} sig User Bill =  i rate i  cons i Meter Provider Reveal!Hide! ACCEPT or REJECT 70

71. 71