Cuando todos los alumnos lo entienden todo

A one-way function g is characterised by being easy to compute, but hard to invert. The

first condition is given by the requirement that g is computable in polynomial time. The second condition is formalised by requiring that it is infeasible for any PPT algorithm to

invert g (that is, to find a pre-image of a given value y) except with negligible probability. This requirement is captured in the inverting experiment (Game 2.12) where we consider

the experiment for a function g. The challenger chooses an input uniformly at random from the domain of g, applies g to this input and gives the adversary both the result

and a description of the function. It suffices for A to find any value of x0 for which g(x0) = y = g(x).

1. (Easy to compute) there exists a polynomial-time algorithm Mg computing g; i.e.

Mg(w) = g(w) for all w ∈ Dom(g);

2. (Hard to invert) for every PPT algorithm A, there exists a negligible function negl such that

Prh1← Exp$ Invert A

h

Revocation in Publicly Verifiable Out-

sourced Computation

Contents

3.1 Introduction . . . 62 3.2 Background Material . . . 65 3.3 Revocable Publicly Verifiable Computation . . . 72 3.4 Security Models . . . 82 3.5 Construction . . . 99 3.6 Proofs of Security . . . 108 3.7 Conclusion . . . 126

This chapter looks at the setting of publicly verifiable outsourced computation (PVC) in which it has been shown that attribute-based encryption can be used, not as an access

control enforcement primitive, but instead to prove correctness of a computation. We investigate the current proposal and propose improvements to achieve a more practical

system model, including a simple method for servers to compute multiple functions and a method to revoke misbehaving servers.

3.1

Introduction

As discussed in Section 2.2, verifiable outsourced computation (VC), has attracted a lot of attention in the community recently. VC aims to allow a single client with limited

resources to outsource computations to an external server and to verify whether returned results are correct. Publicly verifiable computation (PVC) [84] aims to provide a more

and subsequently any other entity may use only public information to outsource compu-

tations and to verify results; thus PVC aims to be a multi-client system. However, in our opinion, the current PVC schemes do not support multiple servers computing multiple

functions particularly well.

We believe that both of these are important requirements for many PVC systems that

might be used in practice. It may be desirable for a set of clients to be able to choose from a set of servers on a per computation basis. For example, certain computations may re-

quire different computational resources (e.g. a certain amount of RAM or processor cores) that are only found in some cloud service providers, or clients may wish to outsource a

computation to servers which are geographically nearby to minimise latency (if compu- tation/retrieval time is important). If multiple servers are able to provide computational

services within a PVC system, they may compete amongst themselves to reduce costs or may be able to bid on computations based on whether they currently have resources

readily available; as a client is assumed to set up a PVC system and is therefore the sys- tem owner, it is in the client’s interest to introduce multiple servers to enable this cost

reduction.

We believe that it is unlikely that a client would be willing to expend the resources to initialise a PVC system (in terms of computational resources, and in terms of the monetary

cost of contracting a cloud server provider) to outsource computations of only a single function. Indeed, we also believe it unlikely that an outsourced computation solution

for a single function would provide the level of functionality required in practice — if company employees are to rely only on mobile or lightweight devices, then any provided

PVC solution should enable them to perform all of their duties. In existing schemes, to outsource a second function, either an entirely new PVC system would need to be

initialised or more complex primitives must be used to instantiate the scheme [84].

It is also conceivable that multiple sets of clients (e.g. multiple companies) will be largely

interested in outsourcing similar sets of computations (e.g. common statistical computa- tions), albeit on different, client-specific input data. In current PVC proposals, it is likely

that each group of clients would have a distinguished client that performs the expensive Setup operation and issue delegation and evaluation keys for specific functions on behalf

of their own group. Given that the functions of interest to these groups may overlap, it could be that much of this effort is redundantly replicated by multiple distinguished

clients. In addition, the introduction of multiple computational servers and multiple func-

tions to PVC systems results in an increase workload for the distinguished clients (who must issue evaluation keys to servers for each function); the role of these clients becomes

akin to an authority on entities within the system. We therefore suggest the introduction of a single trusted party which we call a key distribution centre (KDC); the KDC initialises

the system and issues evaluation keys on behalf of all entities in the system.

Finally, given that we have enabled multiple untrusted servers to enrol in a PVC system,

we may wish to revoke servers that are detected as misbehaving (either maliciously or through poor performance which introduces errors to computations) such that they are

prevented from performing future computations. In the traditional, single-client setting of VC, the client itself would simply choose to no longer use the server, and in both VC and

prior PVC schemes, a new system would need to be initialised. However, in the multi- client setting, it is important that all clients are informed that a server is known not to

be trustworthy. In our new model of PVC, the system may include other servers that can still be used, so initialising a new system is not a desirable option. Note that if other

clients were to outsource a computation to a misbehaving server, any errors would still be detected due to the verification property, but we wish to prevent clients wasting their

(limited) resources delegating to a ‘bad’ server and to discourage servers from cheating in the first place, as they know they will be detected, revoked and therefore potentially incur

a significant (financial) penalty from not receiving future work.

Our main contribution in this chapter, then, is to introduce the new notion of revocable publicly verifiable computation (RPVC). We allow multiple servers to enrol in a PVC

system and allow the outsourced computation of multiple functions within a single PVC system. In some sense, enabling the evaluation of multiple functions can be seen as a

shift from SIMD- to MIMD-style (that is, single instruction, multiple data to multiple instructions, multiple data [54]) PVC environments, where servers can compute multiple

functions on multiple inputs provided by clients, albeit not necessarily in parallel. We give a rigorous definitional framework for RPVC that we believe more accurately reflects real

environments than existing proposals. This new framework both removes redundancy and facilitates additional functionality, leading to several new security notions.

In Section 3.2, we briefly review the PVC construction of Parno et al. [84] and the revo- cable key-policy attribute-based encryption scheme of Attrapadung and Imai [14], both

of which will inform our construction of RPVC later in this chapter. In Section 3.3, we

define our system model and framework for RPVC and in Section 3.4 we define relevant security models. In Section 3.5, we provide an overview, technical details and a concrete

instantiation of our framework using attribute-based encryption and finally, in Section 3.6, we provide full security proofs for our construction.