The disclosure relates to the outsourcing of computations to an untrusted third party, and to the verification of the correctness of the computation result.
When outsourcing a computation to the cloud, it is important to know that the returned computation result is correct. There are three existing approaches: outsourcing the computation to several workers and comparing the results; relying on trusted hardware that the worker has deployed; and letting the worker cryptographically prove correctness. A solution in this latter direction is the Pinocchio system for verifiable computation (as described in “Pinocchio: Nearly Practical Verifiable Computation” by B. Parno, J. Howell, C. Gentry, and M. Raykova in Proceedings of S&P, 2013) and variants. In particular, the “Trinocchio” variant (described in “Trinocchio: Privacy-friendly outsourcing by distributed verifiable computation” by B. Schoenmakers, M. Veeningen, and N. de Vreede, IACR Cryptology ePrint Archive, 2015:480, 2015) shows that correctness guarantees can be combined with multi-party computation techniques to ensure not just correctness but also privacy with respect to the worker, by outsourcing the computation to several workers that collaborate to produce the proof.
In Pinocchio/Trinocchio, a verifier asks a worker to compute a function on the inputs of its choice. However, consider a setting where the worker's computation is a query of the verifier on a sensitive database from a trusted source. For instance, consider an insurer requesting statistics on information coming from a biosensor: the sensor itself is not powerful enough to perform computation and it is not always on-line, so the computation needs to be outsourced. But then it is difficult for the insurer to be sure that the statistics use the data from the biosensor, while at the same time it is difficult for the user to be sure that the insurer does not learn any information about the sensor data apart from the statistics. Similar use cases exist in areas like smart metering and financial auditing. Alternatively, in the case of a distributed computation, two functions may refer to a shared state consisting of a number of values. For instance, this shared state may comprise values that are output by the first function and input to the second function. In this case, these values may be regarded as a trusted input of both functions. Hence, outsourcing computations are considered where, apart from the input by the verifier, there are also trusted inputs from one or more trusted sources. The verifier is supposed to learn the output of the computation and be ensured that it is correct, but it should not learn any additional information about these trusted inputs. Generically, the solution in this setting (as discussed in “ADSNARK: nearly practical and privacy-preserving proofs on authenticated data” by M. Backes, M. Barbosa, D. Fiore, and R. M. Reischuk, in 2015 IEEE
Symposium on Security and Privacy, S P 2015, San Jose, Calif., USA, May 17-21, 2015, pages 271-286, 2015 and “Geppetto: Versatile verifiable computation” by C. Costello, C. Fournet, J. Howell, M. Kohlweiss, B. Kreuter, M. Naehrig, B. Parno, and S. Zahur, in Proceedings of S&P '15, pages 253-270, 2015) is to let sources provide some sort of representation of the trusted inputs; and let the verifier check the correctness of the computation with respect to this representation. Verification requires: (1) a representation of the trusted inputs; (2) verification keys to verify this representation; (3) outputs of the computation; (4) a proof that the outputs are correct with respect to the trusted inputs; and (5) a verification key to verify the proof of correctness of the computation. Here, (2) and (5) come from a central authority (CA); (1) comes from the trusted source(s); and (3) and (4) come from the worker(s). Here, the verification key for the computation may or may not depend on the verification key for the inputs (i.e., on the particular trusted source providing the input).
The two approaches in “ADSNARK: nearly practical and privacy-preserving proofs on authenticated data” and “Geppetto: Versatile verifiable computation” may be used to prove correctness of a computation with respect to authenticated inputs in Pinocchio-type verifiable computations. One generic approach (discussed in “Geppetto: Versatile verifiable computation” and referred to as ‘the generic construction’ in “ADSNARK: nearly practical and privacy-preserving proofs on authenticated data” paper) is to use as input representation one single (constant-sized) signature over all inputs. Then the proof of correctness includes a proof that there exist a set of inputs corresponding to the signature and the computation result. The drawback of this approach is that there is a large overhead for the worker. This is because performing signature verification inside a verifiable computation is expensive.
In the alternative approach, known as ‘ADSNARK’ (which is described in “ADSNARK: nearly practical and privacy-preserving proofs on authenticated data”) there is a separate representation for each item in the input that is presented to the verifier. This representation consists of a commitment to the input and a signature on this commitment. The signatures are separately verified, whereas the commitments can be combined to verify that the underlying inputs were indeed used in the computation. This has a much smaller overhead for the worker (in particular, on one example it is 24.5 times faster than the generic solution), but it has the drawback that it introduces an overhead for the verifier, for whom storage and verification effort both become linear in the number of trusted inputs (previously, they did not depend on this number).
There is therefore a need for improvements over existing techniques and algorithms that minimises the overhead for both the worker and the verifier.
Thus, various embodiments described herein provide a new way to authenticate trusted inputs for Pinocchio and variants like Trinocchio with low overhead for both worker and verifier. A modified input representation is provided that allows trusted inputs to be represented in a constant-size representation; and a new way is provided to embed the proof that a computation corresponds to this representation of the trusted inputs into an already existing, similar, check that is already present in the proof. Hence, a single representation represents the whole data set but with less overhead. When data is from one trusted source, the solutions herein have virtually no overhead for the worker or verifier. When using data from multiple trusted sources in one computation, there is no worker overhead, but for the verifier, the proof size and verification time increase slightly better than linearly in the number of trusted sources. Therefore, compared to other solutions, the (large) worker overhead is eliminated and verifier overhead is reduced (in the case of multiple sources) or eliminated.
According to a first specific aspect, there is provided a first node for use in a system, the system comprising one or more trusted source nodes, one or more worker nodes and a verifier node, wherein the first node is configured to determine a trusted input commitment key for a trusted input to be input into a computation that is to be evaluated by the one or more worker nodes, wherein the trusted input commitment key is for use by the one or more trusted source nodes in forming a trusted input commitment of one or more trusted inputs; determine a computation evaluation key for use by the one or more worker nodes in determining a proof that a computation on one or more trusted inputs is correct and that the one or more trusted inputs were used in the computation, wherein the computation evaluation key comprises key material for one or more trusted input wires that are for inputting the one or more trusted inputs into the computation, wherein the key material is derived from a trapdoor value, one or more polynomials evaluated in a point corresponding to the trapdoor value that are independent of polynomials representing the computation, and one or more polynomials evaluated in a point corresponding to the trapdoor value that represent the computation; determine a computation verification key for use by the verifier node in verifying the result of the computation by the one or more worker nodes; and publish the trusted input commitment key, the computation evaluation key and the computation verification key.
According to a second aspect, there is provided a method of operating a first node in a system, the system comprising one or more trusted source nodes, one or more worker nodes and a verifier node, wherein the method comprises determining a trusted input commitment key for a trusted input to be input into a computation that is to be evaluated by the one or more worker nodes, wherein the trusted input commitment key is for use by the one or more trusted source nodes in forming a trusted input commitment of one or more trusted inputs; determining a computation evaluation key for use by the one or more worker nodes in determining a proof that a computation on one or more trusted inputs is correct and that the one or more trusted inputs were used in the computation, wherein the computation evaluation key comprises key material for one or more trusted input wires that are for inputting the one or more trusted inputs into the computation, wherein the key material is derived from a trapdoor value, one or more polynomials evaluated in a point corresponding to the trapdoor value that are independent of polynomials representing the computation, and one or more polynomials evaluated in a point corresponding to the trapdoor value that represent the computation; determining a computation verification key for use by the verifier node in verifying the result of the computation by the one or more worker nodes; and publishing the trusted input commitment key, the computation evaluation key and the computation verification key.
According to a third aspect, there is provided a worker node for use in a system, the system comprising a first node, one or more trusted source nodes and a verifier node, wherein the worker node is configured to obtain a computation evaluation key for a computation to be performed by the worker node, wherein the computation evaluation key comprises key material for one or more trusted input wires that are for inputting the one or more trusted inputs into the computation, wherein the key material is derived from a trapdoor value, one or more polynomials evaluated in a point corresponding to the trapdoor value that are independent of polynomials representing the computation, and one or more polynomials evaluated in a point corresponding to the trapdoor value that are dependent on polynomials representing the computation; receive one or more trusted inputs for the computation; evaluate the computation using the received one or more trusted inputs to determine values for one or more internal wires of the computation and one or more output wires of the computation; and determine a proof that the computation on the one or more trusted inputs is correct and that the one or more trusted inputs were used in the computation using the computation evaluation key.
According to a fourth aspect, there is provided a method of operating a worker node in a system, the system comprising a first node, one or more trusted source nodes and a verifier node, wherein the method comprises obtaining a computation evaluation key for a computation to be performed by the worker node, wherein the computation evaluation key comprises key material for one or more trusted input wires that are for inputting the one or more trusted inputs into the computation, wherein the key material is derived from a trapdoor value, one or more polynomials evaluated in a point corresponding to the trapdoor value that are independent of polynomials representing the computation, and one or more polynomials evaluated in a point corresponding to the trapdoor value that are dependent on polynomials representing the computation; receiving one or more trusted inputs for the computation; evaluating the computation using the received one or more trusted inputs to determine values for one or more internal wires of the computation and one or more output wires of the computation; and determining a proof that the computation on the one or more trusted inputs is correct and that the one or more trusted inputs were used in the computation using the computation evaluation key.
According to a fifth aspect, there is provided a verifier node for use in a system, the system comprising a first node, one or more trusted source nodes and one or more worker nodes, wherein the verifier node is configured to obtain a trusted input verification key and computation verification key; obtain, from the one or more trusted source nodes, a trusted input commitment, the trusted input commitment comprising a representation of one or more trusted inputs that have been input by the one or more trusted source nodes to a computation; obtain, from one or more worker nodes, an output of the computation and a proof that the computation on the one or more trusted inputs by the one or more worker nodes is correct and that the one or more trusted inputs were used in the computation; and determine whether the computation on the one or more trusted inputs is correct and whether the trusted inputs were used in the computation using the obtained trusted input verification key, obtained computation verification key, obtained trusted input commitment and obtained proof.
According to a sixth aspect, there is provided a method of operating a verifier in a system, the system comprising a first node, one or more trusted source nodes and one or more worker nodes, wherein the method comprises obtaining a trusted input verification key and computation verification key; obtaining, from the one or more trusted source nodes, a trusted input commitment, the trusted input commitment comprising a representation of one or more trusted inputs that have been input by the one or more trusted source nodes to a computation; obtaining, from one or more worker nodes, an output of the computation and a proof that the computation on the one or more trusted inputs by the one or more worker nodes is correct and that the one or more trusted inputs were used in the computation; and determining whether the computation on the one or more trusted inputs is correct and whether the trusted inputs were used in the computation using the obtained trusted input verification key, obtained computation verification key, obtained trusted input commitment and obtained proof.
According to a seventh aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform any of the method aspects set out above.
These and other aspects will be apparent from and elucidated with reference to the embodiment(s) described hereinafter.
Exemplary embodiments will now be described, by way of example only, with reference to the following drawings, in which:
Where the techniques and principles described herein are applied to Pinocchio, the system 2 comprises a single worker node 8 that performs the computation. Where the techniques and principles described herein are applied to Trinocchio, the system 2 comprises two or more worker nodes 8 that cooperate to perform the computation.
Broadly, the system 2, particularly the central authority node 4 and the one or more worker nodes 8, are provided to perform a computation on one or more items of input data (also referred to herein as a trusted input or trusted input data) provided by the input node 6. The correctness of the output of the computation is verified by the verifier node 10.
In some embodiments, the verifier node 10 may request that the computation is performed on trusted input data owned or stored by the input node 6, and the input node 6 can provide the trusted input data as an input to the computation without the worker node(s) 8 or verifier node 10 learning the content of the data.
In some embodiments, the input node 6 may request a computation on its trusted input data, and the verifier node 10 can verify that the computation is (or was) performed correctly.
In some embodiments, the verifier node 10 may also provide an input to the computation along with the trusted input from the input node 6.
Each of the nodes 4, 6, 8, 10 are interconnected to enable data and information exchange therebetween, for example via a network, such as the Internet, although one or more of any of the nodes 4, 6, 8, 10 may be co-located or otherwise interconnected via a local area network.
Each of the nodes 4, 6, 8, 10 can be in the form of any type of computing device or electronic device, such as a computer, a server, a laptop, a tablet, a smartphone, etc.
According to
The node further includes a processing unit 22 for performing operations on data and for generally controlling the operation of the node. The interface circuitry 20 may be connected to the processing unit 22. The node further includes a memory unit 24 for storing any data required for the execution of the techniques described herein and for storing computer program code for causing the processing unit 22 to perform method steps as described in more detail below and as appropriate for the role that the node 4; 6; 8; 10 has in the system 2. The memory unit 24 may be connected to the processing unit 22.
The processing unit 22 can be implemented in numerous ways, with software and/or hardware, to perform the various functions described herein. The processing unit 22 may comprise one or more microprocessors or digital signal processor (DSPs) that may be programmed using software or computer program code to perform the required functions and/or to control components of the processing unit 22 to effect the required functions. The processing unit 22 may be implemented as a combination of dedicated hardware to perform some functions (e.g. amplifiers, pre-amplifiers, analog-to-digital convertors (ADCs) and/or digital-to-analog convertors (DACs)) and a processor (e.g., one or more programmed microprocessors, controllers, DSPs and associated circuitry) to perform other functions. Examples of components that may be employed in various embodiments of the present disclosure include, but are not limited to, conventional microprocessors, DSPs, application specific integrated circuits (ASICs), and field-programmable gate arrays (FPGAs).
The memory unit 24 can comprise any type of non-transitory machine-readable medium, such as cache or system memory including volatile and non-volatile computer memory such as random access memory (RAM) static RAM (SRAM), dynamic RAM (DRAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), and electrically erasable PROM (EEPROM).
It will be appreciated that a practical implementation of any of the central authority node 4, input node 6, worker node 8 and verifier node 10 may include additional components to those shown in
As noted above, various embodiments described herein provide a new way to authenticate trusted inputs for Pinocchio and variants like Trinocchio with low overhead for both worker and verifier. The techniques described herein provide a modified input representation that allows trusted inputs to be represented in a constant-size representation; and a new way to embed the proof that a computation corresponds to this representation of the trusted inputs into an already existing, similar, check that is already present in the proof. This means that a single input representation represents the whole data set, but with less overhead.
In more detail, the techniques described herein re-use Pinocchio's “linear combination consistency check” such that it not just enforces internal consistency of the proof, but also consistency of the proof with a representation of the trusted inputs. In Pinocchio, computations are modelled by quadratic equations. For instance, for an input x1, a prover needs to compute x2=(x1)3. Then x2 is correct if and only if there exists internal wire value x3 (i.e. a part of the computation) such that x3=x1·x1 and x2=x3·x3. When a prover in Pinocchio is asked to compute this function for an input x1, it returns x2 in the clear; an encoding of x3; and a proof that x1; . . . ; x3 satisfy the given quadratic equations.
Specifically, the encoding of internal wires xm+1; . . . ; xn contains four terms:
where the elements Vi, Wi, Yi and β·(Vi+Wi+Yi) are homomorphic encodings using an additively homomorphic encoding scheme. For instance, a value x may be encoded as x·g, with g the generator of a discrete logarithm group (seen as an additive group) on which a symmetric cryptographic pairing is defined. This implies that, given encoding B of β, where β is the discrete logarithm of β·(Vi+Wi+Yi) with respect to Vi+Wi+Yi; V; Wi and Yi it is not feasible to compute γ=β·(Vi+Wi+Yi), but it is possible to check if γ indeed encodes the product of the values encoded by B and Vi+Wi+Yi. Alternatively, a value x may be encoded using an additively homomorphic encryption scheme such as Paillier. In this case, a verifier that knows the secret key of the additively homomorphic encryption scheme can check if γ encodes the product of the values encoded by B and Vi+Wi+Yi by decrypting the decoded values and verifying the relation on the plaintexts. In any case, B, Vi, Wi, Zi and β·(Vi+Wi+Zi) are generated once by the central authority node 4.
An honest prover uses the same xi for each of V, W, Y and Z, but a corrupted prover may use different values for xi in order to prove correctness of an incorrect computation result. The term Z enables a linear combination consistency check that prevents this. Given B, V, W, Y and Z, any party can verify that β·(V+W+Y)=Z, which implies that all use the same xi.
Various embodiments described herein use this linear combination consistency check to prove consistency not just internally between V, W, Y and Z, but also between these elements and a representation of trusted inputs. Suppose that a computation uses input/output values x1, . . . , xl, trusted inputs xl+1, . . . , xm; and internal wires xm+1, . . . , xn. To represent the trusted inputs, elements I0, Il+1, . . . . Im are chosen (in a particular way), and the representation is defined as
for random x0. Adding x0 provides that the trusted inputs do not leak from this representation. It should be noted that the size of this representation (one element) is independent from the number of trusted inputs.
To prove that the trusted inputs represented by I were used in a particular computation, instead of elements {β·(Vi+Wi+Yi)}i=m+1n for Z above, we use:
{β·(Ii+Vi+Wi+Yi)}i=l+1m, {β·(Vi+Wi+Yi)}i=m+1n (6)
As before, it is checked that Z satisfies β·(I+V+W+Y)=Z. For trusted inputs, this guarantees that the same xi were used in V, W, Y and I. For internal wires of the computation, guarantees are as above.
A detailed implementation of the techniques presented herein is described below for a Pinocchio-based system (as described in a simplified form in “Trinocchio: Privacy-friendly outsourcing by distributed verifiable computation”) that enables the security of the original Pinocchio scheme to be (provably) preserved. However, it will be appreciated by those skilled in the art that the techniques presented herein can be applied to other variants of Pinocchio (including Trinocchio variants).
Pinocchio has a single worker node 8, but it is also possible, according to the techniques described herein, to distribute the computation between two or more (e.g. three) different workers 8 in a privacy-preserving way (i.e. so that no individual worker 8 learns any information about the trusted inputs or the inputs of the verifier 10) by a straightforward generalisation of Trinocchio.
Firstly, there is a one-time set-up by central authority 4. A ring is fixed over which computations take place, a maximum number of inputs/outputs l, a maximum number of trusted inputs m−l, and a maximal “degree” of computations d>m. A random trapdoor s is selected, where s∈. Two homomorphic encodings ⋅1∈1, ⋅2∈2 are defined, and a bilinear map e: 1×2→3 that can be used to verify multiplicative relations between encoded elements is also defined. Below, the homomorphic operations on 1 and 2 can be seen as addition, and the homomorphic operation on 3 can be seen as multiplication.
Specifically, as homomorphic encoding, discrete logarithm groups with a cryptographic pairing may be used. In this case, the central authority sets up discrete logarithm groups 1, 2, 3 of order || with a pairing e: 1×2→3 for which the (4d+4)−PDH, d-PKE and (8d+8)−SDH assumptions (as described in “Pinocchio: Nearly Practical Verifiable Computation”) hold. Here, 3 is again a discrete logarithm group. In this case, given generators g1 of 1 and g2 of 2 (written additively) and polynomial f∈|x|, f1 is written for f(s)·g1 and f2 is written for f(s)·g2.
Alternatively, as homomorphic encoding, homomorphic encryptions may be used. In this case, the central authority sets up a homomorphic encryption scheme with plaintext space IF and generates a private/public key pair. Homomorphic encodings ⋅1∈1, ⋅2∈2 are both defined as encryption using this public key. The bilinear map e(a1, b2) is defined by decrypting a1 and b2 to obtain a and b, respectively, and computing a·b. Hence, encodings in 3 are ring elements (where ⋅ is written for the addition operation in the ring). In this case, given polynomial f∈|x|, both f1 and f2 represent an encryption of the ring element f(s).
The central authority node 4 publishes public parameters , l, m, d, and the information required to produce encodings of ring elements according to the homomorphic encodings; it also publishes (in the case of discrete logarithm groups) or provides to the verifier (in the case of homomorphic encryptions) the information required to evaluate the bilinear map. In the latter case, the central authority node 4 does not publish the information required to evaluate the bilinear map for all nodes 6, 8, 10 as the information includes the private key used to produce the encodings, and the worker nodes 8 should not learn this key.
The central authority node 4 also ‘sets-up’ the trusted source 6. Given the trapdoor s, a random γ∈ is selected. A trusted input evaluation key (which is also referred to as a trusted input commitment key) γ·sj1 for j=l+1, l+2, . . . , m is provided to the trusted source 6 and a trusted input verification key γ2 is published.
Next, a data representation is formed by the trusted source 6. Given trusted input evaluation key γ·sj and inputs xl+1, . . . , xm, a random x0 is picked and a trusted input representation (which is also re erred to as a trusted input commitment) is returned in the form:
Next, the central authority node 4 sets up the trusted computation. Given the trapdoor s, random β, αv, αw, αy, rv, rw, ry=rv·rw∈ are picked. A set of d quadratic equations in variables x1, . . . , xn is constructed such that for inputs and outputs x1, . . . , xl and trusted inputs xl+1, . . . , xm, there exist internal wires xm+1, . . . , xn satisfying all of the equations if and only if the function has been correctly computed. These equations are written as:
(v0i+v1i·x1+ . . . +vni·xn)·(w0i+w1i·x1+ . . . +wni·xn)=(y0i+y1i·x1+ . . . +yni·xn) (8)
with i=1, . . . , d.
Distinct α1, . . . , αd∈ are selected or picked.
The following function is defined t(x)=(x−α1)⋅ . . . ⋅(x−αd).
By Lagrange interpolation, let v0(x), . . . , vn(x) be the degree ≤d−1 polynomials such that vi(αj)=vji, and similarly for wi(x), yi(x).
The following computation evaluation key is returned to the worker 8 (where c=0, . . . , d; i=1, l+1, l+2, . . . , n; j=m+1, . . . , n; k=l+1, . . . , m):
s
c)1,1,β·(rvvj+rwwj+rwwj+ryyj)1,β·(sk+rvvk+rwwk+ryyk)1,rvvi1,rvαvvi1,rvt1,rvαvt1,rvβt1,rwwi2,rwαwwi1,rwt2,rwαwt1,rwβt1,ryyi1,ryt1,ryαyt1,ryβt1,ryαyyi1, (9)
This computation evaluation key comprises several elements, a set of consistency-checking elements shown in line 1 of equation (9) which includes the additional computation-independent polynomial element sk, and computation-dependent polynomial elements for the left factor (vk), right factor (wk) and the product (yk) of the set of multiplications that form the computation. In particular, the k-indexed consistency-checking elements in line 1 of equation (9) are key material for one or more trusted input wires that are for inputting the one or more trusted inputs into the computation, and it can be seen that the key material is derived from the trapdoor value, s, one or more polynomials evaluated in a point corresponding to the trapdoor value that are independent of polynomials representing the computation (i.e. sk), and one or more polynomials evaluated in a point corresponding to the trapdoor value that are dependent on polynomials representing the computation (i.e. vk, wk, yk).
The following computation verification key is published by the central authority node 4 (where i=0, . . . , l):
αv2,αw2αy2,β1,β2,rvvi1,rwwi2,ryyi1,ryt2 (10)
The following relates to the computation by the worker 8. Given a computation evaluation key, trusted inputs and inputs from the verifier (if applicable), the worker 8 determines outputs of the computation and internal wire values of the computation such that x1, . . . , xn satisfy all of the above quadratic equations. The worker 8 generates random δv, δw, δy∈ and computes:
with i summing from 0 to n and x0=1. If the equations are satisfied, this is a polynomial.
The worker 8 returns the output of the computation and the following proof (where c=0, . . . , d; i=l+1, l+2, . . . , n; j=m+1, . . . , n; k=l+1, . . . , m, x0=1):
V
mid
1=Σixi·rvvi1+δv·rvt1, (12)
αvVmid1=Σixi·rvαvvi1+δv·rvαvt1, (13)
W
mid
2=Σixi·rwwi2+δw·rwt2, (14)
αwWmid1=Σixi·rwαwwi1+δw·rwαwt1, (15)
Y
mid
1=Σixi·ryyi1+δy·ryt1 (16)
αyYmid1=Σixi·ryαyyi1+δy·ryαyt2 (17)
Z
1=δvrvβt1+δw·rwβt1+δy·ryβt1+Σjxj·β·(rvvj+rwwj+ryyj)1+Σkxk·β·(sk+rvvk+rwwk+ryyk)1, (18)
H
1
=
h
1=Σchc·sc1 (19)
where hc are the coefficients of polynomial h.
The verification of the computation by the verifier 10 is as follows. The verifier 10 is provided with a trusted input verification key and a computation verification key from the central authority 4, a trusted input representation (commitment) from the trusted source 6, chosen inputs and obtained outputs x1, . . . , xl, and a proof from the worker 8, the verifier 10 accepts the outputs if the following hold:
e(I1,γ2)=e(γI1,12); (20)
e(Vmid1,αv2)=e(αvVmid1,12); (21)
e(αw1,Wmid2)=e(αwWmid1,12); (22)
e(Ymid1,αy2)=e(αyYmid1,12); (23)
e(I1+Vmid1+Ymid1,β2)·e(β1,Wmid2)=e(Z1,12) (24)
e(V1,W2)·e(Y1,11β2)−1=e(H1,ryt2) (25)
where V1=Vmid1+Σi=0lxi·rvvi; W2=Wmid2+Σi=0lxi·rwvw2; and Y1=Ymid1+Σi=1lx0·ryyi1 with x0=1. In the above check, the verifier 10 checks the consistency between the representations of the internal wires in the computation (Vmid, Wmid and Ymid) and that these are consistent with the trusted input representation (trusted input commitment).
It will be appreciated that it is important that the central authority 4 is distinct from the worker 8 (although the central authority 4 and trusted source 6 may be the same party). This is because the central authority 4 is technically able to produce proofs of incorrect statements and to modify trusted inputs after the trusted input representation (trusted input commitment) has been defined.
Strictly speaking, the cryptographic security proof relies on the trusted input verification/evaluation key being specific to a single trusted source 6, and the computation verification/evaluation key being specific to a single worker 8 and function. However, in practical deployments, the same keys may be used by different trusted sources 6 and workers 8.
The public parameters, trusted input evaluation (commitment) key, trusted input verification key, computation evaluation key and computation verification key can all be published without affecting the security or privacy of the algorithm. Only the trusted inputs and the outputs need to be kept secret. In practice, the central authority 4 can make the public parameters, trusted input verification key, and computation verification key open to the public by publishing them digitally signed, e.g. on a website. The central authority 4 can provide the trusted input evaluation key directly to the trusted source 6 (indicated by arrow 30 in
It will be appreciated that the arrows in
As extension to the above algorithm, trusted inputs may be provided by multiple sources. In the above algorithm, each computation involves trusted inputs from only one input source 6. The algorithm can be extended to support input from multiple sources by considering the elements
V
mid
1,αvVmid1,Wmid2,αwWmid1,Ymid1,αyYmid1,Z1 (26)
from the proof as a “commitment” to the values xl+1, . . . , xn. For each additional trusted source 6, another commitment of the form (7) is included just to the values coming from that trusted source 6, with a fresh value for β. Note that the commitment in (7) uses s-powers with exponents l+1, . . . , m whereas the inputs from another trusted source would in general have wire indices l+1+δ, . . . , m+δ for some offset δ. To account for this, evaluation key elements β·(sk+rvvk+rwwk+ryyk)1 are used. The verifier 10 repeats the checks in equations (20)-(24) for each of these commitments, and the check in equation (25) is adjusted so that values V1,W2,Y1 include the commitments. In the same way, separate commitments may be used for the inputs by the first trusted source and for the internal wires of the computation.
Thus,
As noted above, the central authority node 4 provides the keys used by the other nodes 6, 8, 10 in the system to perform a computation on a trusted input in a secure way and enable a verifier node 10 to verify the correctness of the computation.
In a first step, step 101, the central authority node 4 determines a trusted input commitment key (also referred to as the trusted input evaluation key). The trusted input commitment key will be used by an input node 6 (trusted source node 6) in forming a trusted input commitment of one or more trusted inputs.
The central authority node 4 also determines a computation evaluation key (step 103). The computation evaluation key is for use by the one or more worker nodes 8 in determining a proof that the computation on one or more trusted inputs is correct and that the one or more trusted inputs were used in the computation.
The computation includes one or more wires for inputting the trusted input (which are referred to as trusted input wires), and the computation evaluation key comprises key material for the one or more trusted input wires. This key material is derived from a trapdoor value s, one or more polynomials evaluated in (or at) a point corresponding to the trapdoor value that are independent of polynomials representing the computation, and one or more polynomials evaluated in (or at) a point corresponding to the trapdoor value that are dependent on polynomials representing the computation.
The central authority node 4 also determines a computation verification key (step 105) that is for use by the verifier node 10 in verifying the result of the computation by the one or more worker nodes 8.
It will be appreciated that steps 101, 103 and 105 can be performed in the same or different order to that shown in
Next, the central authority node 4 publishes the trusted input commitment key, the computation evaluation key and the computation verification key (step 107). By publishing the keys, the central authority node 4 makes the keys available for any node 6, 8, 10 in the system 2 to access. Publishing the keys can mean storing them in a location that is accessible by the other nodes 6, 8, 10, for example in memory unit 24 if that is accessible by the other nodes 6, 8, 10, or storing them on a server or other computer that is accessible via the Internet or other network. As noted above, publishing the keys may be in a digitally signed form.
It will be appreciated that in embodiments where the central authority node 4 determines the various keys at different times, the central authority node 4 can publish each key as it is determined, rather than wait until all keys are derived before publishing.
In some embodiments, the key material for each trusted input wire in the computation evaluation key includes an encoding of the product of a secret value β and the combination of a computation-independent polynomial evaluated in a point corresponding to the trapdoor value that represents the trusted input wire and one or more computation-dependent polynomials evaluated in a point corresponding to the trapdoor value that represent how the wire is used in the computation. It will be appreciated that, since the inverse β−1 of a secret value is again a secret value, instead of multiplication by β one can equivalently perform multiplication by β−1, i.e., division by β when constructing the key material. Below we will not consider this alternative formulation separately.
More specifically, the key material for the one or more trusted input wires can comprise:
β·(sk+rvvk+rwwk+ryyk1 (27)
where k is a label representing each trusted input wire, s is the trapdoor value, β, rv and rw are random values and ry=(rv·rw) for each trusted input, vk, wk and yk are polynomials evaluated at s that represent the computation. In particular, and as defined above vk represents the way that the respective trusted input wire is used in the left factor, wk represents the way that the respective trusted input wire is used in the right factor, and yk represents the way that the respective trusted input wire is used in the product of the set of multiplications that make up the computation. f1 for polynomial f denotes an additively homomorphic encoding of the ring element f(s), as discussed above. It will be appreciated that the key material in equation (27) is also found in the key material set out in equation (9). It will further be appreciated that, by means of the change of variables δ:=1/(βry), ϵ:=1/ry, α:=1/rv, β′:=1/rw, formula (27) may equivalently be written as
Below we will not consider this alternative formulation separately.
In some embodiments, to further improve the security of the algorithm, the central authority node 4 can also determine and publish a trusted input verification key. The trusted input verification key is for use by the verifier node 10 in verifying the authenticity of the trusted inputs that are input into the computation. This key can be published in the same way as the other keys above in step 107.
The trusted source node 6 has one or more trusted inputs 6 that are to be input to a computation.
In step 201, the trusted source node 6 obtains a trusted input commitment key. As noted above, the central authority node 4 determines and publishes the trusted input commitment key. Thus, in step 201, the trusted source node 6 can obtain the published trusted input commitment key.
Next, in step 203, the trusted source node 6 uses the trusted input commitment key to form a trusted input commitment for the one or more trusted inputs that are to be input to the computation. The trusted input commitment can be as defined in equation (7) above.
The trusted source node 6 then sends the trusted input commitment to the verifier node 10 (step 205).
The trusted source node 6 also sends the one or more trusted inputs to the one or more worker nodes 8 for input to the computation.
In step 301, the worker node 8 obtains a computation evaluation key. As noted above, the central authority node 4 determines and publishes the computation evaluation key. Thus, in step 301, the worker node 8 can obtain the published computation evaluation key. The computation evaluation key can comprise any of the various embodiments of the key material set out above with reference to step 103.
Next, in step 303, the worker node 8 receives one or more trusted inputs for the computation from the trusted source node(s) 6 and/or from the verifier node 10.
In step 305 the worker node 8 evaluates the computation using the received one or more trusted inputs to determine values for one or more internal wires of the computation and one or more output wires of the computation (which represent the output of the computation). The trusted inputs are input to the computation using one or more trusted input wires of the computation.
Finally, in step 307 the worker node 8 determines a proof that the computation on the one or more trusted inputs is correct and that the one or more trusted inputs were used in the computation. This proof is determined using the computation evaluation key. The determined proof can be sent to the verifier node 10, e.g. when the information is determined, or in response to a request from the verifier node 10 for proof information.
In some embodiments, the worker node determines the proof by determining encodings (e.g. V, W, Y above) of the contributions of a set of input wires including the trusted input wires to left factors, right factors and products of the multiplications that form the computation using the key material described above based on the one or more polynomials that are dependent on polynomials representing the computation.
In some embodiments, the proof comprises an element Z that is for use in verifying that the commitment for the trusted input wires and the encodings of the contributions consistently use the same values for the trusted input wires.
In some embodiments, element Z is a linear combination of
β·(sk+rvvk+rwwk+ryyk)1 (28)
according to the homomorphic encoding scheme used, with coefficients given by the trusted input wires and where f, for polynomial f, is an additively homomorphic encoding of the ring element f(s).
In alternative embodiments, element Z comprises:
z
1=Σjxjβ·(rvvj+rwwj+ryyj)1+Σkxk(β·(sk+rvvk+rwwk+ryyk)1, (29)
where (f), for polynomial f, is an additively homomorphic encoding of the ring element f(s).
In other alternative embodiments, element Z comprises:
Z
1=δv·rvβt1+δw·rwβt1+δy·ryβt1+Σjxjβ·(rvvj+rwwj+ryyj)1Σkxkβ·(sk+rvvk+rwwk+ryyk)1, (30)
where f, for polynomial f, is an additively homomorphic encoding of the ring element f(s).
In implementations where the system 2 comprises at least one other worker node 8 (e.g. in an implementation based on Trinocchio), the worker node 8 evaluates the computation in step 305 as a multiparty computation with the other worker node(s) 8. In these embodiments, the worker node 8 can determine the proof in step 307 as a multiparty computation with the other worker node(s) 8. Also in these embodiments, as the worker node 8 may have received a secret share of the trusted input and determined a secret share of the result of the computation, the worker node 8 may determine a secret share of the proof (with the other secret share(s) of the proof being determined by the other worker node(s) 8).
In step 401, the verifier node 10 obtains a trusted input verification key and computation verification key. As noted above, the central authority node 4 determines and publishes the trusted input verification key and the computation verification key. Thus, in step 401, the verifier node 10 can obtain the published trusted input verification key and the published computation verification key. The trusted input verification key and the computation verification key can be as described above (e.g. γ2 and equation (10) respectively).
In step 403, the verifier node 10 obtains a trusted input commitment from the one or more trusted source nodes 6 that provided a trusted input to the computation to be verified by the verifier node 10. The trusted input commitment comprises a representation of one or more trusted inputs that have been input by the one or more trusted source nodes 6 to the computation. The trusted input commitment may be as shown in equation (7) above.
In step 405, the verifier node 10 obtains an output of the computation and a proof that the computation on the one or more trusted inputs by the one or more worker nodes is correct and that the one or more trusted inputs were used in the computation. The output and the proof are obtained from the worker node(s) 8 that performed the computation.
It will be appreciated that steps 401, 403 and 405 can be performed in the same or different order to that shown in
Next, in step 407, the verifier node 10 determines whether the computation on the one or more trusted inputs is correct and whether the trusted inputs were used in the computation. This is determined using the trusted input verification key, the computation verification key, the trusted input commitment and the proof.
In some embodiments, the proof comprises encodings (e.g. V, W, Y above) of the contributions of a set of wires including trusted input wires to left factors, right factors and products of the multiplications that form the computation.
In some embodiments, the proof comprises an element Z that is for use in verifying that the plurality of encodings are consistent with each other and that the plurality of encodings are consistent with the trusted input commitment for the computation. The element Z can be as set out above with reference to any of the embodiments of step 307.
In some embodiments, in step 407 the verifier node 10 determines whether the computation on the one or more trusted inputs is correct and whether the trusted inputs were used in the computation by verifying that the plurality of encodings are consistent with each other and that the plurality of encodings are consistent with the trusted input commitment for the computation.
In some embodiments, in step 407 the verifier node 10 determines whether the value encoded by element Z equals the value encoded by a random value multiplied by the sum of the values encoded by the encodings of the contributions of the set of wires including the trusted input wires to the left factors, the right factors, the products of the multiplications that form the computation and an encoding of a representation of the trusted input wires included in the trusted input commitment.
In particular embodiments, in step 407 the verifier node 10 determines whether the computation on the one or more trusted inputs is correct and whether the trusted inputs were used in the computation by evaluating:
e(11,12)β·(I+V
and verifying that they are equal, where I is the representation of the trusted input wires included in the trusted input commitment; Vmid, Wmid, Ymid are the representations of the contributions of the set of input wires including the trusted input wires to the left factors, the right factors, and the products of the multiplications that form the computation; P is the random value; z is the value encoded by element Z; ⋅1, ⋅2 are homomorphic encodings that are used to encode the values I, Vmid, Wmid, Ymid, β, and z; and e is a bilinear map defined on the two encodings.
In some embodiments, the homomorphic encodings x1, x2 are g1x, g2x with g1, g2 generators of discrete logarithm groups and e is a cryptographic pairing.
The verifier node 10 can evaluate equation (31) by evaluating:
e(I1+Vmid1+Ymid1,β2)·e(β1,Wmid2)=e(Z1,12) (32)
In some embodiments, the homomorphic encodings x1, x2 are both encryptions under the same public key with the same homomorphic encryption scheme, e (x1, y2) represents the value x·y obtained by decrypting x1 and y2 and multiplying the results, and e(x1, y2)z represents the value x·y·z obtained by decrypting x1 and y2 and multiplying the result with z.
It will be understood that, in the above description where homomorphic encodings are elements from a discrete logarithm group and the bilinear map e is a cryptographic pairing on the discrete logarithm group, several variations are possible. In particular, it is possible to use a symmetric pairing (in which case the two discrete logarithm groups 1, 2 are the same) or an asymmetric pairing (in which case the two discrete logarithm groups 1, 2 are different). It is also possible to (independently) change the discrete logarithm group used for the various elements in the various keys, commitments, and proofs. For instance, computation proofs may contain a proof element Vmid2=Σixi·rvvi2+δv·rvt2 instead of Vmid1=Σixi·rvvi1+δv·rvt1 if the respective key material is changed appropriately to contain encodings rvvi2, rvt2, αv2 instead of rvvi1, rvt1, αv1 and the verification procedure is changed to check, among other things, that e(αv1, Vmid2)=e(αvVmid1,12).
The above-described nodes, systems and methods have several potential applications. Some examples are outlined below.
A wearable biosensor measures data of a customer and thereby acts as trusted source; an insurance company wants to have statistics on this data to evaluate a premium for the customer. The biosensor cannot compute the data on its own so the data needs to be outsourced, but the insurer wants to be convinced of the correctness. Here, the party orchestrating the methods herein can be the central authority and producer of the biosensor; the processing of the data can then be outsourced to the customer while correctness is still guaranteed.
Governments periodically publish health statistics to inform the public. These statistics can be authenticated with respect to the data by the hospitals and other medical organizations so that the public is sure they are correct. In this case, the party orchestrating the methods herein could act as trusted party independent from both the trusted sources (medical organizations) and worker (the government).
A smart meter produces readings but does not have the computational power to compute an aggregate report on this, or the aggregate report format may change over time. Hence this is outsourced to the owner of the smart meter. But the energy company wants to be sure that the aggregate report has not been manipulated by the owner to reduce her electricity bill.
Similarly, the scheme can be used for pay-as-you-drive insurance.
A bookkeeper authenticates financial data of an organization. Based on proofs an auditor can check that certain processes were followed correctly.
The system could be deployed for consumers to get loyalty discounts based on payment information provided by sales terminals, without the shop knowing details about the consumer's purchases (assuming the shop cannot see what happens inside the sales terminals).
The system could be deployed to allow multiple verifiable computations to refer to a common shared state. For instance, one verifiable computation could have an output x that is used as an input to a second verifiable computation. In this case, x could be regarded as a trusted input to both the first verifiable computation and the second verifiable computation, and the techniques described herein would allow a verifier to check that the same value x was used in both computations without needing to know x.
In distributed ledgers such as the Ethereum blockchain, verifiable computation can be used as a means to prove correctness of transactions while keeping their contents hidden, and while keeping the verification effort independent from the complexity of the description of the transaction. This system enables such verifiable computations to efficiently refer back to trusted inputs by a third party, and it enables multiple such verifiable computations, possibly of different types), to share a state without disclosing it.
There are therefore provided improved techniques and algorithms that enable trusted sources to outsource computations on their data to an untrusted worker, and any external party can cryptographically verify the correctness of the computation result, while minimising the overhead for both the worker and a verifier.
Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the principles and techniques described herein, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. A computer program may be stored or distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Any reference signs in the claims should not be construed as limiting the scope.
The present application claims priority to and benefit of U.S. Provisional Application No. 62/443,338, filed Jan. 6, 2017, its entirety of which is hereby incorporated by reference herein.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2017/084795 | 12/29/2017 | WO | 00 |
Number | Date | Country | |
---|---|---|---|
62608650 | Dec 2017 | US | |
62443338 | Jan 2017 | US |