Integrated Verification of Cryptographic Security Proofs and Implementations

(1)

D

Integrated Verification

of Cryptographic

Security Proofs and

Implementations

Vítor Manuel Parreira Pereira

MAPi

Departamento de Ciência de Computadores 2020

Orientador

Manuel Bernardo Martins Barbosa, Professor Auxiliar, FCUP

Coorientador

(2)

(3)

(4)

Author’s declaration

I declare that the work in this dissertation was carried out in accordance with the requirements of the University’s Regulations and Code of Practice for Research Degree Programmes and that it has not been submitted for any other academic award. Except where indicated by specific reference in the text, the work is the candidate’s own work. Work done in collaboration with, or with the assistance of, others, is indicated as such. Any views expressed in the dissertation are those of the author.

SIGNED: ... DATE: ...

(5)

(6)

Dedication and acknowledgements

Taken from Wikipedia,

”a roller coaster is a type of amusement ride that employs a form of elevated railroad track designed with tight turns, steep slopes, and sometimes inversions” Of course this is just one possible definition of what a roller coaster is. However, if it was up to me, three letters would be enough to define it: P, H and D. And I had the pleasure to ride with the best ones, who I thank in this small part of my thesis.

First, I thank my supervisors Manuel and Bacelar. I guess you were the ones that bought me the ticket to that roller coaster and for that I am thankful. I am 100% sure that this was the best Ph.D. I could ever do and both of you are responsible for that. I learned a lot with you and I will be taking all your mentorship everywhere.

Two things that made these 4 years unforgettable were the two internships I took, for which I would like to express my gratitude. Starting with the French guys, I thank Gilles, Pierry-Yves, François and Benjamin for all the collaboration opportunities and for welcoming me in Madrid in such a friendly way. And now on to the American, I thank Karim not only for the intership in SRI, but also for all the friendship demonstrated. Thank you all for the opportunities you unlocked for me!

From the bottom of my heart, I would like to thank my colleagues Tó, Bernas, Pacho and Óscar. It must be truly hard to deal with me on a daily basis and for that I admire you. You guys contributed actively to my thesis and I am sure I will miss our discussions in the future.

And now, for the ones that have been riding the roller coster with from the beginning -Noky, Parola, Diggy, Rolo, Kiko and Vanessa - and for the ones that joined the ride in the middle - Lobo, Paulo, Vitor, Eduardo and Younes. What a ride it has been. The most crazy memories of my life were created by you and I am pretty sure that, if I told someone some story regarding any of you, that person would have us hospitalised. So lets keep those stories a secret and lets laugh at them when we remember them.

This thesis would not be possible without the support of my loving family. I address my v

(7)

appreciation to my grandparents, my aunts, my uncles and my cousins. My family spreads from Tras-os-Montes to Minho and, when I was little, I always complained about the long trips to visit you. But now, I could not be more thankful to have shared so much moments with you.

A special gratitude to my godfather Paulo, the one that is present in the good and in the bad moments. When he is present in the bad moments, they are not that bad. But when he is present in the good moments, they are the best! It is not easy to express with words the thanks you deserve. I will be forever grateful for what you have done for me and it is a privilege to be your friend!

To my mother Ernesta, who does not know English, I still write her a paragraph. Of course I do, it was impossible not to thank for supporting me in every new journey of my life, no matter how much it cost her. No distance can erase what a mom does for a son and our case is not an exception.

There is one folk that will write his name in the history books. This may seem a strong claim, but it is not strong enough for my brother Mário. You just have to make use of your inteligence and hard work and everything will pay oﬀ. You cannot be Lord because you are not English and probably you also do not want to be Comendador. But leave it, no decoration is suitable enough for you.

I also express my gratefulness belongs to my father. I’m certain that you are reading this letters I am writing and you are smilling on them, just like you did on everything. I’m sure that all the strength I feel comes directly from you and that you will continue to be on my side every day. Many thanks to you dad, for all that you taught me.

To my lovely, beautiful, dear, girlfriend, bride and wife Filipa. This acknowledgements section should be all about you because you were ALWAYS there. You have the special ability to transform every moment in a nice moment. Even the worst ones become good... Just because you are there. I honestly would like to know how do you do that. It is a pleasure to share my life with you and I know my future is bright just because it will be shared with you. You could be doing whatever you want, but you are here with me. Thank you!

Finally,

"I want to thank me for believing in me. I want to thank me for doing all this hard work. I want to thank me for having no days oﬀ. I want to thank me for never quitting. I want to thank me for always being a giver, and trying to give more than I receive. I want to thank me for trying to do more right than wrong. I want to thank me for just being me at all times" - Snoop Dogg.

(8)

Abstract

Cryptographic software can only fulfil its role as the backbone of security architectures if it achieves zero defect. Weaknesses in cryptographic software sometimes originate in the design of the algorithms or protocols they implement, which may be considerably reduced with the use of rigorous security proofs that follow the paradigm of provable security. A more challenging problem is to address the gap between provable security and cryptographic practice. In this thesis, we take advantage of recent advances in the field of computer-aided cryptography and apply them to multiparty computation (MPC).

MPC frameworks typically incorporate a high-level, friendly language to specify programs that are to be securely evaluated by some underlying computation engine, which induces a significant abstraction gap between the environment that programmers use to specify their functionalities and the environment where these are securely computed. To reduce this gap, we employed computer-aided verification techniques to the development of MPC software stacks, connecting security proofs with concrete implementations.

The verification approach was employed in the development of a secure computation engine, obtained from a machine-assisted formalisation of a security proof for a two-party protocol. This verified secure engine was later employed in the construction of an end-tp-end verified software stack for secure function evaluation (SFE), a particular application scenario of MPC. Verification techniques were used in the characterisation and formalisation of the security of MPC frameworks, that entails an interdisciplinarity between programming languages techniques and security. We explored this connection by demonstrating that information-flow and non-interference policies can be used to prove that MPC protocols achieve passive security. Finally, we show how protocols proven secure using our proposed methodology can be used to generate high-level code for parties engaging in a distributed MPC protocol.

(9)

(10)

Resumo

O software criptográfico apenas pode cumprir o seu desígnio como peça fundamental em arquiteturas de segurança se não possuir defeitos. Vulnerabilidades encontradas em software criptográfico têm a sua origem na concepção de algoritmos ou nos protocolos que imple-mentam, podendo estas eventualidades ser consideravelmente mitigadas usando provas de segurança rigorosas. Um desafio mais interessante diz respeito à diferença entre provable security e aplicações práticas de criptografia. Esta dissertação tira partido de recentes desenvolvimentos nesta linha de investigação, aplicando estes conceitos ao caso particular de multiparty computation (MPC).

Tipicamente, frameworks de MPC incorporam uma linguagem de alto nível para especificar programas que podem ser avaliados de forma segura através um mecanismo de avaliação subjacente, o que aumenta a diferença de abstração entre o ambiente em que os programas são escritos e o ambiente em que são computados. Para reduzir esta lacuna, aplicamos técnicas de verificação ao desenvolvimento de frameworks de MPC, ligando provas de segurança a implementações concretas.

A metodologia de verificação foi aplicada no desenvolvimento de um mecanismo de com-putação seguro, obtido através da formalização de uma prova de segurança para um protocolo de dois participantes com a ajuda de um assistende de prova interativo. Este mecanismo de computação verificado foi posteriormente usado na construção de uma stack the MPC segura para secure functional evaluation (SFE), um cenário particular de MPC.

Técnicas de verificação foram também usadas na caracterização e formalização da segurança a de frameworks MPC, que requer uma interdisciplinaridade entre linguagens de progra-mação e segurança. Neste trabalho, explorou-se esta ligação ao demonstrar que técnicas de information-flow e regras de non-interference podem ser usadas para provar que protocolos MPC atingem um nível de segurança passivo. Finalmente, expo-mos como protocolos prova-dos seguros usando a metodologia que propomos podem ser usaprova-dos para gerar código de alto nível para participantes envolvidos em protocolos MPC distribuídos.

(11)

(12)

List of Tables

3.1 Overview of state-of-the-art tools for computational security analysis. . . 76 4.1 Timings (ms): P1 and P2 denote the parties, S1 and S2 the SFE protocol

stage; TTime denotes total time, OT the time for OT computation, GT the garbling time and ET the evaluation time. . . 103 4.2 CBMC-GC vs CirGen vs Optimised CirGen: timings (ms) . . . 111

(15)

(16)

List of Figures

1.1 MPC stack architecture . . . 2

2.1 Chosen plaintext attack security (IND CPA) of encryption schemes . . . 12

2.2 Security of MPC protocols . . . 17

2.3 Two-party SFE security . . . 19

2.4 Real world definition for ABB-security . . . 21

2.5 Ideal world definition of ABB-security . . . 22

2.6 Security experience for ABB-security of MPC protocols . . . 22

2.7 Real world definition for privacy . . . 23

2.8 Ideal world definition for privacy . . . 24

2.9 Privacy composition hops . . . 27

2.10 Privacy and ABB-security composition hops . . . 29

2.11 Yao’s protocol security proof by BHR [BHR12a, BHR12b]. . . 30

2.12 Garbling of a gate. The labels of the output wires are garbled based on the input wire labels. For example, possession of labels A1 _{and B}0 _{lets one access} the third row of the leftmost table. . . 32

2.13 Indistinguishability-based privacy of garbling schemes . . . 34

2.14 Simulation-based privacy of garbling schemes . . . 35

2.15 Eﬃcient inverter for a topo leakage function . . . 36

2.16 Adversary B attacking PRIV-SIM based on adversary A attacking PRIV-IND . 37 2.17 Adversary C attacking PRIV-IND based on adversary A attacking PRIV-SIM . 38 2.18 Security of a DKC scheme. . . 40

2.19 Sender and receiver simulation-based security . . . 42 xv

(17)

2.20 Yao’s protocol SFE security . . . 45

2.21 Adversary BG attacking PRIV-SIM security of the garbling scheme based on adversary AA attacking SFESim security of Alice’s execution of Yao’s SFE protocol . . . 46

2.22 Adversary BR OTattacking SFESim security of the receiver’s execution of the OT protocol based on adversary AAattacking SFESim security of Alice’s execution of Yao’s SFE protocol . . . 47

2.23 Adversary BS OTattacking SFESim security of the sender’s execution of the OT protocol based on adversary AB attacking SFESim security of Bob’s execution of Yao’s SFE protocol . . . 47

2.24 BGW addition functionality and simulator . . . 52

2.25 BGW scalar multiplication functionality and simulator . . . 53

2.26 BGW multiplication functionality and simulator . . . 55

2.27 BGW reshare functionality and simulator . . . 57

2.28 While language . . . 58

2.29 Big step semantics for the while language . . . 60

2.30 Small-step semantics for the while language . . . 60

2.31 While language augmented with high and low annotations . . . 62

4.1 Structure of our verified security proof of an implementation of Yao’s protocol 86 4.2 Abstract two-party protocol . . . 87

4.3 Security of a two-party protocol . . . 88

4.4 Instantiating two-party protocols . . . 90

4.5 Abstract garbling scheme . . . 91

4.6 Simulation-based security of garbling schemes . . . 92

4.7 Indistinguishability-based security for garbling schemes . . . 93

4.8 A concrete oblivious transfer protocol. . . 96

4.9 A concrete DKC scheme. . . 97

4.10 SomeGarble: our concrete garbling scheme. . . 98

4.11 Concrete SFE protocol. . . 101

(18)

LIST OF FIGURES xvii

5.1 Syntax of source-level language. . . 115

5.2 Source-level instrumented semantics. . . 115

5.3 Type system of our source language. . . 117

5.4 Declassify protocol. . . 119

5.5 Low-level distributed semantics. . . 120

6.1 Compilation dimensions as performed by secure computation software frame-works . . . 128

6.2 L syntax . . . 130

6.3 L semantics . . . 131

6.4 Local (public) rules of the multiparty semantics . . . 133

6.5 Synchronisation (secret) points of the multiparty semantics . . . 134

6.6 Security interfaces in our program-based secure computation model . . . 134

6.7 Security experiences in the program-based secure computation framework . . 136

6.8 API semantics . . . 140

6.9 ↵ API semantics . . . 141

6.10 Simulator S . . . 142

(19)

(20)

Chapter 1 Introduction

Secure Multiparty Computation (MPC) is nowadays considered a practical solution and a feasible alternative to be considered in many real-life problems such as distributed voting, private bidding and auctions, sharing of signature or decryption functions and private infor-mation retrieval.

The problematic gap, that we address in this thesis, lies between the security claimed by provable security and the security of the implementations. This gap is induced by the fact that provable security relies on idealised models that leave out essentially all the details involved in implementing the protocol in a programming language. This this leaves room for mistakes, which may introduce vulnerabilities, and also physical attacks that exploit side channels such as timing attacks.

The integrated verification of cryptographic security proofs and implementations is still a major challenge, which has been addressed in recent years as demonstrated by some notable work has emerged in this area [ABBD13, ABBD16, BFG+_{14, BDLF}+_{16, BW10, FKS11].}

The broad goal of this work is to explore how to bridge the gap between cryptographic proofs and implementations with the purpose how deploying verified implementations that match the cryptographic primitive they intend to realise and that satisfy the required security conditions. Informally, we want do so by bringing together the two worlds: i. a world where it is easy to formalise cryptographic algorithms and perform security proofs around them; and ii. a world where it is easy to describe cryptographic algorithms in a lower level, more close to the implementation level, and from where concrete implementations can be derived. From a theoretical point of view, we are interested in understanding how can we perform security proofs and how far would our formalisations be from an implementation level. From a practical point of view, we are interested in understanding how can we generate concrete implementations of cryptographic software that follow the formalisation.

(21)

1.1 Challenges

An MPC protocol implementation can be seen as an evaluation engine that is able to securely evaluate some program. The general idea behind this concept is to look at MPC solutions as software stacks, where a high-level program is compiled to some protocol description (instead of low-level machine code) that is able to be evaluated by an MPC protocol. The architecture of MPC stacks is exhibited in Figure 1.1. The intuition behind MPC stacks is a separation between an high-level computation description language from a low-level protocol description language. The first one is typically a specification language that is provided to end-users for them to specify programs they want to be securely computed (i.e., computed via some MPC protocol), hiding the low-level details of the protocol. The second is a lower-level description of the computation, achieved from the first by a compilation step, that is suitable to be interpreted by a distributed virtual machine who knows how to perform MPC protocols.

High-level language

Computation description

Computation engine

Compilation

Evaluation

Figure 1.1: MPC stack architecture

There are significant advantages of approaching secure computation via a software stack. At first, it provides a friendly, high-level environment for the description of the functionality one wants to securely evaluate. This means that even non-experts would be valid users of MPC technologies. Next, it flavours a compositional approach to secure computation protocols due to the possibility of describing complex computations as the compositions of smaller tasks for which it is known to exists secure MPC protocols that realize them. In fact, the computation description language can be seen as an orchestration language that provides a series of secure MPC protocols for simple operations (addition, multiplication, logical conjunction, logical disjunction, ...) that can be executed by the underlying virtual machine and every instruction or operation in the high-level language can be translated into one of these tasks.

The stack design fits many promising MPC use-cases, such as crypto currency or privacy-preserving data mining, because it tolerates configurable high-level specifications and because there is a clear independence between the stack constituents. The lower-level component of

(22)

1.1. CHALLENGES 3 the framework is static collection of components, that are provably secure and correct at source that oﬀer high-assurance and high-performance guarantees at machine level. This library of protocols can then be applied to diﬀerent scenarios. For example, the input specification can be a relation/statement for zero-knowledge proof, a function for secure evaluation or a reactive functionality for MPC. Intuitively, the particular application scenario to which the framework is being used influences the security model and, therefore, the low-level protocols that are going to be invoked.

At the lowest level, we find the secure computation engine. This designation was purposely chosen to encompass powerful virtual machines oﬀering complex operations but also simpler APIs that permit executing low-level descriptions of computations in circuit form (i.e., sequences of simple operations such as Boolean or arithmetic gates). The purpose of the secure computation engine is to take secure computation descriptions and to execute them according to a well defined semantics.

The role of the secure computation description language is to serve as an intermediate technological level in the secure computation stack is required to bridge the upper and lower layers. In other words, a transformation step must be introduced to convert the high-level specifications into secure computation descriptions that can be executed in the underlying engine.

Finally, at the top level, the developer should be able to use a high-level, possibly domain-specific, language to describe the secure computations that are needed to meet the functional and security requirements of the application.

The critical aspects that we address in this project manifest themselves precisely on the composition of the three stack components. Concretely, how to correctly translate a high-level program to a lower-high-level one so that the engine will execute the designated computation and how to ensure that this engine is performing computations in a secure way. These two steps are represented by the compilation and evaluation labels of Figure 1.1. The challenges are verified both at the theoretical level - more related to fundamental concepts - and at the practical level - more related to formalisation and implementation techniques. We highlight the challenges of this thesis bellow.

Computation specification High-level programs that are to be used inside MPC stacks must meet specific security requirements. The formal verification challenges at this level include being able to rigorously and naturally specify the relevant requirements, as well as providing support to formally verify that the high-level implementation meets the specified requirements. The solutions to these challenges are somewhat facilitated if the selected high-level language is a general-purpose programming language such as C, for which, despite all technical issues that C code specification entails, there exist a wide range of source code formal verification tools. However, the expressiveness of such languages is too limiting when the goal

(23)

is to describe general multiparty interactions, as they were not designed for this purpose. A set of more interesting and complex challenges arises when the high-level language of choice is tailored for secure multi-party computation, as is the case for example of SecreC [Jag10]. Computation description The formal verification challenges at this level are akin to those arising in verified compilation: the goal is to guarantee that the target code gener-ated from the high-level specification preserves the relevant functional and non-functional properties displayed by the latter.

Computation execution The formal verification challenge at this level is to formalize the semantics that the protocol description must follow and to guarantee that, for any given secure computation description, the secure computation engine oﬀers the correctness and security guarantees implied by the semantics.

1.2 Contributions

The contributions resulting from the work developed in this project all fall on the domain of computer-assisted verification and on the production of verified implementations of MPC software and its consequent prototyping.

Verified secure computation engine Our first contribution comprises of verified im-plementation of a two-party SFE protocol due to Yao [Yao82] for which a detailed game-based proof exists in the literature [BHR12b, BHR12a]. Achieving this was done in two steps: the formalisation and verification of its security proof and the generation of a verified implementation based on that proof, that is guaranteed to satisfy the security guarantees proven in the formalisation. Our results were machine-checked using EasyCrypt.

EasyCrypt [BGHB11, BDG+_{13] is an interactive proof assistant with dedicated support to}

perform game-based cryptographic proofs. It has been used for several emblematic examples, including signatures and encryption schemes. Formalising the proof of security for Yao’s SFE protocol in EasyCrypt involved formalising two generic proof techniques that had not previously been considered: hybrid arguments and simulation-based security proofs.

In contrast to other standard techniques, which remain within the realm of the relational program logic that forms the core of EasyCrypt (i.e., it is used to verify transitions between successive games), hybrid arguments and simulation-based proofs lie at the interface between this relational program logic and the higher-order logic of EasyCrypt in which security state-ments are expressed and proved. Specifically, hybrid argustate-ments combine induction proofs and proofs in the relational program logic. Similarly, simulation-based security proofs intrinsically

(24)

1.2. CONTRIBUTIONS 5 require existential quantification over adversarial algorithms and the ability to instantiate security models with concrete algorithms (the simulators) that serve as witnesses as to the validity of the security claims. These two forms of reasoning exercise the expressive power of EasyCrypt’s ambient logic.

MPC is also a challenging test case in terms of its scale. Indeed, EasyCrypt had so far been used primarily for primitives and to a lesser extent for (components) of protocols. While these examples can be intricate to verify, there is a diﬀerence of scale with more complex cryptographic systems, such as SFE, which involve several layers of cryptographic constructions.

Realising our broader goal required several improvements to the EasyCrypt tool. In particular, the complexity and scale of the proof developed here guided several aspects of EasyCrypt’s development to support compositional simulation-based proofs, and the aim of producing exe-cutable code from machine-checked specifications served as initial motivation for EasyCrypt’s code extraction mechanism. We make extensive use of a generic formalisation of hybrid arguments that was produce in the scope of the SFE stack and has since been included in EasyCrypt’s library of game transformations.

Another important challenge identified regards the proof of compositional results of protocols. Indeed, both the security proofs of Yao’s SFE protocol and of the MPC stack formalisation heavily rely on compositional results, that can be established at an abstract level (without considering concrete implementations but assuming its security). Concretely, the security of Yao’s SFE protocol was derived from the composition of a secure oblivious transfer (OT) protocol with a secure garbling scheme and the security of the MPC stack was derived from the composition of smaller protocols that comprise its engine.

The most exciting follow up work after completing a security proof is to actually derive a concrete implementation, that entails all the properties proven in the specification. Achieving some verified implementation can be done via two duals paths: i. starting from a concrete im-plementation, prove that the code satisfies the desired properties; or ii. starting from a proof, extract correct-by-construction code from the specification. For the purpose of this thesis, we were interested in following the second approach, generating verified implementations from EasyCrypt specifications.

To synthesise the verified implementation of Yao’s SFE protocol, we used EasyCrypt’s own OCaml extraction mechanism, that was deployed with earlier versions of the tool. It consisted of a special script command, where users were to able stipulate what was to be extracted and how dependencies (such as EasyCrypt’s core library) should look like in the final code.

Language-based security of MPC protocols MPC frameworks intersects multiple computer science areas besides cryptography, such as programming languages, networks and

(25)

distributed systems.

In this thesis, we study how well established programming languages concepts (particularly those of information-flow and non-interference) can be used to prove security of MPC proto-cols described by means of programs.

We consider a particular language incorporated with public and secret computation. We then define two semantics that can be used to animate the execution of programs on that language: a source-level semantics, that evaluates programs without security concerns and that is instrumented with leakage information (public data that is disclosed in the program evaluation) and a low-level semantics, where language operators are evaluated according to MPC protocols. Intuitively, the same program being animated with the two afore mentioned semantics is a specification of the real and ideal worlds (common in MPC definitions) from a programming languages perspective.

The connection between the two semantics can be drawn by a compilation-like result, where we prove that source-level security - an information-flow theorem - can be mapped to the low-level security - a non-interference theorem. Interestingly, non-interference at the lower-level implies cryptographic security, according to a specific privacy definition over non-reactive protocols, tolerating semi-honest adversaries. Intuitively, our methodology exposes the existence of a simulator that can be used to prove security in a simulation-based fashion.

Secure generation of high-level computation engine descriptions Having a language-based approach to the security of atomic MPC protocols, the next natural step was to explore how similar techniques could be applied to entire MPC frameworks.

We extended the model used for MPC protocols to capture more realistic execution scenarios, lifting it to a reactive setting, allowing computing parties to receive inputs and collect outputs at intermediate steps of the computation. Furthermore, our model also considers the independent evaluation of public computations. In other words, we consider a real world experience where parties can execute local computations independently from one another. Our methodology considers functionality descriptions as programs written in a language with input and output statements. Semantics for these programs are modeled to make a distinction between public (local) operations and secret ones, which are computed by an external API whose role is to specify how secret operators are evaluated. We demonstrate that the inclusion of the secret API permits the definition of a more realistic execution scenario, where parties are able to perform public operations locally and synchronise whenever they need to perform some operation over secret data by calling the external API. Our work also exposed the minimum conditions that need to hold in order to generate a secure and correct description for the computing parties.

(26)

1.3. SOURCES 7 either by generating a low-level description of the functionality and then using our framework to derive a secure evaluation engine description or by generating low-level code for the individual party programs. This last scenario is the most interesting one, as it captures the possibility of using compilers for diﬀerent target languages and for the collaborative execution of the protocol by heterogenous platforms.

1.3 Sources

This section provides a list of the author’s publications produced as a consequence of the work presented in this thesis, as well as orthogonal projects in which the author actively contributed. The list of published papers map to the contributions itemised in Section 1.2, as well as to other verification projects that were developed in the span of the thesis. [ABB+_{17] A Fast and Verified Software Stack for Secure Function Evaluation.}

Almeida, Barbosa, Barthe, Dupressoir, Grégoire, Laporte, Pereira (CCS 2017) This paper describes the construction of the fully verified software stack for SFE. It contains a comprehensive description of the components of the stack - the Boolean circuit generator CirGen and the verified secure computation engine - and how their interoperability based on FRESCO. The author participated in the development of the verified secure computation engine, which included the machine-checked proof that was performed in EasyCrypt, and in its integration inside the FRESCO platform.

[ABB+_{18] Enforcing Ideal-World Leakage Bounds in Real-World Secret Sharing}

MPC frameworks.

Almeida, Barbosa, Barthe, Pacheco, Pereira, Portela (CSF 2018)

This paper describes how to rely on programming languages fundamentals in order to prove the security of some low-level semantics. Particularly, how to transpose to the protocol description level all the security properties that were proved at a higher level. The author participated in the definition of a protocol based semantics that allows programs to be securely evaluated by evaluating language native operators via MPC protocols. The author also took part in the two proof steps entailed by this project: on one hand, how to securely translate from a high-level language to a more suitable protocol description and, on the other hand, in proving that the lower level description achieved the considered degree of security.

[ABB+_{] A Formal Treatment of the Role of Verified Compilers in Secure}

Com-putation.

Almeida, Barbosa, Barthe, Pacheco, Pereira, Portela (JLAMP 2020) This papers leverages on the work presented in the previously described paper to present our formal analysis of MPC frameworks and how existing verified compilers can be used

(27)

inside them to enforce security and correctness requirements. The author participated in the formalisation of the stack functional behaviour as well as its security model, inspired by the UC framework. The author also produced the EasyCrypt formalisation that machine-checks the theoretical view of MPC frameworks that was followed. Throughout the Ph.D. programme, the author was also actively involved in the PRACTICE1

European project, which provided both crucial insight in the fundamental security definitions associated with standard secure computation scenarios, as well as feedback for use cases validating the applicability of the approach. In fact, the development of the verified SFE stack was one of the major contributions of this project (D14.4 [NDM+_{16]). As already}

mentioned, the author actively contributed to the development of the secure computation engine, as well as in the integration of this engine in the FRESCO framework, also developed in the context of the PRACTICE project.

Works not included in this thesis

In addition to the articles mentioned above that are directly related with the work described in this document, the author also participated in two additional projects that also fall in the domain of cryptographic security proofs and in the production of verified implementations for the primitives that were proven secure. We list the papers that derived from those projects and describe the role of the author in them bellow.

[ABB+_{19] A Machine-Checked Proof of Security for AWS Key Management}

Service.

Almeida, Barbosa, Barthe, Campagna, Cohen, Gregoire, Pereira, Portela, Strub, Tasiran (CCS 2019)

This paper resulted from a collaboration with Amazon Web Services (AWS) and presents a machine-checked proof of security for the domain management protocol of Amazon Web Services’ KMS (Key Management Service) a critical security service used through-out AWS and by AWS customers. The author participated in the both the modelling of the KMS component, as well in the definition of the security requirements it should meet. Moreover, the author also took part in the computer-assisted proof that was developed, contributing not only with EasyCrypt definitions but also in the proof of the security theorem.

[EP19] A High-Assurance Evaluator for Machine-Checked Secure Multiparty Computation.

Eldefrawy, Pereira (CSS 2019)

The project described in this paper under the internship that the author took in the 1_{https://practice-project.eu/}

(28)

1.4. DOCUMENT STRUCTURE 9 Computer Science Laboratory (CSL) unit of the SRI International institute in Menlo Park, California, USA. The project focused on the EasyCrypt formalisation of existing proactive secret sharing and MPC protocols, as well as in the synthesis of verified code from this formalisation. The author played a central role in the development of the whole paper, supervised the remaining author, as it developed an entire MPC infrastructure in EasyCrypt, that formed the base to the definition of the protocols that were explored. As part of this work, the author also developed an extraction tool for EasyCrypt that was used to synthesise code from the EasyCrypt implementations of the protocols.

1.4 Document structure

The thesis structure is as follows.

• Chapter 2 described some necessary technical background, mostly focused on formal definitions of the cryptographic primitives that were explored in this thesis, as well as their respective security notions, as well as an introduction to the EasyCrypt toolset. • Chapter 3 provides context of related work with respect to the state-of-the-art

mech-anisms for secure computation, software based approaches to MPC, verification tools and on the application of these tools to the verification of cryptographic algorithms. It also incorporates a brief description of relevant work in the field of programming languages that directly relate to security results.

• Chapter 4 comprises a comprehensive description of how EasyCrypt was used to verify a security proof for Yao’s SFE protocol and how concrete code was generated from that proof. In this chapter, we also illustrate how the verified Yao’s SFE protocol implementation was used as the evaluation engine of an end-to-end verified software stack for SFE, developed with recourse to FRESCO.

• Chapter 5 describes the language-based approach that we follow in order to establish the security of MPC protocols, focusing on the relation between non-interference and passive security.

• Chapter 6 depicts our formal analysis of MPC frameworks, presenting compilation and security results, as well as the identification of the minimum conditions that need to be verified by the MPC stack to enforce its secure execution.

(29)

(30)

Chapter 2 Technical background

The focus of this chapter is to detail the theoretical background that forms the basis of the work carried out throughout this dissertation. We start the chapter by providing a preliminary notation for game-based proofs. Then, we focus on general definitions for secure multiparty computation protocols. We also describe a particular MPC protocol that works in the two-party setting designed by Yao [Yao82], for which a verified implementation was built. Next, we focus on the theme of secret sharing and show how secret sharing schemes can be used to build MPC protocols. These are the underlying techniques of our MPC stack formalisation. We finish the chapter with the presentation of some fundamental concepts in the area of programming languages and with a comprehensive description of EasyCrypt [BGHB11, BDG+_{13], the proof assistant that was used to machine check proofs}

during the project developed in the course of this thesis.

2.1 Game-based notation and proofs

Providing concrete and correct security definitions for cryptographic algorithms can be a tedious task. Moreover, it may be even harder to actually prove that a concrete algo-rithm satisfies the intended security definition and some security proofs can become very complicated and error-prone, nearly impossible to verify. In order to tame the complexity of cryptographic proofs (and to ease in the specification of security notions), cryptographers rely on a proving technique that is based on sequences of games. Briefly, with the objective of proving security of a cryptographic algorithm, one first starts by specifying a game (program) that unequivocally symbolises the security asset. From there, it is possible to slightly tweak the game into another game that is computationally indistinguishable from the original one. This step can repeated until a game is reached where it is possible to prove that an adversary has no advantage on breaking the security of the primitive. Since all games in the sequence are indistinguishable among them, one can conclude that an adversary does not have any

(31)

advantage on attacking the original security description and, consequently, the primitive achieves the desired level of security.

The first use of this game-based proving framework can be traced back to [BG89], where the authors extensively used transitions based on both indistinguishability and failure events. A more formal use of game-based proofs was introduced in [KR96], where the authors applied the Diﬀerence Lemma, specialised to their particular setting. The technique was later refined and the first formal description on the organisation of cryptographic proofs using sequences of games appears in [BR04], where the authors employed the technique to establish the security of triple encryption. In this dissertation, we focus on the game-based approach advocated in [Sho04], that incorporates some diﬀerences when comparing to the definitions in [BR04], namely on how the authors define games (programs vs. probabilistic spaces) and in the transitions based on failure events.

Security of cryptographic primitives is defined as an attack game played between an adversary and a challenger, a benign entity that will answer the adversary queries according to the concrete primitive being analysed. A good example of how to model security definitions based on attack games (and that we use to introduce necessary notation) can be found in Figure 2.1, where we illustrate the security game for chosen plaintext attacks against encryption schemes. In this security experience, an encryption key k is first securely generated via the KGen procedure. This key is then given to the adversary A which he can use to specify two diﬀerent messages m0 and m1, that will be used to challenge the security of the encryption

scheme. These messages are given to the challenger that proceeds by encrypting one of them and giving back the corresponding ciphertext to A. Finally, A will try to guess which message originated the ciphertext he obtained from the challenger. A wins the security game (i.e. breaks the security of the scheme) if he is able to distinguish which message originated the ciphertext (b = b0_{). Furthermore,}

IND CPA_E(_A):

1: b ${0, 1} 2: k $KGen(1 ) 3: (state, m0, m1) $A.choose(1 , k) 4: c $E(k, mb) 5: b0 $A.guess(1 , c, state) 6: return b = b0

Figure 2.1: Chosen plaintext attack security (IND CPA) of encryption schemes The game is parameterised by an adversary A. Parameterisation is essentially an universal quantification on the module that is being used to parameterise the game. Specific to this case, it means that security is defined for any adversary A that is able to challenge the

(32)

2.1. GAME-BASED NOTATION AND PROOFS 13 security of the encryption scheme E. Sampling some value from a probabilistic distribution is represented by operand $, the same way the assignment of probabilistic procedures is represented.

Typically, both adversaries and challengers are modelled as probabilistic processes that interact with each other and the definition of security is tied to some particular event E: for every eﬃcient (polynomial time) adversary, the probability that event E occurs is very close to some specified target probability, which can be 0, 1/2 or the probability of some other event E0 _{occurring in other game in which the same adversary is interacting with a}

diﬀerent challenger. For the particular case of IND CPA, the security event is the adversary successfully guessing if the ciphertext it receives comes from either the encryption of m0 or

m1.

Formal security games also include a security parameter , an integer tending to infinity that measures the security of the cryptographic primitive. The term very close to used in the previous paragraph frequently refers to a function on this security parameter: the difference is smaller than the inverse of any polynomial in the security parameter. The most common used term for this difference is negligible, meaning that the difference is so small that is barely noticeable. The security parameter is most of the times implicit in security definitions.

To prove security using the sequence of games approach, one proceeds as follows. First, one starts by constructing a sequence of games Game0, Game1, . . . Gamen where Game0 is the

original attack game and with E0 = Ebeing the security event. The construction defines, for

every i 2 [1..n], event Ei that should occur in Gamei, usually related to the original event

E. The goal is then to prove that Pr[Ei]is negligible close to Pr[Ei+1]for i 2 [1..n 1] and

that Pr[En]matches the target probability. From this, it is possible to derive that Pr[E ] is

negligibly close to the target probability and security is therefore proved.

When constructing the sequence of games Game0, . . . , Gamen, it is desirable that the changes

between the games are very small so that it is simple to analyse it and prove its computational equivalence to the previous game in the sequence. We identify three possible transition steps between games:

• Transitions based on indistinguishability - where a small change is made that, if de-tected by the adversary, would imply the existence of an eﬃcient method to distinguish between two distributions that are assumed to be indistinguishable.

• Transitions based on failure events - where it is shown that Gamei and Gamei+1 are

identical unless a certain failure event F happens.

• Bridging transitions - which are essentially conceptual changes, where the computation is restated in a diﬀerent way. These transitions are very useful when paving the way

(33)

for a transition of the above two types.

Finally, security theorems are expressed by means of the advantage an adversary has when at-tacking a given cryptographic scheme. For example, the IND CPA security of the encryption scheme E can be stated as

Advindcpa_E (A) = 2 · PrhIND CPA_E(A) : resi 1

where res is the output of the IND CPA security experience. It is possible to go even further and redefine the above equation as a diﬀerence between two probabilities if one considers a version of the IND CPA written in terms of conditional probabilities. Concretely, it is possible to prove that

PrhIND CPA_E(A) : resi= 1 2 · (Pr

h

IND CPA_E(A) : res|bi+ PrhIND CPA_E(A) : res|¬bi) Consequently, the advantage lemma can be restated as

Advindcpa_E (A) = PrhIND CPA_E(A) : res|bi PrhIND CPA_E(A) : ¬res|¬bi

a more suitable advantage definition for some applications, such as the ones considered in Section 2.3 and Section 2.4.

2.2 Secure multiparty computation

The functional and security definitions in this section are based on previous MPC notes by Ronald Cramer and Ivan Damgård [CDC+_{06] and David Evans, Vladimir Kolesnikov and}

Mike Rosulek [EKR18].

MPC, first described in [Yao82], is a cryptographic technology whose goal is to replace the usage of a Trusted Third Party (TTP) by enabling a group of parties who do not trust each other to jointly compute arbitrary (potentially reactive) functions that depends on all of their private inputs. The meaning of security here is twofold. On one hand, it requires that no information regarding the players private input is disclosed throughout the execution of the protocol. Note that MPC protocols do allow some admissible information to be leaked with respect to local party inputs, such as, for example, its bit size, which can be exploited by an adversary trying to breach the security of the protocol. On the other hand, security also includes the correctness of the protocol outputs, stating that honest parties must never output an incorrect result (they either output the correct result or end the protocol with no output at all). General MPC definition considers arbitrary functions, tolerating reactiveness

(34)

2.2. SECURE MULTIPARTY COMPUTATION 15 of the execution, meaning that protocol parties may provide inputs and collect outputs in intermediate steps of the protocol execution. If one fixes the function and the party inputs before the protocol execution, we obtain an interesting realisation of MPC called secure function evaluation (SFE). Although the definitions of SFE and MPC may be similar, there are two important diﬀerences that worth mentioning. First, the function to be computed must be agreed before the execution of the protocol, diﬀerent from the arbitrary functions that considered in general MPC. And second, SFE imposes that party inputs are fully known at the beginning of the protocol, in contrast to the reactiveness of general MPC protocols. Security of MPC protocols

Defining a general security notion for MPC protocols is a particularly challenging task, namely due to its multiple applications. Providing a general security definition for MPC protocols must lead to, for example, a security definition for electronic voting or auctioning protocols because there are particular instances of MPC. Therefore, when specifying security for MPC, one must take into account many security requirements that may appear in diﬀerent MPC contexts, which may not be a feasible task.

The definitions we present here are a simplification of the Universal Composability (UC) [Can00] definitions, built on top of earlier work, namely [Bea92, MR92]. Nevertheless, we stress that the simplified model we show here suﬃces for the particular context of this dissertation in which MPC protocols are applied.

Ideal vs. Real world paradigm To avoid having the need to itemise the security assets that should be met by a MPC protocol, a commonly used technique is the introduction of an ideal world, which is basically a specification of what the protocol should functionally compute and an encapsulation of its security guarantees. The first usage of this paradigm is due to Goldwasser and Micali [GM84b], when they used this approach to define security for probabilistic encryption primitives.

The idea behind the ideal vs. real world approach is to establish an indistinguishability result between the ideal world and the real world, modelling the collaborative execution of the MPC protocol by a set of parties, modelled as Turing machines. Intuitively, the real world will consider the actual protocol execution while the ideal world will describe what the protocol should compute (in terms of functional correctness) and what security assets should be verified by the protocol. If the two worlds are identical, then the protocol execution in the real world matches the functional behaviour of the ideal world and it also ensures the security assets defined in the latter. In what follows, we will provide a more extensive description of the two worlds and formalise general security results for MPC protocols.

(35)

i.e., how protocol participants could outsource the computation of the protocol functionality to a TTP by oﬄoading their secret inputs to it. The ideal functionality must also return the leakage that is admissible by the MPC protocol. The term leakage here is employed not as information that is visible in the execution of the protocol (like the messages exchanged by the parties) but rather information about the private party inputs of honest parties that is tolerated to be known by the environment and adversary (like the bit size of the inputs). Intuitively, the possession of such leakage permits the construction of a simulator, whose role is to reproduce the online behaviour of the protocol. Specifically, given the private input of the protocol and the admissible leakage returned by the functionality, the simulator must produce an output, a communication trace and randomness data that are indistinguishable for the ones that would have been produced if the actual protocol was executed. In addition, the simulator interface is also responsible for controlling when protocol parties produce visible output, as well as determine the number of inputs given to every party (which encompasses the public parameters of the protocol). The ideal world is then a combination of the ideal functionality with the simulator.

Environment and adversary In MPC, the challenger (either the real world or the ideal world) interacts with an environment Z, an external entity to the protocol. The environment Z has access to an adversary A, an adversarial interface that captures whatever influence a malicious insider is allowed to have in the protocol.

The environment Z is responsible for initialising the protocol execution by supplying concrete inputs to every party involved. At this point, Z can either ask for the execution of the challenger and get the necessary data to attempt on distinguishing between a real and a simulate execution of the protocol. Nevertheless, Z can activate an adversary A multiple times before asking for the execution of the MPC protocol. The environment can ask for the adversary to corrupt a party (or a set of parties), i.e., to take control of it and possibly influencing its local behaviour. Intuitively, Z can use A as a mean to not only collect information but also to maliciously induce undesired behaviour so that he can eﬃciently break the security of the protocol.

The environment can then stop querying the adversary and ask for the execution of the protocol. Note that this execution will be influenced by the actions of A commanded by Z. The security goal is to show that besides the corruptions induced to the protocol, the security of the protocol will not be violated.

Security of MPC protocols is commonly defined against passive and active adversaries. These two categories establish the power of the adversary in terms of what he is allowed to do when he corrupts (takes control) of a party. Passive adversaries (also called honest-but-curious) are limited to being an eavesdropper to the protocol, meaning that he can see all messages exchanged throughout the protocol but can only control the internal state of

(36)

2.2. SECURE MULTIPARTY COMPUTATION 17 corrupted parties. Furthermore, he is obliged to follow the rules of the protocol. Active adversaries (also known as malicious or Byzantine) can performed arbitrary modifications to the parties they corrupt. For example, they can change their private input, control their communication flux or even remove them from the collaborative protocol execution. For the particular scenarios studied in this dissertation, our focus will be on passive adversaries. Security definition The security of a MPC protocol can then be established by the advantage of the environment in distinguishing between the real and ideal worlds. In other words, one needs to prove the existence of a simulator that can trick the adversary into thinking he is interacting with the protocol. A schematic definition of the security of MPC protocols can be found in Figure 2.2. On the left side, the adversary and environment are interacting directly with an honest protocol execution and, on the right side, they are interacting with the ideal functionality and with a simulator that will reproduce the online behaviour of the protocol. Note that we consider reactiveness of both the protocol and the ideal functionality, meaning that the environment can perform I/O operations during the evaluation of both worlds while querying the adversary.

Figure 2.2: Security of MPC protocols

The MPC definitions we described in this section are general definitions that accommodate a large set of possible realisations of MPC. However, alternative and simpler security notions (that directly derive from the one described in this section) can be considered for some concrete classes of functionalities and respective protocols.

Intrinsic to the definition of ideal functionalities is the reactiveness of the protocol, as functionalities should tolerate the same entry and exit points of the protocol. Informally, the diﬀerence between reactive functionalities and non-reactive functionalities can be reduced to the entry and exit points that are tolerated by the functionality: while the latter only contemplate one entry point at the beginning (where inputs are provided) and one exit point (where outputs are collected), reactive functionalities tolerate multiple input/output operations throughout its execution.

(37)

Another relevant property that functionalities need to take into account is the model of the network. If one considers an asynchronous model, parties may provide inputs to the ideal functionality at diﬀerent points while the functionality is responsible for controlling when parties receive outputs. In a synchronous network, it is assumed that parties provide inputs at the same time before they simultaneously process the functionality.

An interesting observation is that non-reactive functionalities executing over a synchronous model precisely define the SFE setting. In the next sections, we will first show how security can be realised for two-party SFE and then extend those definition to the multiparty scenario. These two formalisations form the base for our machine-checked security proof of Yao’s SFE protocol in Chapters 4 and for our language-based security approach, explained in Chapter 5.

2.3 The two-party scenario for secure function evaluation

For the two-party case, we consider a synchronous model, in which every message are placed in the communication channel before being processed (received) by parties. A two-party SFE protocol P can be described as a tuple of polynomial time algorithms P = (⇧1, ⇧2),

such that ⇧i(st, M ) : m⇤ out ⇤ b is a probabilistic algorithm that takes as input the current

state of party i together with all incoming messages M from the other parties to produce an outgoing message m, a local output out and a decision to halt or continue. The initial state of a party can be set up locally and is composed of the security parameter and of party i private input xi. The interesting aspect of formalising MPC protocols as presented is that

it allows one to slice the protocol execution to only reason about a given party (or parties). Namely, it is possible to define two addition polynomial time algorithms Viewi(xi, . . . , xn)

and Outputi(xi, . . . , xn) such that

• Viewi(x1, . . . , xn) : convi⇤ !i is a probabilistic algorithm that returns the view of party

ifor an execution of P with inputs x1, . . . , xn. The view vi of party i is a collection of

the messages convi exchanged by party i during the course of the protocol (messages

it sends and messages it receives) and also of the randomness !i consumed by party i.

• Outputi(xi, . . . , xn) : yi is a probabilistic algorithm that returns the output value yi of

party i after the protocol is performed.

Two-party SFE security is defined based on two security games, one for each party. We assume that the protocol is being collaboratively computed by players Alice and Bob. To model the security of one party, each experience will assume that the party has been corrupted and will try to gain access to sensitive information about the opposite party throughout the messages exchanged during the protocol. Likewise, we consider two diﬀerent adversaries, one

(38)

2.3. THE TWO-PARTY SCENARIO FOR SECURE FUNCTION EVALUATION 19 that will challenge the Alice ’s execution and one that will challenge the Bob’s execution. Both adversaries will have two procedures: choose - used to generate the inputs of the SFE protocol for both parties -, and dist - used to try to diﬀerentiate between a real execution of the protocol and a simulated one.

Both security games can be found in Figure 2.3, where the Alice’s game appears on the left and the Bob’s on the right. Both games include a simulator S, whose goal is to, Informally, play the role of the opposite party and reproduce it’s behaviour: based on the input, output and leakage of the opposite party, generate a view that could trick the adversary into thinking he is interacting with the protocol itself. For simplicity, we will name this security notion as SFE-SIM. Alice_P(_{S, A):} 1: b ${0, 1} 2: (iA, iB)_A.choose() 3: if b then 4: v_ViewA_P(iA, iB) 5: else

6: oA_OutputA_P(iA, iB) 7: v_SA(iA, oA, (iB)) 8: b0 _A.dist(v)

9: return b = b0

Bob_P(_{S, A):}

1: b ${0, 1}

2: (iA, iB)_A.choose() 3: if b then

4: v_ViewB_P(iA, iB) 5: else

6: oB _OutputB_P(iA, iB) 7: v_SB(iB, oB, (iA)) 8: b0 _A.dist(v)

9: return b = b0

Figure 2.3: Two-party SFE security

The security of a two-party SFE protocol is defined based on two advantage terms, one for each involved party, as stated bellow.

Advsfe-sim_P (_{A, S) = Adv}alice_P (_AAlice,SAlice)+

Advbob_P (_ABob,SBob)

The security (and functional) definitions of passively secure two-party protocols here pre-sented is modular enough to be applied to multiple protocol instantiations. In fact, we will use this definition to reason about the security of both oblivious transfer (OT) protocols and of Yao’s SFE protocol. Note that, despite being two diﬀerent classes of MPC protocols, the security goal is the same: no more information about the private inputs can be disclosed other than the tolerated one. We provide a more detailed explanation about this general 2-party construction and explore how it can be used to abstract the behaviour and security of both

(39)

the OT protocol and of Yao’s SFE protocol when we describe our EasyCrypt formalisation in Chapter 4.

2.4 Security definitions for non-reactive functionalities

In the previous section, we showed security definition for two-pary SFE. Due to the simplicity (non-reactive in a synchronous model) of the two-party SFE setting, it is possible to define security of the protocol based on two games, one for each party, where it is easy to define security aware information such as the leakage produced by the other parties input. However, extending this kind of reasoning to the multiparty setting is unfeasible: if the number of parties involved in the protocol is large, then the security proof may become unmanageable. Moreover, many of the protocols definitions in the literature do not consider a concrete number of parties (they work for three or more parties) and, consequently, it is impossible to know how many party specific security games are needed.

In this section, we show how the security definitions for two-party SFE naturally extend to the multiparty scenario, again considering non-reactiveness and a synchronous network model. We consider MPC protocols secure agains passive adversaries, tolerating static corruptions, and for which inputs are shares produced by a linear secret sharing scheme. We do so by providing concrete real and ideal world instantiations and by establishing the advantage of an attacker in this setup. We will exhibit two diﬀerent notions of security: i a more classic ABB-security definition, realising arithmetic black box (ABB) functionalities [DN03]; and ii a weaker security notion called privacy [BLLP14], that will fit MPC protocols realising deterministic arithmetic functionalities.

One interesting aspect regarding the security characterisations we depict here is that, since the inputs to the protocol must be established before the protocol execution, as this model does not consider I/O operations in the middle of it, and because parties will be always synchronised, it possible to simplify the security definition depicted in Figure 2.2 by collapsing the environment and the adversary into the same entity.

ABB-security for ABB functionalities

Informally, an ABB can be thought of as a secure general-purpose arithmetic evaluator, where parties can specify inputs and collect the final result of the computation at the end. ABB functionalities are usually defined as probabilistic ones, as they require the use of some sort of randomness to ensure the security of the overall computation. This probabilistic behaviour is typically accomplished by wrapping a simpler deterministic functionality (henceforth denoted as FABB_{) around a secret sharing scheme, in the sense that the value outputted by the}

(40)

2.4. SECURITY DEFINITIONS FOR NON-REACTIVE FUNCTIONALITIES 21 exactly what models the desired freshness of output shares that ABB protocols must achieve. For clarity, we make this process explicit in the security games presented in this section. The security games described bellow are derived from a simplified version of Universal Composability (UC) security [Can00].

Real world The real world specification for ABB-security can be found in Figure 2.4. The environment starts by choosing the private party inputs and also a set of corrupted parties C. The real world will answer back to the environment with the protocol outputs and only with the view of the corrupted parties. We use ¯x to denote the array of input shares (x1, . . . , xn)

and similar notation in the case of outputs and party views. RealSec_P(_{Z, A):}

1: (¯x, C)_ZA.choose() 2: (¯y, ¯v)_⇡(¯x)

3: return (¯y, ¯vC)

Figure 2.4: Real world definition for ABB-security

Ideal world The ideal world is topped by the same environment and adversary structures as the real world. However, the ideal world does not contemplate any protocol parties as its the goal is to emulate a TTP: protocol players are expected to send their private inputs to the functionality that is responsible to perform some computation with them.

The construction of the ideal world is exhibited in Figure 2.5. While the interaction with the environment and adversary follows the same structure of the real world in Figure 2.4, the way values are compute changes: party outputs will be computed via the functionality F (also responsible for executing the leakage function ) and the view of the corrupted parties is reproduced with recourse to simulator S. Informally, the simulator will possess the inputs and outputs of the corrupted parties and what he is admitted to know about honest parties’ inputs (i.e., the leakage l). Armed with these, he attempts to reproduce the protocol execution such that it would generate communication traces and random coins that would match those produced by an honest execution of the protocol with the same inputs.

Security definition The formal security definition is defined via the security game MPC Sim of Figure 2.6.

Essentially, the adversary will be able to choose the inputs with which he wants to challenge the protocol, together with the parties he will corrupt. He will then receive concrete protocol outputs or outputs that were computed by the functionality. Furthermore, he will also have access to the messages exchanged by corrupted parties, together with all their internal

(41)

IdealSec_P(FABB,_{Z, A, S):} 1: (¯x, C) ZA.choose() 2: x Unshare(¯x) 3: (y, l) FABB(x) 4: y¯ Share(y) 5: vC¯ S(l, ¯xC, ¯yC) 6: return (¯y, ¯vC)

Figure 2.5: Ideal world definition of ABB-security

information (including randomness used). Armed with all this data, he will finally attempt to guess if what he was given came from an honest protocol execution or if it is the product of some simulator. Intuitively, an MPC protocol is secure if the views do not allow the computation of any undesired information such as honest parties inputs, which would violate their privacy. MPC Sim_P(FABB,Z, A, S): 1: (¯x, C)_ZA.choose() 2: b ${0, 1} 3: if b then 4: (¯y, ¯v)_RealSecP(_{Z, A)} 5: else 6: (¯y, ¯vC)_IdealSecP(FABB, ,_{Z, A, S)} 7: b0_ZA.guess(¯y, ¯vC) 8: return b = b0

Figure 2.6: Security experience for ABB-security of MPC protocols

The advantage of the environment Z, colluding with adversary A can be written according to Definition 1.

Definition 1 (ABB-security of MPC protocols). Protocol P is said to securely realize some functionality F if there exists a polynomial time simulator S such that, for any environment Z with colluding with adversary A

Advsmc simMPC SIM(FABB,Z, A, S) = 2 · Pr

h

MPC SIM_P(FABB,Z, A, S)i 1

One advantage of specifying security of MPC protocols according to the security game of Figure 2.6 and to the advantage lemma above is that it is possible to decompose both of them with the objective of writing a simpler security theorem. Fixing the decision bit b of

(42)

2.4. SECURITY DEFINITIONS FOR NON-REACTIVE FUNCTIONALITIES 23 game MPC Sim, it can be splited at the conditional branch of line 3, giving origin to two diﬀerent games, similar to the real world and ideal world experiences of Figures 2.4 and 2.5. The probability term PrhMPC Sim_P(FABB,_{Z, A)}ican then be re-written as

PrhMPC Sim_P(FABB,Z, A, S)i= 1 2 (Pr

h

RealSec_P(Z, A)i+PrhIdealSec_P(FABB,Z, A, S)i) Applying this equation to the advantage lemma of Definition 1, we get

Advmpc sim_Game (FABB,_{Z, A, S) = Pr}hRealSec_P(_{Z, A)}i Prh_¬IdealSec_P(FABB,_{Z, A, S)}i This last version of the advantage theorem is indeed the most common one because it centres the security of a protocol in the demonstration that the real and ideal worlds are computationally equivalent.

Privacy for deterministic functionalities

The main diﬀerence between privacy and the ABB-security afore characterised lies on the power that is given to the adversary. While in MPC SIM is given the output shares of all protocol participants together with the views of corrupted parties, in MPC PRIV the attacker will instead observe the unshared protocol output and the part of the trace corresponding to the corrupted parties. Privacy also considers a diﬀerent class of (deterministic) functionali-ties, that we denote by Fop_.

Real world The real world experience for MPC PRIV can be found in Figure 2.7. Note that the protocol output that is given to the adversary is the reconstruction of the protocol output shares.

RealPriv_P(_{Z, A):}

1: (¯x, C)_ZA.choose() 2: (¯y, ¯v)_⇡(¯x)

3: y_Unshare(¯y) 4: return (y, ¯yC, ¯vC)

Figure 2.7: Real world definition for privacy

Ideal world In the ideal world (Figure 2.8), the attacker sees the ideal functionality output and a simulated trace. Note that the goal of the simulator also diﬀers from the simulators

Integrated Verification of Cryptographic Security Proofs and Implementations

D