Cryptographic Protocols: Practical revocation and key rotation
β’
1 likeβ’267 views
This document summarizes a presentation on asynchronous provably-secure hidden services. The presentation proposes a protocol that allows a client to communicate with a hidden server in an asynchronous and distributed network, while provably preserving the server's anonymity. The key aspects are: (1) the client broadcasts a request, (2) all nodes (including the server) secret share a response using random values, (3) shares are routed to the client who reconstructs the response, ensuring the server's behavior is indistinguishable from others. The protocol achieves linear communication complexity using homomorphic encryption and a spanning tree structure. Security is based on simulation, showing the real and simulated views are indistinguishable.
More Related Content
What's hot
What's hot (19)
Similar to Cryptographic Protocols: Practical revocation and key rotation
Similar to Cryptographic Protocols: Practical revocation and key rotation (20)
More from Priyanka Aash
More from Priyanka Aash (20)
Recently uploaded
Recently uploaded (20)
Cryptographic Protocols: Practical revocation and key rotation
- 1. SESSION ID: #RSAC Adam Shull CRYPTOGRAPHIC PROTOCOLS: PRACTICAL REVOCATION AND KEY ROTATION CRYP-W04 Recent Ph.D. Graduate Indiana University
- 2. #RSAC π π π π Access revocation on the cloud 2 ππ§π ππ Pub π1 , ππ§π π1 Sym π1 ππ§π ππ Pub π2 , ππ§π π2 Sym π2 ππ§π ππ Pub π3 , ππ§π π3 Sym π3 π π
- 3. #RSAC π πβ² π πβ² Access revocation on the cloud 2 ππ§π ππ Pub π1 , ππ§π π1 Sym π1 ππ§π ππ Pub π2 , ππ§π π2 Sym π2 ππ§π ππ Pub π3 , ππ§π π3 Sym π3
- 4. #RSAC Revocation using proxy re-encryption 3 ππ§π ππ Pub π1 , ππ§π π1 Sym π1 ππ§π ππ Pub π2 , ππ§π π2 Sym π2 ππ§π ππ Pub π3 , ππ§π π3 Sym π3 ππ§π ππβ² Pub π1 , ππ§π π1 Sym π1 ππ§π ππβ² Pub π2 , ππ§π π2 Sym π2 ππ§π ππβ² Pub π3 , ππ§π π3 Sym π3 Proxy re-encrypt from ππ to ππβ²
- 5. #RSAC Key-scraping attack 4 ππ§π ππ Pub π1 , ππ§π π1 Sym π1 ππ§π ππ Pub π2 , ππ§π π2 Sym π2 ππ§π ππ Pub π3 , ππ§π π3 Sym π3 ππ§π ππβ² Pub π1 , ππ§π π1 Sym π1 ππ§π ππβ² Pub π2 , ππ§π π2 Sym π2 ππ§π ππβ² Pub π3 , ππ§π π3 Sym π3 The symmetric keys for the files are not changed! A revoked user may have stored π1, π2, and π3
- 6. #RSAC The symmetric key must be changed! 5 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
- 11. #RSAC 1010110000111111101001010101110100111011000101010001010100111000 Our approach using an AONT 0111101100101111010010011100100011001110001111010100010010010111 π 1010110100111101101001010101110100111011000101011001010100011000 XOR with a pseudorandom string 8
- 13. #RSAC Initial ciphertext: ππ§π ππ π0 , π ππ§π π0 Sym π Once re-encrypted ciphertext: ππ§π ππβ² π0 , ππ§π ππβ² π 1, π1 , π ππ§π π0 Sym π Ind π 1 ,Ctr π1 Twice re-encrypted ciphertext: ππ§π ππβ²β² π0 , ππ§π ππβ²β² π 1, π1 , ππ§π ππβ²β² π 2, π2 , π ππ§π π0 Sym π Ind π 1 ,Ctr π1 Ind π 2 ,Ctr π2 Proxy re-encryption construction 10
- 14. #RSAC Result: Much faster re-encryption 11 64 512 4,096 32,768 262,144 2,097,152 1 8 64 512 4,096 32,768 InstancesofAESblockcipher File size (in KiB) Full re-encryption 50% downloaded 75% downloaded 90% downloaded
- 15. #RSAC Result: Much faster decryption 12 0 200,000 400,000 600,000 800,000 1,000,000 1,200,000 1,400,000 0 20 40 60 80 100 InstancesofAESblockcipher Number of re-encryptions Full 8 KiB Full 40 KiB Full 200 KiB Ours 8 KiB Ours 40 KiB Ours 200 KiB
- 16. #RSAC Summary 13 In scenarios such as access revocation and key rotation, symmetric- key 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 revocable- storage attribute-based encryption
- 17. #RSAC Apply What You Have Learned 14 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
- 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 β’ Avoid DoS β’ Reduce attack surface β’ Censorship resistance β’ Traο¬c analysis 2
- 21. Naive Solution: Recursive Multicast β’ If C contacts S1, the response will arrive after β 2T β’ If C contacts S2, 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] β’ Provably secure DC-nets [Chaum β88] β’ Provably secure 4
- 24. Anonymity: Asynchronous Alternatives Crowds [Reiter & Rubin β98] β’ Asynchronous β’ Several attacks 5
- 25. Anonymity: Asynchronous Alternatives Crowds [Reiter & Rubin β98] β’ Asynchronous β’ Several attacks Tor [Dingledine & Mathewson & Syverson β04] β’ Asynchronous β’ Several attacks β’ Most popular 5
- 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 deο¬nition. β’ Communication restricted to use FNetwork β’ Pi is allowed to send message to Pj, 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 Pi. Upon seeing a request message, send a random value si to the server (broadcast) 3 Player Pi. Upon seeing everybodyβs values {sj}: β’ If Pi = Server. Secret share response r using {sj}. Send share r β sj to client. β’ Else. Submit si 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 Pi. Upon seeing a request message, send a random value si to the server (broadcast) 3 Player Pi. Upon seeing everybodyβs values {sj}: β’ If Pi = Server. Secret share response r using {sj}. Send share r β sj to client. β’ Else. Submit si to client. 4 Client. Upon receiving all shares, reconstruct the serverβs response r. Naive implementation has O(n2) communication complexity. 9
- 31. Eο¬cient Implementation β’ Avoid recursive multicast on every message. β’ Combine encrypted shares on intermediate nodes. 10
- 32. Eο¬cient Implementation β’ Avoid recursive multicast on every message. β’ Combine encrypted shares on intermediate nodes. Extra Tools: β’ Homomorphic Encryption β’ Encpk(m1) + Encpk(m2) = Encpk(m1 + m2) β’ 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: EncpkS (y) Β· EncpkS (z) = EncpkS (y + z) = EncpkS (y ) 13
- 36. Phase 2.b): Sharesβ sum DOWN to server The encrypted sum Ni=C shareNi 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: res := F(req) β’ The server recomputes its own share: sharenew S := res β ( Ni=C shareNi β shareold 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 Ni = C (including S) send their share sharei to C. β’ S will send sharenew S instead of shareold S . β’ All shares are added using homomorphic encryption (using Cβs public key): EncpkC (y) Β· EncpkC (z) = EncpkC (y + z) = EncpkC (y ) 16
- 39. Phase 4.b) Encrypted response sent to client The encrypted response res = Ni=C shareNi 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(n2) Comm. complexity). β’ Append zero-knowledge proof that ciphertexts encrypt same share. Allow identiο¬cation 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 Rg1,g2 = {(A, B; r) : A = gr 1 β§ B = gr 2} [1] {(D; s) : D = gs } [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-oο¬s to scale current solution β’ Server anonymity Questions? 22