Witness-Based Cryptographic Program Checking and ... - CiteSeerX

Witness-Based Cryptographic Program Checking and Robust Function Sharing Yair Frankel

Peter Gemmelly

Abstract We suggest a new methodology for \result checking" that enables us to extend the notion of Blum's program result checking to the on-line checking of cryptographic functions. In our model, the checker not only needs to be assured of the correctness of the result but the owner of the program needs to be sure not to give away anything but the requested result on the (authorized) input. The existing approaches for program result checking of numerical problems often ask the program a number of extra queries (dierent from the actual input). In the case of cryptographic functions, this may be in contradiction with the security requirement of the program owner. Additional queries, in fact, may be used to gain unauthorized advantage (for example, imagine the implications of the on-line checking of a decryption device that requires the decryption of extra ciphertexts). In [Blum88], the notion of a simple checker was introduced where, for the purpose of eciency, extra queries are not allowed. In our model, we do allow extra queries, but only when the response is simulate able. We de ne a new \witness-based" approach and give constructions that apply to various cryptographic scenarios while making sure that the checker/program interaction releases no extra \knowledge". A particularly useful application is achieving \ecient robust function sharing", a method by which the power to apply a cryptographic function (e.g., RSA decryption / signature) is shared among multiple trustees. As long as a quorum of the trustees is not corrupted and is available, we can apply the function on the input parameters while maintaining the security of the function. With robustness we are able to tolerate and identify misbehaving trustees, both with eciency and on-line, when computing a function value.

 Sandia National Labs. Albuquerque, NM 87185; [email protected]; This work was performed under U.S. Department of Energy contract number DE-AC04-76AL85000. ySandia National Labs. Albuquerque, NM 87185; [email protected]; This work was performed under U.S. Department of Energy contract number DE-AC04-76AL85000 zIBM T. J. Watson Research Center, Yorktown Heights, NY; [email protected]

Moti Yung z

1 Introduction Blum [Blum88] introduced the useful and elegant notion of Program Result Checking, which was further developed in various ways and new directions (e.g., [BK89, Rub90, BLR90, LIP91, BW95]). In this setting, given arbitrary input  and program P , a checker C for a function f will catch, with high probability, if P () 6= f (). The checker has only a \black-box" access to the program and accomplishes its goal on-line. Our goal in this work is to allow the on-line checking of programs computing cryptographic functions in a working environment. (In fact, this need was exempli ed recently when it was shown that a cryptographic program in a popular Internet server can, actually, be manipulated and spoofed by intruders [NYT95]) We have noticed, however, that in our case there are various new constraints and requirements due to the cryptographic nature of the setting. As a result of which, traditional \program checking" by itself is insucient. Indeed, in our model the checker worries about correctness (which \program checking" takes care of, since due to the adversarial setting we require correctness with very high probability). In our model, the owner of a program will output P () provided it is authorized to output the result, but the checker (user) learns nothing more about P from this checking procedure, in the spirit of zero-knowledge complexity approach to knowledge. This gives rise to a game between two mutually distrusting parties, one (program owner) willing to release a result but nothing more, and the second user (checker), that needs to verify the correctness of the released result. Existing \program result checkers" may not satisfy the security needs of the program owner. In fact, often in the case of numerical problems, the checker gets to query the program on a number of inputs and this enables it to exploit algebraic relations and conclude that the result is correct. For security reasons, it may be disadvantageous or even disastrous for the program's owner to allow such additional querying. We will show how to bridge the seemingly disparate needs of the two parties and assure \correctness" for the checker on one hand, and \minimal exposure" to the program, on the other. We note that some known notions are similar to our concerns since they deal with releasing no computational advantage or information and, in fact, we were inspired by them. Zero-knowledge proofs [GMR89] are one example, however they typically validate a result by accessing the structure (circuit) of the computational device that computes the result (e.g. proof of a result of a circuit computation translated into NP statement). Thus, zero-knowledge proofs do not constitute a \black box" approach to checking but rather it is proof of correctness of a well de ned public computation.

The notion of \hiding an input from an oracle" [AFK87] deals with the issue of the requester hiding its input from the computational device; we, however, are concerned with the opposite direction (protecting the computing device).

1.1 The approach: witness-based checking

Given that we cannot allow the checker to probe on additional inputs, we resort to a new way of viewing checking. We are motivated by common practice of installation guides for devices and software functions. The guides typically give some random input/output relation. To check the installation, one has to feed the mechanism with the sample input (e.g., a key and a message) and get an output (a ciphertext). Both input and output are given in the guide. If there is a match of the actual output to the printed one, we assume the mechanism has been correctly installed. The approach we suggest is to have a small initial trusted collection (limited small sample) of instances of inputs and their correct outputs which the checker holds. We call this approach witness-based checking. Given this precomputed trusted sample (e.g., a signature on meaningless messages that are not risky) we then require that one can on-line check the results of the program whenever activated on the entire distribution.

1.2 Applications

The basic application is testing cryptographic servers. In the future, many servers will act on behalf of user populations and assurance of non-spoofed service will be important. We now discuss several applications for cryptographic program checking. Consider the encrypting-machine requester game where the encrypting-machine (server) is willing to encrypt authorized requests. If the checking process requires the encryption of other (unauthorized) plaintext so that the output of the request can be checked, then the checker can exploit this service to encrypt unauthorized texts as well. Another similar application is the international key escrow game. (This is related to recent speci cations of actual system that is not yet well understood; but is similar to the concept of escrow encryption systems such as Clipper [FIPS185, DS94]). In this situation country A has a key escrow system and will allow country B to obtain decryption of messages of A's citizens under some prede ned treaty and under some conditions. A does not want to provide B with the actual keys of its citizens (only decrypted messages) while country B does not trust that A will reply with the correct cleartext values. Cryptographic program checking, in turn, allows B to verify the correctness of the outputs, while A knows that it is not being abused (by revealing messages not covered by the treaty or conditions). One of the applications that motivated this research on cryptographic program checking is in the development of veri cation algorithms for function sharing [DDFY94], a method to distribute control of a function as suggested for threshold cryptography [F89, DF89]. In function sharing a function f is distributed amongst n agents as programs P1 (
); : : : ; Pn (
) such that a threshold (quorum) of, say, any t are able to compute f () from Pi1 ();: : : ; Pit (). There are several interesting applications for which function sharing is a very useful solution in practice (e.g., distributed decryption, signature generation, public key certi cation generation, e-cash generation, etc.). Once the shares are available

there is a polynomial-time combiner that collects the shares and combine them to the nal result of the function. When agents may misbehave this gives rise to the agent combiner game, where the combiner has to be sure to pick correct shares into its computation. If there is no ecient way to verify correctness of shares, the combiner may need to try all subsets of shares (but this will take exponential time). The agent combiner game will assure the combiner which of the agents acted correctly. The need for robust function sharing was also expressed in [RB94] in an application for replicating services in network were some of the clients and servers have been corrupted by an adversary. Since there is a real systems' need for the primitive, inecient methods like non-interactive zero-knowledge techniques should be avoided. Another notion is the proactive-function game which is an extension of the agent-combiner game. In this system the agents' state is modi ed over time so that an adversary may have access to all agents over the lifetime of the system but not to all at any particular point in time. The agents periodically modify their state so that information learned by a mobile adversary at two points in time is, for practical purposes, uncorrelated. In this game, the honest agents make sure that changing their state does not provide a means for the adversary either to learn too much information or to destroy the ability of honest agents later to compute the function. Hence each of the agents veri es the information provided to it by other agents is correct before it changes states. [FGMY96] give a pro-active RSA protocol using cryptographic program checking. The basic ideas of our methodology can be applied to a veri er hardware-device game. Where a holder of a result computed by some hardware device needs to probe a verifying device. For example, how can we make sure that a value computed in the past (a time stamp) is correct without the veri cation process leaking the computation itself (thus, recomputing the time stamp{ which in eect causes an undesirable back-stamping). The methodology presented in this work applies to this situation as well.

Organization:

In section 2 we present basic de nition and the model. In section 3 we present the rst approach to cryptographic function sharing where parties share access to a random oracle function, while in section 4 we present a procedure that does not employ random oracle in its basic form and potentially can employ it to reduce interaction. In section 5, we discuss a multi-prover approach which removes some of the limitations of the previous methods. The main application to function-sharing is given in section 6.

2 Model and De nitions In this section we formally introduce the concept of cryptographic program checking which is an extension of program checking for security needs. Let us rst de ne program checking [BK89, BLR90].

De nition 1 (program checker) Let P be a program

that supposedly computes function f . Let C be a probabilistic polynomial time algorithm. Let  be a security parameter (which we call the checking security parameter). (C; P; f ) is a program checking system if it satis es:  Input: h;y = P ()i

 Correct output: if P (z ) = f (z ) for all inputs z , ACCEPT; if y = 6 f (), REJECT. Otherwise either

REJECT or ACCEPT is correct.  Reliability: for all h;yi: the probability that C 's output is correct for h; yi is greater than or equal to 1 ? .  Time bound: C is time bounded by a constant multiple of P when including running time of subroutine P ; C is time bounded by o(T (n)) when the running time of subroutine P is counted as one step and where T (n) is the minimum worst-case running time of any program that computes f on inputs of length n. We say a family of program checking systems for a family of functions F when for all functions f 2 F there exists a (C; P;f ). The checking security parameter is  = (n) where n is the size of inputs to a given f 2 F . Program checking assumes that the adversary is the program P and the entity having access to the input and/or output of P is honest. In our model we want more from the system. That is in our cryptographic program checking model, the program owner itself does not trust the checker. We now de ne an adversarial model of the entity having a speci c capability against a secure function. This adversarial entity will later be de ned as the owner of the program checker C . We rst formalize what we mean by a protocol being secure against an adversary.

De nition 2 (Secure Functions with Restricted Access) Let Ad be an adversary against a family of cryptographic functions F with capability Cap. Let n be a function security parameter (input size). We say that F is secure against Ad with respect to Cap when the probability that Ad can perform a successful attack on programs P computing f 2R F is less than  ( = (n; Cap) is the function successful attack probability relative to Cap). The de nition of successful attack is dependent on the adversary, Ad computation, when given a description of the family F and Cap. We say Ad has restricted access when Cap de nes a set CapI;Hist which de nes the allowable inputs given a history Hist.

We note that it is possible to de ne a large set of traditional cryptographic adversarial models with the above de nition. The above de nition is purposefully vague in de ning what a successful attack may be. We may use, for instance, either polynomial security or semantic security. Our goal is to de ne the most general model which is dicult when we do not de ne the security model for f formally. We now are ready to de ne cryptographic program checking. What we desire is a system that satis es the program checking requirements yet protects the usage of P .

De nition 3 (Cryptographic program checking (CPC) system) Let f 2 F operate on inputs of size n. The checking security parameter is  = (n) where n is the size of inputs to a given f 2 F .

A system (C;P 0 ; P;f ) is a Cryptographic Program Checking system if: (C; P 0 ; P ) is a system of programs where C and P 0 have inputs x. P supposedly computes f . P 0 can call P and 0 . At the start interact with C . C can interact only with P of the interaction between P 0 and C , P 0 sends a value y (supposedly P ())) to C . The system satis es the following further constraints: 1. Security against P 0 ; P There exists C = C good such that the system satis es the following properties: (A) If P (z ) = f (z ) for all inputs z then there exists a polynomial time P 0 = P 0good such that C1good accepts with probability at least 1 ?  and  < nk for any k for n large enough). (B) If y 6= f () then for all P 0 , C good rejects with probability at least 1 ? . (C) Otherwise, C good may reject or accept with any probabilities. (D) Both C good and P 0good run in time bounded by a constant multiple ofgood P when including running time of subroutine P ; C and P 0good are time bounded by o(T (n)) when the running time of subroutine P is counted as one step and where T (n) is the minimum worst-case running time of any program that computes f on inputs of length n. (In particular if f is non-trivial i.e.goodnot computable in BPP, it holds since we require C and P 0good to run in polynomial time). 2. Security against C If there exists an adversary Ad0 that can successfully attack f by playing the role of C against P 0good and P = f and all inputs i 2 Cap, then there is an adversary Ad that can successfully attack f just by having restricted access (on the same inputs i ) to f , where: (A) The time and space resources of Ad0 are polynomially bounded in terms of those of Ad. (B) Other resources are the same (C) For every constant k for large enough n the probability of success of Ad and the probability of successful attack of Ad0 dier by at most n1k . (Thus, since (n) is a bound on the 0success probability of any Ad (with Cap), then any Ad is successful by less than (n)+ n1k .) Note that if every poly-time restricted access adversary is bounded Ad by (n; Cap) then we get a global bound on an any similar resource bounded adversary attacking the checker.

2.1 Algebraic properties

Many of the program checking methodologies are linked to the algebraic properties of the function that they check. One function property that program checking exploits is called random self reducibility. De nition 4 A function f is k-random self-reducible if f (x) can be expressed as an easily computable function of f (x1 ); : : : ; f (xk ), where the xi 's are each uniformly randomly distributed.

Note that homomorphic functions where multiplication and division in the domains are easy are random self reducible. Another similar concept has been developed. Coherent functions [Yao90] are ones in which, given inputs ; , it is possible to determine using a BPP f algorithm that does not query f on x whether f (x) = y. One dierence between coherent functions and random self reducible functions is that coherent functions allow for an adaptive choice of queries while, for random self reducible functions, the choice of queries is made in one pass. [Yao90] proved that if function f has an ecient checker then it is coherent. If a simple use of random self reducabilty is used for cryptographic program checking then the owner of the program will have to output the function value for random inputs. This will allow instances where the checker can compute P () from, say, a P (0 ) when 0 is allowed but  is not. Hence, random self reducability in its most basic form is not useful for cryptographic program checking because the program owner does not want to reveal more information about the function than outputs for the allowed inputs (See security against C in De nition 3).

2.2 Indistinguishability and zero-knowledge proofs

The reader familiar with indistinguishability and with zeroknowledge interactive proofs may skip this sub-section (see also [GMR89]). We employ the notion of a proof system and zero-knowledge (simulatability) in our proofs. Let Prover be a probabilistic Turing machine and let V erifier a probabilistic polynomial-time machine that share the same input and can communicate with each other. By using Prover $V(x) we denote V erifier's output after interacting with Prover on input x. De nition 5 A pair (Prover; V erifier) constitutes an interactive proof system for the language L if 1. (Completeness) If x 2 L then Pr(Prover $ V erifier(x) = ACCEPT)  2=3: 2. (Soundness) If x 62 L then for all probabilistic Turing machines Prover Pr(Prover $ V erifier(x) = ACCEPT)  1=2: We de ne ViewV erifier (x), V erifier's view of the interaction with Prover on input x, as the probability space that assigns to pairs (R; log ) the probability that R is the tape of V erifier's random bits and that log is the transcript of a conversation between Prover and V erifier on input x given that R is V erifier's random tape. We now discuss statistical zero-knowledge. De nition 6 Interactive proof system (Prover; V erifier) for L is a statistical zero-knowledge proof system for L (in short, a SZK proof system) if for each V erifier there exists a probabilistic machine MV erifier (called the simulator) running in expected polynomial time such that for all constants c and all suciently long x 2 L

X jPr(View V erifier (x) = ) ? Pr(MV erifier (x) = )j 

< jxjc:

This statistical indistinguishability is the notion of approximation of random variables (in general) we use in the rest of the paper.

2.3 Witnesses and approximable group order

We deal with homomorphic functions. Wlog, we will assume that the function domain D is a nite multiplicative group throughout this paper. We now discuss witnesses which are the basis for our protocols. These are instances of input/output pairs for a function. [CvA89] used a similar concept for undeniable signatures. Security of a function f given such a witness set means that that having knowledge of the witness does not reduce the strength of the function against attack. Many cryptographic functions inherently satisfy this condition. For instance with a public key signature, the message w and its signature f (w) are considered public. De nition 7 Let group D(
) be the domain to homomorphic function f . The witness to a homomorphic function f is a tuple W = (w1 ; f (w1); : : : ; wk ; f (wk )) such that w1 ; : : : ; wk generate D. We call a wi from W a witness element. We say that f 2 F is secure w.r.t. W , if there exists an adversary Ad0 given capability Cap that can successfully attack f given W then there exists an adversary Ad with capability Cap that can successfully attack f without being given W , where: (A) The time and space resources of Ad are polynomially bounded in terms of those of Ad0. (B) Other resources are the same (C) For every constant k for large enough n the probability of success of Ad and the probability of successful attack of Ad0 dier by at most n1k . (Thus, since (n) is a bound on Ad0 , then Ad is successful by less than (n) + n1k .)

NOTE: It is easy to see that due to the algebraic structurei i

of f , given only f (wj ) one can compute f (wj ) = f (wj ) for any integer i and any witness element wj . This is an important property used in this paper. De nition 8 . We say a family of groups G has the approximable group order property, if there exists a probabilistic polynomial time approximator A when given public information about a group G 2 G returns an approximation aG such that for a set of generators w1 ; : : : ; wk the distribution of frr 2R Gg is rstatistically (perfectly) indistinguishable from fw11  : : :  wkk gri 2R ZaG . The approximator does not necessarily need to return a value close to the order of the group but rather a value close to a multiple of the order of the group. Let us give an example. Lemma 1 Let Zh = fnjn = pq; and length(p) =length(q) = h=2g de ne the family of multiplicative groups Zn . Then Zh has the group order approximation property. Proof. Let A takes as input n and return aZn = n. In [DDFY94] it was demonstrated that A = frgr2R f0;:::;n?1g is indistinguishable from B = frgr2R f0;:::;(n)?1g when n is chosen in the above form. Let w1 ; : : : ; wk generate the

group1 . If there exists a distinguisher for the distribution of

frgr2R Zn and fwr  : : :  wkrk gri 2R f ;:::;n? g then this distinguisher can be used to distinguish between fAg and fBg. 1

0

1

1

2

A contradiction.

3 Random oracle approach

Protocol 1 The random oracle approach Let  be the security parameters. Let F be a family

of cryptographic functions whose domains are from a family of groups with the group order approximation property. Let f 2 F be a group homomorphism over nite group D(
), aD be D's group approximation number. Let f be secure given witness W = fw1 ; W1 = f (w1 ); : : : ; wk ; Wk = f (wk )g as in De nition 7. Let v = 2 log(1=) and H : f0; 1gn ! f0; 1g2n+4 be a random oracle.

Input:  Protocol:

1. C generates r1;0 ; : : : ; r1;k ; : : : ; rv;0 ; : : : ; rv;k 2

ZaD 2. C sendr to P 0 the tuple (; z1 ; : : : ; zv ) where zi = ri; w1i;


wkri;k . 3. if  2 CapI;Hist , P 0 outputs tuple (y = P (); o1 = H (P (z1)); : : : ; ov = H (P (zv ))), otherwise NULL 4. C veri esr for all ri that H (qi ) = oi where qi = yri;
W1 i;


Wk i;k 0

1

1

Theorem 1 Let ;  be the security parameters. The system 0 (C; P ; P; f ) de ned in Protocol 1 is a cryptographic program checking system.

Proof. Lemma 2 Given only ; z = 0r ; wr ; wr ; : : : wkr ;k , the probability that an adversary P can convince C to accept a value for y = 6 f () is at most 2=3. 1

Given the information ; z1 = r ; b, the distribution on r1;0 is statistically indistinguishable from the uniform distribution (inrthe sense of de nition 6) on 0; : : : ; order(D) ?1 where b = w1 ; w2r ; : : : wkr ;k . Note that q1 = yr ; f (b) = yr ; f (?r ; z1 ) = r ; f (z1) where = y=f (). 0 The adversary P can choose because he knows  and can choose y. Therefore the adversary has exactly the power to determine in what set S1; the value q1 lies where: S1; = f r0 ; f (z1 )gr0 ; 2f0:::ord( )?1g 1 0

1 1

1 2

1

1 0

We start by assuming a random oracle is available (e.g. a globally accessible pseudorandom hardware device, in practice). Random oracles have been suggested in several applications. [BR93] suggest an instantiation based on the MD-5 cryptographic hash function. The general idea of the approach is for C to provide two elements to P :  and z . Here  is the input and z is a random element based on  and the witness elements W . The element z is created in such a manner that given f () and W , C can itself generate f (z ) (based on the NOTE from Section 2.3). P who is suppose to output (y = f ();o01 = f (z )) can not cheat because it can not predict how random z was generated. This is similar to a random self reducability approach in computing z . To prevent C from cheating, due to the homomorphic properties of f , o1 = H (f (z )) (where H is a random oracle) is output instead of o01 .

0

Proof.

1 0

1 1

1

2

1 2

1

1 We note that the maximum number of generators actually needed is two.

1 0

1 0

1 0

1 0

1 0

Furthermore, by our de nitions of the approximable group order property, we have that the distribution on q1 within S1; is statistically indistinguishable from the uniform distribution. Because the random oracle H produces 2n +4 bits where each input has n bits, the probability that H has any collisions for n bit inputs is less than 1=(2n 16). Therefore, the probability of any collisions within any of the sets S1; is less than 1=16. If there are no collisions within any of the sets S1; , then choosing the correct value of H (q1 ) is equivalent to choosing the correct value of r modulo the order of . Therefore, given y 6= f (), we have that even an unbounded computational adversary can not compute o1 such that C will accept with probability greater than 1=16+1=ord( )  1=6+1=2 = 2=3.

2

Corollary 1 The above protocol satis es the cryptographic program checker (CPC ) requirements for security against P 0. Proof.

With probability close to 1, all values of zi used in the protocol are distinct. In this case, the protocol requires that P 0 provide hash values for k dierent values of qi and P 0 must guess values of qi from k dierent sets Si; for some . Because the variables ri;0 are independent, the identities of qi within the sets Si; are also independent. So we have that the probability that C accepts an incorrect y is at most (2=3)k . So we can have k = 2 log(1=).)

2

We now complete the proof by showing that Protocol 1 satis es the rest of the requirements of a cryptographic program cheker (CPC). Security against C Let x = (1; f (1 ); : : : ; s; f (s)) 2 L where i 2 CapI;Histi . The security assumed is (n; Cap). We show that given x 2 L, simulator MC  can generate a checker's view of the interaction in Protocol 1 which is indistinguishable (see de nition 6) from the real interaction between a checker and program owner. The0 simulator simply generates from H; i ; f (i) the o0j;i = H (qj;i ) (1  j  v) where qj;i = 0 0 0 0 0j;0;i rj;0 1;i rj;k;i r f (i) W1 : : : Wk = f (irj;0;i w1rj;1;i : : : wkrj;k;i ) and rj;i 2R f0; : : : ; aD ? 1g. Now the view (1 ; f (1 ); o01;1 ; : : : ; o0v;1; : : : ; f (v ); o01;s ; : : : ; o0v;sg 0 in is indistinguishable from a real interaction since the ri;c;j the simulation are chosen from same distribution as those

in the real interaction. Hence if Protocol 1 above is insecure against C , namely, in nitely often it enables advantagek which is bounded away from (n; Cap), i.e., (n; Cap)+1=n advantage for some constant k, while restricted access f is  secure given W , then there would be a distinguisher (by by-now standard techniques) between the real interaction and the simulated interaction which will distinguish with polynomial probability. This is a contradiction. Is the access to the oracle H in contradiction with the de nition of security of f restricted adversary? The answer is no (in a nut-shell, since answers of an random oracle can be simulated by random coins, for any system whose life is polynomial-time). Time-bounded The only actions performed are ecient multiplications and exponentiations in the domain assumed to be polynomial time, whereas the function evaluation is assumed to be intractable (not in polynomial-time). This completes the proof. 2

4 Interactive approach We now provide an interactive solution using witnesses. In the previous (random oracle) approach, P 0 hid P (zi;1 ) from C by using a random oracle because C may have generated veri cation strings in a manner in which it (C ) could compute P (0) for an 0 62 CapI;Hist due to the homomorphic property of f . The general idea in the interactive protocol is for C to prove to P 0 that it generated the veri cation string zi in the correct rmanner r(i.e., C knows ri;0 ; : : : ; ri;k such that zi = ri;0 w1i;1


wki;k ). Once P 0 knows that the zi are generated in the correct form it can provide P (zi ).

Protocol 2 The interactive approach Let ;  be the security parameters. Let F be a family of cryptographic functions whose domains are from a family of groups with the group order approximation property. Let f 2 F be a group homomorphism over nite group D(
), aD be D's group approximation number. Let f be secure given witness W = fw1 ; W1 = f (w1 ); : : : ; wk ; Wk = f (wk )g as in De ni=) and v2 = 2 log(1= ). tion 7. v1 = 2log(1 log(1= )

Input:  Protocol:

1. C : (a) C generates

fr i;l ; gi2f :::v g;l2f :::kg 2R f0; : : : ; aD ? 1g, fr i;l ;j gi2f :::v g;l2f :::kg;j2f :::v g 2R f0; : : : ; aD ? 1g. (

)1

1

(

2

0

1

)

1

0

1

2

2

(b) C sends to P 0 the tuple (;z1;1 ; : : : ; zv1 ;v2 ) where zi;j = r(i;0);j w1r(i;1);j : : : wkr(i;k);j

2. P 0 : If  2 CapI;Hist , P 0 returns U = (u1;2; ; : : : ; u1;v2 ; ; : : : ; uv1 ;2 ; : : : ; uv1;v2 ) where ui;j 2R f0; 1g. 3. C responds for 1  i  v1 and 2  j  v2 with  fresponse(i;l);j gl2f0:::kg = fr(i;l);j gl2f0:::kg , if ui;j = 0  fresponse(i;l);j gl2f0:::kg = fr(i;l);j + r(i;l);1 gl2f0:::kg , if ui;j = 1 4. P 0 veri es  if ui;j = 0, then zi;j = response(i;0);j kl=1 wlresponse(i;l);j  if ui;j = 1, then zi;j zi;1 = response(i;0);j kl=1 wlresponse(i;l);j 5. P 0 responds NULL if any veri cations fail. Otherwise, P 0 responds: y = f (); foi = f (zi;1 )gi2f1:::v1 g .

Q

Q

6. C veri es that oi = yr(i;0);1 W1r(i;1);1 : : : Wkr(i;k);1 for all i 2 f1 : : : v1 g.

Theorem 2 Let ;  be the security parameters. The system 0 (C; P ; P; f ) de ned in Protocol 2 is a cryptographic program checker.

Proof. Lemma 3 Given only ; z ; = r ; ; wr ; ; : : : wkr ;k ; , fresponse ;l ;j gl2f :::kg;j2f :::v g , the probability that an adversary P 0 can convince C to accept a value for y = 6 f () is (1 0) 1

11

(1 )

1

1

(1 1) 1

1

(1

) 1

2

at most 2=3. Proof. (sketch) Given the information ; z1;1 = r(1;0);1 b, the distribution on r(1;0);1 modulo order(D) is statistically indistin-

guishable from the uniformr distribution on the values 0; : : : ; order(D) ?1 where b = w1(1;1);1 : : : wkr(1;k);1 . 0 We now consider what happens when P also learns fresponse(1;l);j gl2f0:::kg;j2f2:::v2 g . Because the values fresponse(1;l);j gl6=0;j2f2:::v2 g yield no information about response(1;0);1 ; we will consider only the information given by fresponse(1;0);j gj2f2:::v2 g . For those values response(1;0);j = r(1;0);j , P 0 learns nothing about the value r(1;0);1 . Therefore, we will assume that all v2 ? 1 values are of the form: response(1;0);j = r(1;0);j + r(1;0);1 . If we view fresponse(1;0);j gj2f2:::v2g as a random variable that is a function of r(1;0);1 , then for any two values r(1;0);1 , r(10 ;0);1 ; we have: 0 r(1 0) 1

; ; fresponse ; ; Diff (fresponse(1;0);j grj2f; 2:::v (1;0);j gj 2f2:::v g ) g < 2v2 aD =a2D P where Diff (X;Y ) = all values a [jProb[X = a] ? Prob[Y = a]j] and the observation is made by viewing the two distributions as overlapping v2 ? 1-dimensional boxes. Therefore, the probability that even a computationally unbounded P 0 learns any information about r(1;0);1 from fresponse(1;0);j gj2f2:::v g is very low. So we have that the distribution on r(1;0);1 modulo allowbreak order(D) given fresponse(1;0);j gj2f2:::v g and z1;1 is statistically indistinguishable from the uniform distribution on f0 : : : order(D) ?1g. Forr y 6= f (), de ne q = yr ; ; f (b) = yr ; ; W1r ; ; : : : Wk ;k ; . If C accepts, then P 0 must compute o1 = q. (1 0) 1

2

2

2

2

(1 0) 1

(1 0) 1

(1

(1 1) 1

) 1

We have:

q=f (z1;1 ) = (y=f ())r

; ;

(1 0) 1

Therefore, we have shown that if a computationally un0 can compute a correct value for q then this bounded P P 0 can compute a correct value for r(1;0);1 modulo ord( = y=f ()). This latter feat can be accomplished with probability at most 1=ord( ) + small statistical terms  2=3.

2

Corollary 2 The above protocol satis es the CPC require0 ments for security against P . This follows from the variables in the tuples being independent. 2

Proof.

Security against C : The proof is similar to that in Theorem 1 Let x = (1; f (1 ); : : : ; v ; f (v )) 2 L where i 2 CapI;Histi . We show that given x 2 L, simulator MC  can generate a checker's view of the interaction in Protocol 1 which is indistinguishable from the real interaction between a checker and program owner. The idea is that the additional interaction can be simulated by standard techniques in polynomial time. First C is challenged at random, then the computation is rewind and it is challenged again. The result is that the set of exponents used by C gets known to the simulator, now given W and the exponents and 's the simulator computes exactly what is required. Now the view generated as above is indistinguishable from a real interaction since the checkers randomness in the simulation is chosen from same distribution as the checker in

the real interaction. Hence if Protocol 2 is insecure against C , and restricted access f is secure given W there would be a distinguisher between the real interaction and the simulated interaction. This is a contradiction. Time bound: The only interaction action performed are ef cient multiplication and exponentiation in the domain assumed to be polynomial time, whereas the function evaluation is assumed to be not in polynomial-time. This completes the theorem 2

The minimal amount of interaction is needed to assure the security unless the function result is trivial (BPP). This can be shown by using the result in [GK], using the fact that assuming the result is given as input that is let a language L be f(; f (); W )j 2 Dg = L, then the Protocol 2 is a zeroknowledge interactive proof for it (in fact what was hard to show is that it is indeed an interactive proof, whereas the zero-knowledge aspects were easier). We note that the above interactive protocol can be made into a non-interactive protocol by using a by-now standard self-challenging idea introduced by Fiat and Shamir [FS86], assuming a random oracle. Simply rather than wait to a challenge U = (u1;2 ; : : : ; uv1 ;v2 ) in step 2, U is computed by applying the random oracle to the message Z computed in step 1, so steps 1,2, and 3 are combined into one message. (Rather than in an abstract setting, in an application context, where devices with pseudorandom function are available, the above methodology makes sense).

5 A Multi-prover Checker Approach We now investigate models that require less interaction and do not require random oracles. To bypass the impossibility results of [GK] (assuming the function result validation is an intractable problem), our employ multiple provers, some of which are trusted. We now de ne two dierent types of cryptographic program checking systems for multiple provers. De nition 9 (t; l)-Multi-prover Cryptographic program

checker - Type 1 & Type 2 Let f 2 F operate on inputs of size n. The checking security parameter is  = (n) where n is the size of inputs to a given f 2 F (in0 our case,  = 0). 0

A system (C; P0 ; : : : ; Pl?1 ; f ) is a Cryptographic Program Checking system for f if: 0 0 ( C; P 0 ; : : : ; Pl?1 ) is a system of programs where C and P00 ; : : : ; Pl0?1 have inputs x. C also has input y which is supposedly equal to f (x). The provers, P00 ; : : : ; Pl0?1 , have collective knowledge of f and can all interact (based on their type):  Type 1 : only with C .  Type 2 : privately with C or via an authenticated bulletin board. The system satis es the good following further constraints: There exists C = C such that the system satis es the following properties: For all x and for all subsets S  f0 : : : l ? 1g, there exist 0 gi2S , running in time o(time(f )), a set of programs fPi;good such that if y = f (x); then C will accept with probability at least 1 ? .

0 g , Furthermore, for all Cbad and for all programs fPi;bad i2S the protocol can be simulated. (zero-knowledge style).

Conceivably, there could be other types - for instance, a type in a which more general access structures to determine which checkers can determine the function, types in which multiple rounds and security against the provers being all evil, and, maybe a type in which only one entity knows how to compute function and rest of provers can not learn how to compute function. It is an interesting problem to see what other types of multi-prover cryptographic functions can be developed. The protocols below are based on properties presented in [DDFY94] that are sucient to make a function shareable. In particular, these properties are share translation (i.e., function family satis es condition fa(x)fb(x) = fa+b (x)), share eciency (i.e., key space for family of functions is sampleable and key space operations are ecient) and, when necessary, simulateability2 (i.e., there is a key space that can be simulated given only public knowledge). The protocols employ the witness-based approach. First, we present a Type 1 scheme.

Protocol 3 A (pn; 2n)-Type 1 protocol Let F be a family of functions that satis es the sucient conditions of [DDFY94], described above. Let fk 2 F (i.e., fk is a particular function in F indexed by key k) be the function to be checked. Let K be the simulatable key space.

Pre-processing: The0

provers

are

fPi;j gi2f ::: png;j2f :::png 1

2

1

grouped

as

follows:

The shares of the secret key k are distributed to the provers as follows: Pi;j0 gets share ai;j 2R K where 8i; nj=1 ai;j = k.

P

Input: ; y Run-time Protocol:

0 the input  1. C sends to each Pi;j 0 : If  2 CapI;Hist , Pi;j 0 outputs bi;j = fa () 2. Pi;j i;j p

n bi;j g 3. C accept k i the majority of fj=1 i2f1::: 2png equals y.

The correctness of the above protocol follows from the share translation property. Theorem 3 The system (C; P00 ; : : : ; Pl0?1; f ) de ned in Protocol 3 is a Type 1 multi-prover cryptographic program checker. 2 In [DDFY94] the shared function may not have acted upon the simulateable key space and therefore another other function very similar to f was introduced. For simplicity, we assume that the checked function acts on the simulatable key space in order to avoid introducing extra notation as in [DDFY94].

We now present a Type 2 scheme. This checking system allows for many more evil provers. As in the previous protocol, there is a matrix of values such that the sum of each row equals k. However, for each element ai;j of the matrix, there are 2 log(n) dierent provers given ai;j who provide C with the value fai;j (). The matrix is 20n by n1= . [AGY95] proved that for most random assignments of n provers to matrix values, for every subset S of provers of size (1=2 + )n, we have:  For all 2rows i, there exists j such that all provers 0 g log(n) given ai;j are members of S . fPi;j;m m=1  For at least 90 percent of the rows i, for all j , there is at least one member of S who knows the value ai;j .

Protocol 4 A ((1=2 ? )n; n)-Type 2 protocol Let  be the security parameter. Let F be a family of functions that satis es the sucient conditions of [DDFY94]. Let fk 2 F (i.e., fk is a particular function in F indexed by key k) to be checked. Let K be the simulatable key space.

Pre-processing: Let the values fai;j g, which are random shares of the 0

secret key k, be distributed to all provers Pi;j;m in an assignment as described above. For all values m 2 f1 : : : 2 log(n)g,

Input: ; y Protocol:

0 the input  1. C sends to each Pi;j;m 0 : If  2 CapI;Hist , broadcast (i; j; m);bi;j = 2. Pi;j;m fai;j (). 0 3. If Pi;j;m sees a broadcast (i; j;m0 ); bi;j;m0 such that bi;j 6= fai;j (), then broadcast challenge (i; j;m); ci;j;m = ai;j . 4. C : For those bi;j values that are challenged, determine if fci;j;m (g) = fai;j (g) and, if so, compute bi;j = fci;j;m (). 1= Accept i the majority of fnj=1 bi;j gi2f1::: 20ng equals y.

The correctness of the above protocol follows from the share translation property. Theorem 4 Let  be the security parameter. The system (C; P00 ; : : : ; Pl0?1 ; f ) de ned in Protocol 4 is a Type 2 multiprover cryptographic program checker.

6 Application: robust function sharing As discussed in the introduction, [DDFY94] presented the concept of sharable functions as a means in which to distribute a function so that it can be computed eciently by a

quorum of agents holding pieces of the function, and activating their pieces to get partial results. When a polynomialtime combiner obtains a quorum of the partial results it can easily (and without any secret information) compute the function result. In particular, the idea is to minimize interaction of the agents with the combiner, and ideally to do it in a non-interactive fashion as advocated in [DDFY94]. The major source of ineciency of the protocol is the method in which to determine if shadow function holders performed their computation correctly (e.g. using non-interactive zeroknowledge method is by many orders of magnitude inecient when compared to all the other computations). The basic idea of function sharing is the following. Shadow function holders are provided with a shadow functions Pi for a function fd (i.e., a cryptographic algorithm indexed by key d) such that for a given input  any t partial results, Pi1 (); : : : ; Pit (), can be used to generate fd (). It was also proved that nothing was learned about fd during the protocol then would have been learned from P (). One particularly troubling area is how to determine if one or more of the partial results was computed wrong. Indeed, [RB94] discussed this concern in an application of function sharing to construct replicated services in a network that maintain their availability and integrity even when some of the servers and clients have been corrupted by an adversary. One may even say that function sharing is more prone to errors since to compute a function multiple entities are needed (each with the potential of presenting the wrong output). Moreover when there are l total entities (shadow function holders) and t = l=2 entities de ne a quorum which can compute the function, if l agents output their partial results for an input  and l=2 of their outputs are wrong it could take exponential trials to compute the output for each of the l=2 size subsets and verify if their output is correct. Using non-interactive proofs is polynomial but extremely inecient. Our approach in this paper is to verify the correctness of each of the partial results on an individual basis. That is we treat each Pl as a separate program owner P 0 . We will discuss the non-interactive solution only in our discussion below, but all our protocols apply. We show Theorem 5 If there is a sharable function which is homomorphic and its domain has the group order approximation property, then there is an \ecient robust sharable function". The basic idea is that in the key generation phase the key will include the witness set computed for each agent. This will enable the combining of the results to rst check its correctness (via the protocols presented here) and then to combine the correct result. Let us next brie y review the most important aspects of the [DDFY94] RSA protocol. We skip some of the steps presented in [DDFY94] since our goal here is to demonstrate the applicability of our protocols rather than present for the general case (though our approach does work for the general case under the conditions of the Theorem above). Let Fh de ne a family of RSA functions such that its elements are fd ()  d mod n where n = pq for primes p; q of length h=2 and gcd(d; (p ? 1)(q ? 1)) = 1. We treat d as an element in Z(n) (+) where (n) = (p ? 1)(q ? 1) is the order of the multiplicative group Zn . Our rst step is to extend Z(n) by the element u to obtain Z(n) [u] where u is a root of

P

?1 xi the cyclotomic polynomial p(x) = xq ? 1=(x ? 1) = qi=0 and q is a prime greater than l, the number of shareholders. Next, using Lagrange interpolation shares si of the secret d 2 Z(n) [u] are given. Each shareholder i, associated with a public interpolation point3 xi = ij?=01 ui , is provided with the share si = si;0 + si;1 u + : : : + si;q?2 uq?2 = r(xi ) where r is a random polynomial of degree t ? 1 over the module Z(n) [u](+) with scalar Z(n) [u](
) such that r(0) = d, the secret key. The shareholder's shadow functions are Pi (x) = [fsi;0 (x); : : : ; fsi;q?2 (x)] and a partial result for input  is Pi (). The value of fd () is obtained by using Lagrange interpolation in Zn [u] with t interpolation points Pi1 (); : : : ; Pit (). (See [DDFY94] for more details).

P

Robust function sharing of RSA

We now discuss how to use our cryptographic checking protocol to check that this program is functioning4 correctly. We rst note that the Pi are the homomorphic : Pi(1  2 ) = [fsi;0 (1  2 ); : : : ; fsi;q?2 (1  2 )] = [fsi;0 (1); : : : ; fsi;q?2 (1 )]
[fsi;0(2 ); : : : ; fsi;q?2 (2 )] = Pi(1 )
Pi(2 ). We also observe that for RSA that the the function is secure when given witness W . The other property that we need is that the domain satis es the group order approximation property. In Lemma 1 it was shown that that approximator A(n) = aZ(n) = n satis es the properties of De nition 8. Hence, we have shown that RSA function sharing meets all the conditions necessary to use the witness based cryptographic program checking protocols discussed in this paper. The multi-prover approaches follow from the sucient properties: share translation, share ecient, and simulateable. This is discussed in more detail in [?].

Conclusion A new concept of cryptographic program checking which is based on the elegant notion of program result checking is introduced in this paper. In our model not only do we assure that the output of a program is correct but also that the checker can not cheat. Hence, unlike the more traditional program checking model, there are two adversaries: the program and the checker. Several applications for cryptographic program checking are also discussed in the paper. Instantiations of cryptographic program checking for homomorphic functions are provided which are interactive, or non-interactive but use a random oracle or multiple provers.

References [AFK87] M. Abadi, J. Feigenbaum, and J. Kilian, On Hiding Information from an Oracle, STOC 87. [AGY95] N. Alon, Z. Galil and M. Yung, Dynamic-resharing Veri able Secret Sharing, ESA 95. [BR93] M. Bellare and P. Rogaway, Random Oracles are Practical: a paradigm for designing ecient protocols, ACM, 1-st Comp. and Com. Sec. 1993. [Blum88] M. Blum, Designing programs to check their work, ICSI technical report TR-88-009. 1 3 ?1 xi is chosen this way so that x? 6 j) i and (xi ? xj ) (for i =

exist. This is not relament to our discussion but is necessary for the Lagrange interpolation to work correctly and securely. 4 We treat this as a multiplicative homomorphism though [DDFY94] would have treated it as additive.

[BEGKN91] M. Blum, W. Evans, P. Gemmell, S. Kannan, M. Naor. Checking the Correctness of Memories. In the 32nd Annual Foundations of Computer Science Conference, Puerto Rico, pp 90-99, October 1991. [BLR90] M. Blum, M. Luby, and R. Rubinfeld , Self testing/correcting with applications to numerical problems, Journal of Computer and Systems Science, Vol 47, pp. 549-595, 1993. Preliminary version: The Proceedings of the 22nd ACM Symposium on the Theory of Computing (STOC), pp. 73-68, 1990. [BK89] M. Blum and S. Kannan, Designing programs that check their work, Proceedings of the 21st ACM Symposium on the Theory of Computing (STOC), pp. 86-97, 1989. [BW95] M. Blum and M. Wasserman, Software reliability via run-time result checking, 35th IEEE Foundations of Computer Science (FOCS), 1994. [CvA89] D. Chaum and H. van Antwerpen, Undeniable Signatures, Advances in Cryptology, Proc. of Crypto '89 (Lecture Notes in Computer Science 435), pages 212-216, 1990. [DS94] D. E. Denning and M. Smid, Key Escrowing Now, IEEE Communications Magazine, Sep. 1994, pp. 54-68. [DDFY94] A. De Santis, Y. Desmedt, Y. Frankel, and M. Yung, How to Share a Function Securely, Proceedings of the ACM Symposium on the Theory of Computing (STOC), pp. 522-533, 1994. [DF89] Y. Desmedt and Y. Frankel, Threshold cryptosystems, Advances in Cryptology, Proc. of Crypto '89 (Lecture Notes in Computer Science 435), pages 307{315. Springer-Verlag, 1990. [FIPS185] FIPS PUB 185, Escrowed Encryption Standard February 1994. (Dept. of Commerce). [F89] Y. Frankel, \A practical protocol for large group oriented networks", Advances in cryptology, Proc. of Eurocrypt 89. pp. 56-61. [FGMY96] Y. Frankel, P. Gemmell, P. MacKenzie, M. Yung Proactive RSA Submitted to Crypto '96. Available from authors by request. (SAND report available soon). [FS86] A. Fiat and A. Shamir, \How to prove yourself: practical solutions to identi cation and signature problems" Advances in cryptology, Proc. of Crypto '86, pp. 186-194. [GK] O. Goldreich and H. Krawczyk, On the Composition of Zero-Knowledge Proof Systems, ICALP 1990. [GMR89] S. Goldwasser, S. Micali, and C. Racko, The Knowledge Complexity of Interactive ProofSystems, SIAM Journal on Computing, vol. 18, n. 1, February 1989.

[LIP91] R. Lipton, New directions in testing, distributed computing and cryptography DIAMACS series in Dis. Math and Th. Comp. Sci. vol 2, 1991, 191202. [NYT95] New York Times article (Wed., Oct. 11, 1995) on recent breaks of Netscape servers by U.C. Berekeley students: \If the application code is not secire, i.e., it can be replaced by a hacked version..." [Rub90] R. Rubinfeld, A mathematical theory of selfchecking, self-testing and self-correcting programs, Ph.D. Thesis, Univ. of California, Berkeley, 1990. [RB94] M. Reiter and K. Birman, How to securely replicate services, ACM Transactions on Programming Languages and Systems, 16(3), May 1994, pp. 9861009. [Yao90] A. Yao, Coherent functions and program checkers, Proceedings of the 22nd ACM Symposium on the Theory of Computing (STOC), pp. 84-94, 1990.