ACHIEVING PRIVACY IN VERIFIABLE COMPUTATION WITH MULTIPLE SERVERS WITHOUT FHE AND WITHOUT PREPROCESSING

Transcription

1 ACHIEVING PRIVACY IN VERIFIABLE COMPUTATION WITH MULTIPLE SERVERS WITHOUT FHE AND WITHOUT PREPROCESSING Prabhanjan Ananth, UCLA Nishanth Chandran, Microsoft Research India Vipul Goyal, Microsoft Research India Bhavana Kanukurthi, UCLA Rafail Ostrovsky, UCLA Presented by: Chongwon Cho, HRL

2 OUTSOURCING COMPUTATION Alice has a weak device and she wants to perform expensive computation

3 OUTSOURCING COMPUTATION Alice has a weak device and she wants to perform expensive computation Solution: Outsource to the cloud

4 CLOUD COMPUTING Commercial providers: Amazon, Microsoft Azure, Google Compute Engine etc.

5 CLOUD COMPUTING Commercial providers: Amazon, Microsoft Azure, Google Compute Engine etc. Stanford Project that uses computing resources of thousands of volunteer PCs/game consoles

6 OUTSOURCING COMPUTATION x f(x)

7 OUTSOURCING COMPUTATION x f(x) Problem: Need to trust the companies that the computation was done correctly.

8 OUTSOURCING COMPUTATION x f(x) What if the cloud is malicious?

9 OUTSOURCING COMPUTATION x f(x) Solution: Verifiable Computation What if the cloud is malicious?

10 VERIFIABLE COMPUTATION F

11 VERIFIABLE COMPUTATION F Input: x Goal: Verifiably outsource computation of F on x to the cloud

12 VERIFIABLE COMPUTATION F x

13 VERIFIABLE COMPUTATION F x Compute y=f(x) Generate proof z that the computation was done correctly

14 VERIFIABLE COMPUTATION F x y,z Compute y=f(x) Generate proof z that the computation was done correctly

15 VERIFIABLE COMPUTATION F x y,z Verify using proof z that y = F(x) Compute y=f(x) Generate proof z that the computation was done correctly

16 PROPERTIES OF VC PROTOCOL Verifiability: An adversarial cloud cannot make Alice accept an incorrect F(x). Efficiency: Verifying y=f(x) should be significantly easier than computing F(x) itself.

17 A SECOND LOOK AT VERIFIABLE COMPUTATION F x y,z Verify using proof z that y = F(x) Compute y=f(x) Generate proof z that the computation was done correctly

18 A SECOND LOOK AT VERIFIABLE COMPUTATION F x y,z Verify using proof z that y = F(x) Is it necessary Compute that the y=f(x) cloud learns Generate x? proof z that the computation was done correctly

19 A SECOND LOOK AT VERIFIABLE COMPUTATION F x This work: Focus y,zon achieving privacy Verify using proof z that y = F(x) Is it necessary Compute that the y=f(x) cloud learns Generate x? proof z that the computation was done correctly

20 PRIOR WORK ON VC PROTOCOLS

21 PRIOR WORK ON VC No input-privacy: PROTOCOLS With input-privacy:

22 PRIOR WORK ON VC PROTOCOLS No input-privacy: CS proofs [Micali94], Extractable CRHF-based solutions [GLR11,BCCT11], ABE based solutions [PRV12], Quadratic Span programs [GGPR12], Information-theoretic protocols [CRR12] With input-privacy:

23 PRIOR WORK ON VC PROTOCOLS No input-privacy: CS proofs [Micali94], Extractable CRHF-based solutions [GLR11,BCCT11], ABE based solutions [PRV12], Quadratic Span programs [GGPR12], Information-theoretic protocols [CRR12] With input-privacy: FHE-based solutions [GGP10,CKV10], Randomized-Encodings based solutions [AIK10]

24 PRIOR WORK ON VC PROTOCOLS No input-privacy: CS proofs [Micali94], Extractable CRHF-based solutions [GLR11,BCCT11], ABE based solutions [PRV12], Quadratic Span programs Either use FHE or defined for [GGPR12], Information-theoretic protocols [CRR12] specific functions. With input-privacy: FHE-based solutions [GGP10,CKV10], Randomized-Encodings based solutions [AIK10]

25 DRAWBACKS WITH FHE Computational assumption: constructions under standard assumptions known only for leveled-fhe

26 DRAWBACKS WITH FHE Computational assumption: constructions under standard assumptions known only for leveled-fhe Efficiency: the computational overhead involved during evaluation is large.

27 DRAWBACKS WITH FHE Computational assumption: Can we achieve privacy in verifiable computation standard assumptions known only for leveled-fhe for all efficient functions without FHE? Efficiency: during evaluation is large.

28 ACHIEVING PRIVACY IN VC WITHOUT FHE Single server case: FHE seems to be inherently required.

29 ACHIEVING PRIVACY IN VC WITHOUT FHE Single server case: FHE seems to be inherently required. We focus on the case when Alice outsources her computation to many servers

30 RESULTS

31 RESULTS 2-server case: based on one-way functions, very efficient

32 RESULTS 2-server case: based on one-way functions, very efficient n-servers: Protocol #1: can tolerate (n-1) dishonest servers, based on DDH assumption

33 RESULTS 2-server case: based on one-way functions, client is very efficient n-servers: Protocol #1: can tolerate (n-1) dishonest servers, based on DDH assumption Protocol #2: can tolerate constant fraction of dishonest servers, based on one-way functions

34 RESULTS 2-server case: based on one-way functions, client is very efficient n-servers: Protocol #1: can tolerate (n-1) dishonest servers, based on DDH assumption Protocol #2: can tolerate constant fraction of dishonest servers, based on one-way functions

35 PROPERTIES OF PROTOCOL #1 Based on DDH assumption

36 PROPERTIES OF PROTOCOL #1 Based on DDH assumption At least one honest server

37 PROPERTIES OF PROTOCOL #1 Based on DDH assumption At least one honest server No preprocessing

38 PROPERTIES OF PROTOCOL #1 Based on DDH assumption Many prior known protocols : expensive At least one honest server preprocessing No preprocessing

39 PROPERTIES OF PROTOCOL #1 Based on DDH assumption At least one honest server No preprocessing The client complexity independent of the function complexity.

40 PROPERTIES OF PROTOCOL #1 At least one honest server No preprocessing In all prior known protocols : the client complexity depends on the function complexity The client complexity independent of the function complexity.

41 TECHNICAL DETAILS

42 VC IN THE MULTIPLE-SERVER MODEL F F F Input : x

43 VC IN THE MULTIPLE-SERVER MODEL F F F msg1 Input : x

44 VC IN THE MULTIPLE-SERVER MODEL F F F msg2 msg1 Input : x

45 VC IN THE MULTIPLE-SERVER MODEL F F F msg2 msgn msg1 Input : x

46 VC IN THE MULTIPLE-SERVER MODEL F F F msg2 msgn msg1 msgn+1 Input : x

47 VC IN THE MULTIPLE-SERVER MODEL F F F msg2 msgn msg1 msgn+1 Input : x Alice retrieves F(x) from msgn+1

48 VC IN THE MULTIPLE-SERVER MODEL F F F msg2 msgn msg1 msgn+1 Advantage: Minimal communication between the parties Input : x Alice retrieves F(x) from msgn+1

49 THIS TALK: EQUIVALENT MODEL F F F msg2 msgn msg1 msgn+1 Input : x Alice sends messages to intermediate servers

50 THIS TALK: EQUIVALENT MODEL F F F msg2 msgn This is equivalent to the previous model: msg1 Client encrypts all the messages with public keys of servers Signs the ciphertexts Sends the ciphertexts to the first server. Input : x msgn+1 Alice sends messages to intermediate servers

51 OUR CONSTRUCTION

52 OUR CONSTRUCTION Main ingredient: rerandomizable garbled circuits [GHV10]

53 OUR CONSTRUCTION Main ingredient: rerandomizable garbled circuits [GHV10] freshly generated GC rerandomized GC GC1 GC2

54 OUR CONSTRUCTION Main ingredient: rerandomizable garbled circuits [GHV10] freshly generated GC rerandomized GC GC1 GC2 Cannot distinguish: fresh GC v/s rerandomized GC

55 OUR CONSTRUCTION Main ingredient: rerandomizable garbled circuits [GHV10] - Use encryption scheme that has homomorphic properties.

56 OUR CONSTRUCTION Main ingredient: rerandomizable garbled circuits [GHV10] - Use encryption scheme that has homomorphic properties. Supports permutation and XOR

57 USING RERANDOMIZABLE GC First server: garbles the circuit F to obtain GC1 and sends to second server. i th server: rerandomizes the garbled circuit GCi-1 to obtain GCi and sends to i+1 th server. Last server: evaluates the garbled circuit to obtain F(x).

58 USING RERANDOMIZABLE GC First server: garbles the circuit F to obtain GC1 and sends to second server. i th server: rerandomizes the garbled circuit GCi-1 to wire keys supplied by the client obtain GCi and sends to i+1 th server. Last server: evaluates the garbled circuit to obtain F(x).

59 USING RERANDOMIZABLE GC: ISSUES The garbled circuits can be maliciously generated by servers

60 USING RERANDOMIZABLE GC: ISSUES The garbled circuits can be maliciously generated by servers - Use NIZKs

61 USING RERANDOMIZABLE GC: ISSUES The garbled circuits can be maliciously generated by servers - Use NIZKs The servers can use improper randomness

62 USING RERANDOMIZABLE GC: ISSUES The garbled circuits can be maliciously generated by servers - Use NIZKs The servers can use improper randomness - Client gives PRF keys to the servers

63 OUR CONSTRUCTION F F F msg2 msgn msg1 msgn+1 Input : x

64 OUR CONSTRUCTION F F F Send PRF key K1 to 1 st server Input : x

65 OUR CONSTRUCTION F F F Garble F to obtain GC1 Send GC1 to 2 nd server Send proof of computation Input : x

66 OUR CONSTRUCTION F F F Send PRF key K2 to 2 nd server Input : x

67 OUR CONSTRUCTION F F F rerandomize GC1 to obtain GC2 Send GC1 to 3 rd server Send proof of computation Input : x

68 OUR CONSTRUCTION F F F Send wire keys of GCn-1 corresponding to x Input : x

69 OUR CONSTRUCTION F F F Evaluate msgthe garbled circuit GCn-1 to obtain F(x) Send F(x) to the client Input : x

70 OUR CONSTRUCTION: PROPERTIES

71 OUR CONSTRUCTION: PROPERTIES Input-privacy? YES

72 OUR CONSTRUCTION: PROPERTIES Input-privacy? YES Client efficiency? YES

73 OUR CONSTRUCTION: PROPERTIES Input-privacy? YES Client efficiency? YES Verifiability? NO

74 OUR CONSTRUCTION: Input-privacy? YES PROPERTIES Client efficiency? YES Verifiability? NO The last server might send an incorrect value as F(x)

75 ENSURING VERIFIABILITY Consider the function G(.,. ): G(x,K) outputs (F(x), MAC(K,F(x)))

76 ENSURING VERIFIABILITY Consider the function G(.,. ): G(x,K) outputs (F(x), MAC(K,F(x))) Modify our construction as follows: - Garble G(.,. ) instead of F - Client sends wire keys corresponding to x and K instead of just x

77 REMARK ON CLIENT COMPLEXITY Client complexity depends on the number of servers

78 REMARK ON CLIENT COMPLEXITY Client complexity depends on the number of servers - Has to send PRF keys to all servers.

79 REMARK ON CLIENT COMPLEXITY Client complexity depends on the number of servers - Has to send PRF keys to all servers. - Has to rerandomize the wire keys (n-2) times to obtain wire keys of the last GC

80 REMARK ON CLIENT COMPLEXITY Client complexity depends on the number of servers - Has to send PRF keys to all servers. - Has to rerandomize the wire keys (n-2) times Using preprocessing: generate all PRF to obtain wire keys of the last GC keys during preprocessing phase

81 REMARK ON CLIENT COMPLEXITY Client complexity depends on the number of servers - Has to send PRF keys to all servers. - Has to rerandomize the wire keys (n-2) times to obtain wire keys of the last GC???

82 IMPROVING CLIENT COMPLEXITY Warmup attempt: Using encryption scheme having homomorphic properties.

83 IMPROVING CLIENT COMPLEXITY Warmup attempt: Using encryption scheme having homomorphic properties. Supporting permutation and XOR operations.

84 MODIFIED CONSTRUCTION F F F Encrypt input wire keys of GC1 w.r.t x Input : x

85 MODIFIED CONSTRUCTION F F F rerandomize wire keys of GC1 Input : x

86 MODIFIED CONSTRUCTION F F F rerandomize wire keys of GC1 Using homomorphism of encryption Input : x

87 MODIFIED CONSTRUCTION F F F Send decryption key Input : x

88 MODIFIED CONSTRUCTION F F F Gets encrypted wire keys Decrypts it to obtain F(x) Input : x

89 MODIFIED CONSTRUCTION F F F Does not work Input : x

90 MODIFIED CONSTRUCTION F F F Does not work Reason: First and last server can collude Input : x

91 FIXING THE CONSTRUCTION Use re-encryption

92 FIXING THE CONSTRUCTION Use re-encryption : can re-encrypt a ciphertext corresponding to a different public key.

93 FIXING THE CONSTRUCTION Use re-encryption : can re-encrypt a ciphertext corresponding to a different public key. We use an encryption scheme that supports reencryption and homomorphism.

94 FIXING THE CONSTRUCTION Use re-encryption : can re-encrypt a ciphertext corresponding to a different public key. Details in the paper We use an encryption scheme that supports reencryption and homomorphism.

95 OPEN PROBLEMS Replacing NIZKs in our construction. VC protocol in the multiple-server model based on one-way functions? More efficient VC protocols for specific functions?

96 QUESTIONS? Prabhanjan Ananth - prabhanjan@cs.ucla.edu Nishanth Chandran - nichandr@microsoft.com Vipul Goyal - vipul@microsoft.com Bhavana Kanukurthi - bhavanak@cs.bu.edu Rafail Ostrovsky - rafail@cs.ucla.edu

97 THANKS