CRYPTOGRAPHIC PROTOCOLS: PRACTICAL REVOCATION AND KEY ROTATION

Transcription

1 #RSAC SESSION ID: CRYP-W04 CRYPTOGRAPHIC PROTOCOLS: PRACTICAL REVOCATION AND KEY ROTATION Adam Shull Recent Ph.D. Graduate Indiana University

2 Access revocation on the cloud #RSAC sk sk Enc Pub Sym pk k 1, Enc k1 f1 Enc Pub Sym pk k 2, Enc k2 f2 Enc Pub Sym pk k 3, Enc k3 f3 sk 2

3 Access revocation on the cloud #RSAC sk Enc Pub Sym pk k 1, Enc k1 f1 Enc Pub Sym pk k 2, Enc k2 f2 Enc Pub Sym pk k 3, Enc k3 f3 sk 2

4 Revocation using proxy re-encryption #RSAC Enc Pub Sym pk k 1, Enc k1 f1 Enc Pub Sym pk k 1, Enc k1 f1 Enc Pub Sym pk k 2, Enc k2 f2 Proxy re-encrypt from pk to pk Enc Pub Sym pk k 2, Enc k2 f2 Enc Pub Sym pk k 3, Enc k3 f3 Enc Pub Sym pk k 3, Enc k3 f3 3

5 Key-scraping attack #RSAC Enc Pub Sym pk k 1, Enc k1 f1 Enc Pub Sym pk k 2, Enc k2 f2 Enc Pub Sym pk k 3, Enc k3 f3 The symmetric keys for the files are not changed! A revoked user may have stored k 1, k 2, and k 3 Enc Pub Sym pk k 1, Enc k1 f1 Enc Pub Sym pk k 2, Enc k2 f2 Enc Pub Sym pk k 3, Enc k3 f3 4

6 The symmetric key must be changed! #RSAC Decrypt with old key, encrypt with new key Requires trusted re-encryptor and takes two full passes for re-encryption Encrypt existing ciphertext with new key Decryption takes one full pass for each previous re-encryption Key-homomorphic pseudorandom functions Allow untrusted party to re-encrypt to fresh key Existing key-homomorphic pseudorandom functions are extremely slow 5

7 Security model #RSAC 6

8 Security model #RSAC 6

9 All-or-nothing transform (AONT) #RSAC T T

10 All-or-nothing transform (AONT) #RSAC T T 1? 7

11 Our approach using an AONT #RSAC T XOR with a pseudorandom string

12 Security intuition #RSAC

13 Proxy re-encryption construction #RSAC Sym Initial ciphertext: Enc pk k 0, T Enc k0 f Once re-encrypted ciphertext: Sym Enc pk k 0, Enc pk s 1, k 1, T Enc k0 f Twice re-encrypted ciphertext: Enc pk k 0, Enc pk s 1, k 1, Enc pk s 2, k 2, Ind s1,ctr k1 Sym T Enc k0 M Ind s1,ctr k1 Ind s 2,Ctr k 2 10

14 Instances of AES block cipher Result: Much faster re-encryption #RSAC 2,097, ,144 32,768 4, ,096 32,768 File size (in KiB) Full re-encryption 50% downloaded 75% downloaded 90% downloaded 11

15 Instances of AES block cipher Result: Much faster decryption #RSAC 1,400,000 1,200,000 1,000, , , , , Number of re-encryptions Full 8 KiB Full 40 KiB Full 200 KiB Ours 8 KiB Ours 40 KiB Ours 200 KiB 12

16 Summary #RSAC In scenarios such as access revocation and key rotation, symmetrickey ciphertexts may need to be re-encrypted Existing solutions are either insecure or too slow to be used in practice Using an all-or-nothing transform, we can re-encrypt efficiently while achieving provable security under a reasonable model We provide constructions for updatable symmetric-key encryption, public-key and identity-based proxy re-encryption, and revocablestorage attribute-based encryption 13

17 Apply What You Have Learned #RSAC Realize the need to update the symmetric key Many papers on public-key revocation don t consider hybrid encryption Realistic security models must address key-scraping attacks Possible future work: Produce a general theorem encompassing all uses of symmetric-key encryption Assess tradeoffs between streaming efficiency and security Provide a full implementation of the construction 14

18 SESSION ID: CRYP-W04 ASYNCHRONOUS PROVABLY-SECURE HIDDEN SERVICES Fernando Krell Philippe Camacho

19 Problem: how to hide the location of a server? Arbitrary network topology One node acts as a server Other nodes can be clients 2

20 Problem: how to hide the location of a server? Arbitrary network topology One node acts as a server Other nodes can be clients 2 Avoid DoS Reduce attack surface Censorship resistance Traffic analysis

21 Naive Solution: Recursive Multicast If C contacts S 1, the response will arrive after 2T If C contacts S 2, the response will arrive after 6T 3

22 Anonymity: Synchronous Solutions Mix-nets [Chaum 81] Provably secure 4

23 Anonymity: Synchronous Solutions Mix-nets [Chaum 81] DC-nets [Chaum 88] Provably secure Provably secure 4

24 Anonymity: Asynchronous Alternatives Crowds [Reiter & Rubin 98] Asynchronous Several attacks 5

25 Anonymity: Asynchronous Alternatives Crowds [Reiter & Rubin 98] Tor [Dingledine & Mathewson & Syverson 04] Asynchronous Several attacks 5 Asynchronous Several attacks Most popular

26 Intersection attack lower bound on communication Thus all the nodes must participate in order to hide the server s location. 6

27 Can we get the best of both worlds (Provably Secure and Asynchronous)? Asynchronous Synchronous Provably Secure This work DC-nets/ mix-nets, DO 00 Heuristic Security Tor,Crowds Herbivore [GRPS 03] 7

28 Model Simulation based security definition. Communication restricted to use F Network P i is allowed to send message to P j, if they are directly connected. 8

29 Overview of our solution Participant s behavior is indistinguishable from server s. 1 Client. Broadcast the request 2 Player P i. Upon seeing a request message, send a random value s i to the server (broadcast) 3 Player P i. Upon seeing everybody s values {s j }: If P i = Server. Secret share response r using {s j }. Send share r s j to client. Else. Submit s i to client. 4 Client. Upon receiving all shares, reconstruct the server s response r. 9

30 Overview of our solution Participant s behavior is indistinguishable from server s. 1 Client. Broadcast the request 2 Player P i. Upon seeing a request message, send a random value s i to the server (broadcast) 3 Player P i. Upon seeing everybody s values {s j }: If P i = Server. Secret share response r using {s j }. Send share r s j to client. Else. Submit s i to client. 4 Client. Upon receiving all shares, reconstruct the server s response r. Naive implementation has O(n 2 ) communication complexity. 9

31 Efficient Implementation Avoid recursive multicast on every message. Combine encrypted shares on intermediate nodes. 10

32 Efficient Implementation Avoid recursive multicast on every message. Combine encrypted shares on intermediate nodes. Extra Tools: Homomorphic Encryption Enc pk (m 1 ) + Enc pk (m 2 ) = Enc pk (m 1 + m 2 ) Spanning Tree 10

33 Communication Pattern Avoiding quadratic complexity: 11

34 Phase 1: Broadcast the Request 12

35 Phase 2.a): Shares UP to root Shares are encrypted for the server, and sent up the tree. All shares are added using homomorphic encryption: Enc pk S (y) Enc pk S (z) = Enc pk S (y + z) = Enc pk S (y ) 13

36 Phase 2.b): Shares sum DOWN to server The encrypted sum N i C share N i is sent down the tree so that the server S can decrypt it. 14

37 Phase 3: Server change its share The response to req is computed by the server S: The server recomputes its own share: share new S res := F(req) := res ( N i C share Ni share old S ) The new share of the server and the share of the other nodes add up to res: 15

38 Phase 4.a): Response shares sent to root All N i C (including S) send their share share i to C. S will send share new S instead of share old S. All shares are added using homomorphic encryption (using C s public key): Enc pk C (y) Enc pk C (z) = Enc pk C (y + z) = Enc pk C (y ) 16

39 Phase 4.b) Encrypted response sent to client The encrypted response res = N i C share N i is sent down the tree so that the client C can decrypt it. 17

40 Security based on simulation REAL SIMULATED When client is not corrupted: just simulate protocol under fake messages. When client is corrupted: Simulator S gets response from ideal functionality. S changes honest parties shares so that they reconstruct the correct response. 18

41 Linear Complexity O(1) messages per Spanning Tree Edge. O(1) homomorphic encryption operations. Although a node can have O(n) worst case complexity. 19

42 Malicious Adversaries (Overview) Adversary s strategies: Drop messages. DoS. Change shares. DoS. New Protocol: Messages are signed. Use recursive multicast for all messages (O(n 2 ) Comm. complexity). Append zero-knowledge proof that ciphertexts encrypt same share. Allow identification of malicious players. 20

43 Zero-knowledge proof Prove that two ciphertexts encrypt same message, except... 21

44 Zero-knowledge proof Prove that two ciphertexts encrypt same message, except... Server actually changes the share. Proof needs to convince that [1] The two ciphertexts encrypt same message OR [2] The issuer is the server 21

45 Zero-knowledge proof Prove that two ciphertexts encrypt same message, except... Server actually changes the share. Proof needs to convince that [1] The two ciphertexts encrypt same message OR [2] The issuer is the server Do not reveal whether which of [1], [2] is true. Reduces to simple Σ-protocol for relation R g1,g 2 = {(A, B; r) : A = g r 1 }{{ B = gr 2 } {(D; s) : D = g s } }}{{} [1] [2] 21

46 Future work Resilience. Protocol needs to succeed even if some players disappears Improve communication complexity of second protocol Empirical Study Find trade-offs to scale current solution Server anonymity Questions? 22