• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ILIC Dejan - MSc: Secure Business Computation by using Garbled Circuits in a Web Environment
 

ILIC Dejan - MSc: Secure Business Computation by using Garbled Circuits in a Web Environment

on

  • 1,885 views

This thesis introduces a web based system for secure evaluation of economic function, named Secure Business Computation (SBC), in the manner suggested by Yao 1982

This thesis introduces a web based system for secure evaluation of economic function, named Secure Business Computation (SBC), in the manner suggested by Yao 1982

Statistics

Views

Total Views
1,885
Views on SlideShare
1,885
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ILIC Dejan - MSc: Secure Business Computation by using Garbled Circuits in a Web Environment ILIC Dejan - MSc: Secure Business Computation by using Garbled Circuits in a Web Environment Document Transcript

    • University of Trieste Italy Master of Science in Computer Engineering Master Thesis Secure Business Computation by using Garbled Circuits in a Web Environment ´ by ILIC Dejan UNITS Supervisor SAP Supervisor DR. BARTOLI Alberto ¨ M.Sc. SCHROPFER Axel Piazzale Europa 1 Vincenz-Prießnitz-Straße 1 34127 Trieste, Italy 76131 Karlsruhe, Germany March 5, 2010
    • Acknowledgments It is an honor for me to give my biggest thank to my professor and supervisor Alberto Bartoli. He has made available his support in a number of ways. His professional, positive, informed and encouraging nature has been an inspiration throughout. From the first day, at University of Trieste, to the very end of my studdings. I am indebted to my many of my colleagues for supporting me at SAP Research in Karslruhe. To all who helped and encouraged me during my time within their department. Firstly, I am heartily thankful to my second supervisor Axel Schr¨pfer, o whose encouragement, supervision and support from the preliminary to the conclud- ing level enabled me to hit even harder for my future career development. It is an honor for me to acknowledge the project leader Florian Kerschbaum for his willing support, advice and hard work in many aspects of the project. I am also grateful to the many students who participated in the Secure SCM project, in particular Daniel Funke, Vishaal Kumar and Piter Kohl. Their tolerance, team work, good humour and insight added much to this work experience. Hopefully, all my colleagues felt as rewarded as I did for their time and effort. It is a pleasure to thank those who made this thesis possible. Firstly, I owe my deepest gratitude to my parents and my brother who gave me the moral support I’ve required from the very first day. I am particularly indebted to my girlfriend and my friends, who has turned a blind eye to the dereliction of duty that occurred over the past few years. Also, many thanks goes to my friends and colleagues at the University of Trieste that were supporting and encouraging me to pursue this degree. Lastly, I offer my regards and blessings to all of those who supported me in any respect during the studies. Sincerely yours, ´ ILIC Dejan
    • Abstract English. Collaboration among partners in a supply chain has been proven bene- ficial. Thus, the full potential of a supply chain is not achievable by locally optimal strategies, but rather requires cooperation of all participating parties. Yet part- ners are reluctant to share private data in fear of exploitation by suppliers and competitors. Secure Computation (SC) enables the effective decision making upon comprehensive partners data, while assuring the secrecy of private data. The SC is an interesting topic in modern cryptography. Rapid growth in process- ing and communication speeds made a web based two-party SC realistic paradigm. This thesis introduces a web based system for secure evaluation of economic func- tion, named Secure Business Computation (SBC), in the manner suggested by Yao in [29]. A function is described with high level Secure Business Computation Lan- guage (SBCL), which will be used to generate a one-pass Binary Circuit Description Language (BCDL) object. Indispensable libraries for cryptographic tools, like Obliv- ious Transfer and Yao’s secure function evaluation protocol, were developed. These libraries are used by a pair of Supplier/Buyer web based SBC applications. This work is particularly focused on a Joint Economic Lot Size (JELS) function. Italiano. La collaborazione tra i partner pu migliorare il funzionamento di una sup- ply chain rispetto ad uno scenario in cui ogni componente della supply chain adotta una strategia ottimale a livello locale. Realizzare questa collaborazione nella prat- ica molto complicato in quanto i componenti sono riluttanti a condividere i propri dati con altre organizzazioni, siano esse fornitori o potenziali concorrenti. La Secure Computation (SC) uno strumento potente in questo contesto in quanto permette di prendere decisioni su dati globali garantendo la segretezza dei dati stessi. La velocit di calcolo e di comunicazione delle tecnologie moderne rende il paradigma SC praticamente utilizzabile. La tesi descrive un sistema web basato sul paradigma di SC per realizzare forme di Secure Business Computation in accordo al protocollo proposto da Yao in [29]. La funzione da calcolare viene descritta con linguaggio ad alto livello Secure Business Computation Language e da questa descrizione viene poi derivato un oggetto Binary Circuit Description Language che realizza la fun- zione per mezzo di un circuito combinatorio. Sono state sviluppate le librerie per i componenti crittografiche essenziali, quali la componente di Oblivious Transfer e la componente che realizza il protocollo di secure evaluation proposto da Yao. Queste librerie sono utilizzate in una applicazione web per Supplier e Buyer in paradigma SC. Il lavoro ` focalizzato in particolare sulla funzione Joint Economic Lot Size. e
    • Contents 1 Introduction 3 2 State of the Art 5 3 Boolean Circuit Construction 8 3.1 Formula Tree Object . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 In-Memory Tree Structure . . . . . . . . . . . . . . . . . . . . 10 3.1.2 SBCL Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Arithmetic Operation Blocks . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1 Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2 Subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.3 Multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.4 Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Formula Tree To BCDL Compiler . . . . . . . . . . . . . . . . . . . . 19 3.3.1 Boolean Circuit Description Language . . . . . . . . . . . . . 19 3.3.2 Formula Circuit Composition . . . . . . . . . . . . . . . . . . 21 3.3.3 Circuit Correctness . . . . . . . . . . . . . . . . . . . . . . . . 26 4 Web Based Secure Business Computation 29 4.1 Browser To Browser Message Exchange . . . . . . . . . . . . . . . . 30 4.1.1 Exchange Session Manager . . . . . . . . . . . . . . . . . . . 32 4.1.2 Browser Message Box . . . . . . . . . . . . . . . . . . . . . . 37 4.2 Cryptographic Library . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2.1 Secure Hash Algorithm SHA-1 . . . . . . . . . . . . . . . . . 41 4.2.2 Oblivious Transfer . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2.3 Garbled Circuits . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3 Web Yao Application Structure . . . . . . . . . . . . . . . . . . . . . 51 4.4 Graphic User Interface Design . . . . . . . . . . . . . . . . . . . . . . 56 5 Evaluation 58 5.1 Joint Economic Lot Size . . . . . . . . . . . . . . . . . . . . . . . . . 58 1
    • 5.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6 Conclusion and Future Work 68 A Cryptographically Secure Random Number 70 2
    • Chapter 1 Introduction This thesis work is a part of the IT research at SAP AG Research CEC (Campus- based Engineering Center) situated in Karlsruhe, Germany. The corresponding project is focused on a Security&Trust1 research field, particularly onto improvement of the Supply Chain Management (SCM) by using secure multi-party computation. Thus, the project is denominated ”Secure SCM” project. The key title parts are ”Secure Business Computation”, ”Garbled Circuits” and ”Web Environment”. The Secure Business Computation (SBC) was born by adapt- ing Secure Function Evaluation (SFE) technique, while the evaluated function is a simple economic (or business) function constructed from basic arithmetical opera- tions. The technique described by Yao in [7], named Garbled Circuits, is used to develop secure business computation paradigm. At the end, the entire system is accommodated to run on internet, or in other words ”Web Environment”. The successful work result is an internet based service that performs a secure business computation between a supplier and a buyer, in a web browser. A specified high level language has been developed dedicated to a custom business function description named Secure Business Computation Language (SBCL). This language then will be parsed to an in-memory formula object which will be compiled to a one- pass boolean circuit described with Binary Circuit Description Language (BCDL). The final result is a fully operational web based product which performs a secure business computation behind a friendly Graphical User Interface (GUI). As such this product is ready to be released to the market. 1 Security&Trust is a research program of SAP Research. This program approach emphasizes on the users and their individual protection needs, including confidence in the system security and awareness of its security status. Itrelates to security properties including authenticity, authorization, integrity, confidentiality, privacy, anonymity, pseudonymity and non-repudiation. 3
    • Business data exchange between a business partners is always critical for each partner, thus they keep their sensitive information private. But the partners would like to achieve collaborative business improvements e.g. to identify a globally optimal production plan (Funke [8]). A good example for this is an economic function named Joint Lot Economic Size (JELS), used in the collaborative supply chain which has to be computed by both partners. This function can be evaluated securely with secure function evaluation technique. In this case, this function is described as an encrypted (garbled) boolean circuit. Therefore, a SBC is a secure function evaluation technique, but represented trough the garbled boolean circuit. With this method each partner can compute an economic function output without revealing his input to his partner. Final application is a secure computation service meant for business partners that are willing to execute the computation in a web environment. The entire work is divided in two parts. In the first part, a SBCL language has been developed. Than a SBCL parser was developed to generate an in-memory formula object. A developed compiler then compiles in-memory formula to a BCDL object. The parser and compiler are written in Java programing language. The second part is development of a web based (Yao protocol) SBC application between two browsers. These browsers communicate over an artificial channel through a web server message exchange subsystem developed with Java Servlet and deployed on the Apache Tomcat server. The server application logic uses Java Server Pages (JSP), the server-side Java technology. While the client application work flow is developed with JavaScript scripting language, together with the Asynchronous JavaScript And XML (AJAX) technology used for client/server communication. Even for the Yao evaluation, the cryptographic libraries were developed in JavaScript. The AJAX technology was also used to build a rich GUI for client application. The State-of-the-Art chapter compares this thesis work with similar available practical privacy-preserving web based information systems on market. The chapter 3 describes how a secure business computation is composed (from the four arithmetic blocks) using dedicated languages for its construction. The chapter 4 explains how the application itself is constructed. It describes how messages between two browsers are exchanged. Indispensable cryptographic libraries for Yao and OT protocol evaluation will be explained. The evaluation chapter describes the final web based application system. The system runs a secure computation of the Joint Lot Economic Size function. In the chapter 6 an overall research conclusion is described and desired future work on a web based privacy-preserving secure business computation systems. 4
    • Chapter 2 State of the Art In cryptography, secure multi-party computation (SMC) is a problem that was ini- tially suggested by Andrew C. Yao in a 1982 paper [28]. In that publication, Yao raised the issue of two millionaires, Alice and Bob, willing to find out who is richer without revealing the precise amount of their wealth. A SMC solution has been provided, satisfying Alice’s and Bob’s curiosity while respecting the constraints. By looking at this example, there is no doubt that without a SMC those parties would be forced to reveal amount of their wealth to a third (trusted) party. This example show the type of the problems that generalized a multi-party com- putation (as in [11]), or SMC protocols. In an SMC, there is a number N of partici- pants p1 , p2 , . . . , pN , where each participant has a private data d1 , d2 , . . . , dN . These participants want to compute the value of a public function with their private in- puts, e.g. F (d1 , d2 , . . . , dN ). By definition, a SMC protocol computation is privacy preserving, i.e. nothing else is revealed to the other players than what is inferable by his private input and the outcome of the function. These functions should be se- curely computed, or evaluated, and this process is called Secure Function Evaluation (SFE). In order to construct SFE there has been accepted Yao’s encrypted (garbled) bi- nary circuit approach [29]. In this approach one of the participants, Bob, constructs the garbled circuit by assigning two random (garbled) bit strings to all the wires which are represented by 0 and 1 respectively and sends it to the other participant, Alice. Before Alice can evaluate the circuit she needs to learn her corresponding garbled input string. To do so, they use a cryptographic technique called 1-out-of-2 2 oblivious transfer (OT1 ) for Alice to receive her input in garbled form. With this technique Alice reveals only one message mA , while two messages m0 and m1 were offered by Bob, but still Bob cannot reveal value A and therefore he doesn’t know 5
    • which message Alice has choose. Alice then evaluates the garbled circuit and sends Bobs output back. They both translate the garbled output strings for their output wires into output bits, or computation result. As has been shown in practice, various real-life problems would require SMC solution. Such problems are distributed voting, private bidding and auctions, private information retrieval, etc. But some problems can rely only on the sub-problem of SMC. That’s because of its close relation to many cryptographic tasks is referred to as secure two-party computation (2PC). As has been proven by Yao in [28], a SFE can be achieved with help of the garbled circuits. Since now, the Yao’s garbled circuit was implemented only as non web based solution. Therefore, the main goal of the thesis is to contrive a web based two-party application which runs SFE with Yao protocol. Till now this concept was mostly theoretical, but modern cryptography coupled with rapid growth in processing and communication speeds made secure two-party computation a realistic paradigm. First system that runs Yao protocol is presented in a Fairplay project [7]. It comprises two applications that are activated by the two players, who want to engage in two-party SFE. This system presents the first evaluation of an overall SFE in real settings. The two-party FairPlay system includes a high-level language SFDL for specifying a distributed protocol, a compiler that compiles the high-level definition into a low-level sequence of primitive operations (boolean circuit) named SHDL, and cryptographic protocols for securely executing this sequence of operations. An important notice is that the two-party FairPlay system is not a web based solution. Nowadays an essential business request is to have a system capable to be run in a web environment. Maybe FairPlay it can evaluate simple SFDL programs, but business partners will require to be transparent and independent while they still can evaluate simple custom economic functions.1 This was also mentioned in the FairPlay project paper [7], a secure two-party computation system can be extended in many ways. One important improvement was developing a new applications driven by advances in the communication infrastructure (such as the ubiquity of the Internet or the emergence of web services). As has been described in chapter 1, this work shows a cutting edge web based SFE application in a security information systems. The final system is able to demonstrate the concept of SFE in a web environment, with protocol proposed by Yao. This systam will protect partners and their confidentiality by contrive them to learn the SFE result without revealing their secret inputs. It will be shown in chapter 4, that this system provides a service to business partners for a custom 1 An simple economic function is expected that can be built with four basic arithmetical operators. 6
    • Figure 2.1: The final web SBC application look economic function computation. The key task is to demonstrate evaluation of the JELS function defined with BCDL object, that is generated with help of a high-level language SBCL used to define an economic function. This example makes clear that the final circuit can be an arbitrary economic function. Therefore, the thesis research goes to cutting edge in the security research field and delivers state of the are system. The resulting application provides an oppor- tunity for future engineering of practical privacy-preserving web based information systems. It pushes research in supply chain optimizations even further, making pos- sible and secure computation for all participating parties. At the very beginning, there has been mentioned that thesis result is a pair of internet applications ready to be release to the market. Indeed, as has been shown, two browsers are capable to evaluate a secure two-party computation over the internet. The figure 2.1 shows entering web page for the final SBC application, and more pictures are shown in the section 4.4. 7
    • Chapter 3 Boolean Circuit Construction A boolean circuit is a mathematical model of computation used in studying compu- tational complexity theory. This circuits are also the main object of study in circuit complexity [27]. In this study, a boolean circuit with n input bits is a directed acyclic graph in which every node (usually called gates in this context) is either an input node of in-degree 0 labeled by one of the n input bits, an AND gate, an OR or a NOT gate. One of these gates is designated as the output gate. Such a circuit naturally computes a function of its n inputs. The size of a circuit is directly related to the number of gates it contains. Several important complexity measures can be defined on boolean circuits, in- cluding circuit depth1 , circuit size, and number of alternations. In a circuit family the size complexity is considered for this thesis work, e.g. of a family to be the function of n that gives the size of the circuit that decides inputs of length n. A boolean circuit is defined in terms of the gates it contain. As mentioned, a basic circuit might contain binary AND and OR gates and unary NOT gates. This basic circuits gates can be used to derive a binary gate eXclusive OR, or XOR. The usage of the XOR gate can help to decrease circuit size, or total gate number. Each gate corresponds to some Boolean function, meaning that it is some mathematical function which takes k bits as input and which outputs a single bit. One important feature of the one-pass(or combinatorial) boolean circuits is that they are oblivious. They perform the same operation sequence independently of the input (i.e. compute the values of the gates one after the other). A combinatorial circuit is a circuit whose output is uniquely defined by its inputs. They do not have memory, previous inputs do not affect their outputs. This structure differs to a sequential circuit structure where the circuit gates can be reused, obviating the 1 Depth of a circuit, denotes the maximum distance from an input to an output. 8
    • circuit memoryless property. Therefore, the combinatorial circuit structure makes this circuits oblivious as required by Yao in [29]. This obliviousness is the key reason why one-pass boolean circuits were used as the computation model for the secure function evaluation protocols (rather than, e.g. a Turing machine). The concept of the obliviousness is important since the BCDL (from section 3.3.1) object will need to respect this rule. As said, this circuits are capable to compute also a general function where n inputs are assigned to k players. In this scenario a boolean circuit contains n in- puts dedicated to k = 2 players. Bob and Alice are players with their inputs a and b respectively. Together they wish to compute some general function f (a, b) using a properly constructed boolean circuit. This is a general problem of a secure multi-party computation (SMC). In this work circuit evaluation is a protocol that accomplishes three things: 1. Alice can enter her input a without Bob’s being able to learn it. 2. Bob can enter his input b without Alice’s being able to learn it. 3. Both Bob and Alice can agree on an arbitrary boolean circuit used to calculate the output. This way both parties are sure on the output correctness and that neither party has tempered it. The theory regarding Yao protocol evaluation will be explained detailed in section 4.2.3. As Yao proposed in [29], the SMC circuit should differ from circuits constructed out of the real hardware compilers. He specified that a boolean circuit should be a purely combinatorial circuit, with no sequential logic. Compilers into real hardware are mostly designed to use (and re-use) circuit components i.e. usage of registers. For instance, look at a compound statement command like sum = sum + a[i], where i = {1 . . . 32}. Real hardware compilers would produce a circuit with a single (sum) register and a single addition circuit, where in each of the 32 clock cycles, one value a[i] is added to the sum register. Fallowing Yao’s proposal, a compiler should produce a circuit that has 32 copies of the addition circuit. Looking at an arbitrary economic function it is obvious that a repetition of an arithmetic operation will be common. But still, the circuit construction blocks, described in section 3.2, can’t have any sequential logic and they can’t be reused. From this it can be concluded that each arithmetic operation inside the formula will require one arithmetic block. In this work an economic formula is considered as a really simple mathematical 9
    • formula, that involves only the four basic arithmetic operations. Of course that even an economic can include interest rates, percentage etc., but all these should be then represented through the four arithmetic operations. This definition is valid for entire document. 3.1 Formula Tree Object An arbitrary economic formula will be represented as an in-memory object. Because of the restriction on sequential logic, mentioned inside the introduction of chapter 3, a chosen approach is to represent formula as a binary tree data structure. A binary tree is a tree data structure in which each node has at most two children. With this structure a parent has to be an arithmetic operation and the child would be an operand. Also, it will be shown that formula described inside the binary tree also satisfies Yao’s restriction on sequential logic. A typical request in business would be a computation of a custom formula be- tween n business partners. In other words, request is to construct the circuit out of an economic formula defined by the business partners in a high-level programming language. For that reason, as the part of this work, a high-level programming lan- guage named Secure Business Computation Language (SBCL) has been developed. This have leaded the work to development of a SBCL parser, which will parse the SBCL description into an in-memory formula object. 3.1.1 In-Memory Tree Structure Before describing a structure of the in-memory formula tree, there are some impor- tant definitions for a rooted binary tree: • A directed edge refers to the link from the parent to the child (the arrows in the picture of the tree). • The root node of a tree is the node with no parents. There is at most one root node in a rooted tree. • A binary tree is a tree data structure in which each node has at most two children. • A leaf node has no children. • The depth of a node n is the length of the path from the root to the leaf. The set of all nodes at a given depth is sometimes called a level of the tree. The root node is at depth zero. 10
    • Figure 3.1: A formula tree example representing formula (3 ∗ d)/c − (a + b). • Siblings are nodes that share the same parent node. In a rooted binary tree each node have at most two siblings, left and right. An in-memory tree object is an economic formula represented in data structure of the rooted binary tree. To represent a formula inside this structure a root node has to be an arithmetic operation. The children nodes are also arithmetic operation, but a leaf can be either an input variable or a constant. To understand this better, an arbitrary economic function can be seen in figure 3.1. In the figure an root node is shown that perform subtraction of the children nodes. The left child is an node performing division of the children nodes, where the left node is another arithmetic operation and the right one (leaf) is an input variable, etc. Thus, a node (or a child) can perform an arithmetic operation dedicated to economic calculations such as addition, subtraction, multiplication and division. Operation values can derive from another node as a result of arithmetic operation result on lower binary tree levels. In this case first node is known as the root node and the child nodes are called left and right. This is important because two of the four basic arithmetic operations are operand position dependent. In the representation of subtraction the minuend is the left child, while the subtrahend is the right one. In the representation of division the dividend is the left child, while the divisor is the right child. Looking first at the structure of a binary tree starting from the root node there has to be provided a recursive function. This function should run through the 11
    • Figure 3.2: A formula tree classes from tree.arithmetic package entire tree, on all nodes and leafs. This shows necessity for an abstract class that is supposed to be extended by arithmetic operation, input variable and constant. As shown on figure 3.2 each tree node extends the abstract class Operand. Inside the tree a leaf input variable and a constant is an instance of FormulaVariable or FormulaConstant class, respectively. For an arithmetic operation a class named Operation is meant to be extended further to a four classes intended for four arithmetic operations. The Operation class extends the Operand class with two attributes. This attributes are mentioned even before as left child and right child, but in this case the term child is substituted with the term operand. Now, the recursion trough a rooted binary tree can be executed with a help of predefined abstract functions inside the Operand class. There are two main func- tions: getValue(inputs) returns a formula’s calculated output value for the specific input values. This function is called recursively for all operands from the tree root to the leafs. For instance, if binary tree root computes a function f0 (a, b) = a + b, then a and b will be returned values from the both Operand nodes. Therefore if a is an another arithmetic operation where a ≡ f1 (c, d) = c − d than operand’s function getValue(inputs) will take recursion to 1st level of binary tree etc. getSize() returns a calculated bit output size from the tree. This function is also called recursively for all operands from the tree root to the leafs. For example, 12
    • relating to previous example if binary tree root computes a function f0 (a, b) = a + b, where a and b are node operands, than getSize() function will return i+1 i≥j g(i, j) = j+1 otherwise. where i and j are bit output size returned from the getSize() function invoked on the a and the b operands respectively. Of course, if function getValue(inputs) is called than a result will be com- puted respect to the arithmetical operations of the nodes. Thus, if getSize() is invoked, returned result depends also on operands and its characteristic to binary representation. Therefore, if i and j are size of operands, then: Addition will return bit size of max(i, j) + 1 Subtraction will return i size, or minuend bit size2 Multiplication will return i + j integer Division will return dividend (i) bit size Later in text it will be shown that an in-memory formula tree object is only a transition object between SBCL and BCDL3 . That is important, because in the final application design an business partner should just provide the formula, written in SBCL, and BCDL object is generated out of it. 3.1.2 SBCL Parser The secure function evaluation protocol requires that an evaluated function is given as a Boolean circuit, preferably described in with BCDL. Business partners, however, will desire a more convenient high-level form for a given economic function. In the context of secure protocols, this is even more important than the strong usual reasons for writing in high level programming languages. The starting point of any attempt of security is a clear, formal, and easily understandable definition of the requirements. Such clarity of definition is nearly impossible for humans, using low-level formalisms such as Boolean circuits. The clear high-level domain specific languages are required, such as SBCL. To fulfill one of the users request there has been provided a high-level definition language called Secure Business Computation Language (SBCL) used for a clear 2 Subtraction returns minuend’s bit size because of arithmetic block limits to only positive integer numbers. 3 For a detailed description refer to the section 3.3. 13
    • computation overview. The SBCL is language-oriented and its tailored to describe economic formulas. Expressions combine the standard notations as constants, vari- ables, operators and optionally, parenthesis. The allowed operators include arith- metic addition, subtraction, multiplication and division. It is also capable to handle input data of a different input bit size. Once such a specification is given, a parser generates an intermediate level specification of the computation in the form of an in- memory formula tree object. The main reason to parse a SBCL object to in-memory binary tree is for actual BCDL construction. The SBCL language serve only to ease the development effort for the construction of a BCDL objects. Let’s demonstrate an economic type of formula written in SBCL. This is a simple two-player example with multiple variables and arithmetic operations: default-bits:12 a:Alice b:Bob c:Bob d:Alice x:Alice,Bob x = d/c - (a+b) representing the variables input size, variable names and owners, together with a function to compute. To explain the shown code, starting from top of the bottom, a few important expressions have to be explained: default-bits:12 is default input size only for all input variables. This is not true for the output bit size, because is supposed to be calculated respect to the given formula; a:Alice is an input variable named a who’s owner is Alice. The other input variables are a, b, c and d where Bob owns b and c , while Alice owns a and d; x:Alice,Bob is an output variable. It can be seen that the variable is owned by both players, Bob and Alice; x = d/c - (a+b) is a custom formula suggested by business partners. Here can be also seen that x is an output variable. The input and output variables, together with the owners have to be defined for every formula. If th+ e variables and the owners are not defined than the parser 14
    • can’t create an in-memory tree object meant to be compiled to BCDL. In order to fulfill requests for future development, variable can have multiple owners. This rule is valid for input and output variables. Therefore, if a business partners provide all necessary data, the parser will thus accept an economic function written in a high-level programming language and parse it into a in-memory object that representing the same function. In our case the compiler compiles an SBCL program into an rooted binary tree object. It is also important to notice that the overall circuit size directly effect on eval- uation performance. For example, due to their cost, multiplication and division should be used with great caution. The multiplication would increase circuit size really fast, therefore it is recommended to be used as least operation. The division operator should be avoided if possible, or at least used with great restrictions. This restrictions are just a hint to decrease circuit size, because final circuit have to be purely combinatorial, in order to maintain obliviousness. For further details on the arithmetic blocks characteristics refer to the table 3.1 Regarding to previously mentioned performance, the very first step in circuit optimization is actually recomposition of the given economic formula. Making an automatic optimizer for economic formula will make a life of the business partners easier. This is one of the future development points. Another focus in future de- velopment would be developing a SBCL-to-BCDL compiler. The a SBCL-to-BCDL compiler is a novel endeavor in itself, because unlike common hardware compilers, our compiler may use no registers, no loops, and moreover, may use every gate only once. Still, the development of a direct SBCL-to-BCDL compiler, at this point of time, is in a phase of development. 3.2 Arithmetic Operation Blocks Now will be shown the construction of the arithmetic building blocks in the above circuits given the one-pass constraint by Yaos protocol. Building blocks are com- binations of previously mentioned logic gates. The necessary building blocks for an economic function are addition, subtraction, multiplication and division. Note that there exist circuits with better asymptotic complexity than circuits here pre- sented, but many of them cannot be used, since they either do not adhere to the one-pass constraint (Oberman and Flynn, 1997 [18]) or their complexity hides very high constants in the ”big O” notation (e.g. Karatsuba and Ofman, 1962 [12]). The goal is to optimize the number of gates for a realistic domain D, e.g. 32 bit. The domain D needs to be chosen, such that it includes all possible inputs, outputs and 15
    • Figure 3.3: Half adder circuit diagram intermediate values of j(XA , XB ) and therefore no over- or underflow occurs during the computation. It is emphasized that the size of D is independent of any security parameter chosen to protect the privacy of data sets. Thus circuits with the same (or even lower) asymptotic complexity may noticeably differ in the absolute num- ber of gates. The absolute number of gates is relevant because computation and communication costs increase linearly with the number of gates. Table 3.1 depicts for the three arithmetic building blocks a function on the num- ber of gates required for inputs of length l bit, g(l), and the asymptotic complexity of g(l). 3.2.1 Addition The addition building block takes as input two positive numbers, a and b, both having l bits. We denote a = al−1 . . . a0 and b = bl−1 . . . b0 . The output is a number o = a+b, having l +1 bits, o = ol . . . o0 . The circuit is composed from one half-adder which is constructed from two gates and l − 1 full-adders which is constructed from five gates each. A half adder is a logical circuit that performs an addition operation on two one-bit binary numbers. The one half-adder takes as input bits a0 and b0 and has as output the sum bit o0 and carry bit c0 . A full adder is a logical circuit that performs an addition operation on three one-bit binary numbers. For 0 < i ≤ l a full-adder takes as inputs bits ai , bi and carry bit ci−1 and has as output sum bit oi and carry bit ci . It can be combined with other full adders or work on its own. The final bit ol is cl−1 . The total number of gates then is 2 + (l − 1) ∗ 5 = 5l − 3 which is proved to be the theoretical optimal lower bound for carrying out addition of two l-bit numbers (Redkin, 1981 [22]). 3.2.2 Subtraction The subtraction building block takes as input two numbers, a and b, both having l bits. We denote a = al−1 . . . a0 and b = bl−1 . . . b0 . The output is a number o = a+b, having l bits, o = ol−1 . . . o0 . The circuit is composed from one complement or 16
    • Figure 3.4: Full adder circuit diagram negation ¬x (NOT) circuit and two addition circuits already explained in subsection 3.2.1. The complement circuit takes as input bits bl−1 . . . b0 and the output c = cl−1 . . . c0 will have same length of input size. Second part of the circuit takes as input bits cl−1 . . . c0 as one of input variables of first addition circuit together with other constant input variable equal to one, giving output d = dl . . . d0 . Third and the last part, addition circuit from 3.2.1, takes a = al−1 . . . a0 and d = dl−1 . . . d0 , where dl is discarded, and giving out the output o = ol . . . o0 , where, again the most significant bit ol is discarded. The total number of gates then is l + 2 ∗ (2 + (l − 1) ∗ 5) = 11l − 6. 3.2.3 Multiplication The multiplication building block described in (Wegener, 1996) takes as input two positive numbers, a and b, both having l bits. We denote a = al−1 . . . a0 and b = bl−1 . . . b0 . The output is a number o = a ∗ b, having 2l bits, o = o2l−1 . . . o0 . First, l intermediate products si for 0 ≤ i < l will be computed, each having l bits. Let sij denote bit j of intermediate product si , then si,j is computed from aj ∧ bi for 0 ≤ i, j < l , i.e. requires l2 gates. We then calculate by employing the addition building block l − 1 intermediate sums tk for 0 ≤ k ≤ l − 1 of two l-bit strings having as output l + 1 bit. Let tk ,m denote bit m of intermediate sum tk . tk is computed by adding the two l bit strings sk+1 and tk−1,l . . . tk−1,1 . t0 is computed by adding the two l-bit strings s0,l−1 . . . s0,1 and s1 . The final output o is then the concatenation of bits tl−2,l . . . tl−2,1 tk,0 s0,0 . The total number of gates is l2 + (l − 1) ∗ (5l − 3) = 6l2 − 8l + 3. 3.2.4 Division The division building block takes as input two positive numbers, a and b, both having l bits. We denote a = al−1 . . . a0 and b = bl−1 . . . b0 . The output is a number o = a/b, having l bits, o = ol−1 . . . o0 . In the phase of planning there were proposed 17
    • Addition Subtraction Multiplication g(l) 5l − 3 11l − 6 6l2 − 8l + 3 O(g(l)) O(l) O(l) O(l2 ) g(32) 157 346 5891 Table 3.1: Gate number and asymptotic complexity, respect to the l input size, for each arithmetic building block Figure 3.5: Number of gates per building block, respect to input size two solutions. The first circuit performed as proposed by Oberman and Flynn (1997) in [18] by first calculating the reciprocal of b, b−1 , with the iterative Newton-Raphson approximation, and then performing a multiplication to obtain o = a ∗ b−1 . This circuit had a total gate number equal to (log2 l − 1) ∗ (2(6l2 − 8l + 3) + 5l − 3) + 6l2 − 8l + 3 = log2 l(12l2 − 11l + 3) − 6l2 + 3l. For an l = 32 the circuit size is equal to 53647 gates. A second proposed building block for division by Kerschbaum and Schr¨pfer has o reduced the size of the first proposal, for a l = 32 input size, by factor three4 . At the moment the circuit is still if phase of development, therefore a reader is referred to the [19] for a detailed explanation. 4 Detailed explanation of the circuit will be published in WP2 deliverable for Secure SCM project. 18
    • 3.3 Formula Tree To BCDL Compiler The in-memory object formula represents an arithmetic function chosen by busi- ness partners. But still, before the evaluation this formula has to be represented as a boolean circuit object. Therefore the language has been developed and used for describing this boolean circuit. This language is denominated Boolean Circuit Description Language (BCDL). It is expected that an in-memory formula can be compiled into BCDL object. This step is required to provide a necessary input object to the web-based application (described in chapter 4), i.e. a BCDL object. 3.3.1 Boolean Circuit Description Language Required data for evaluation of a boolean circuit are the circuit gates, their truth tables and circuit output wires. While this circuit data were enough for a mathe- matical formula, there were required some additional informations for an economic formula. To calculate an economic formula input and output variables have to be owned by at least one of the business partners. There had been decided a specific boolean circuit descriptive language develop- ment, after the structural analysis of a boolean circuit. This language shall describe a one-pass boolean circuit together with all necessary data required to represent an economic function e.g an input owner. A BCDL object contains all necessary infor- mations about a boolean circuit gates, truth tables, input/output wires and their owners. As such a BCDL object can be divided into following descriptive parts: Inputs. There are n inputs, e.g. for each function variable vl where l ∈ {1, . . . , n}. As said before, each input (or variable) has its own size sl described with SBCL. This input size sl is the size of an array representing an input vl , where each element in the array is a circuit wire wu . Therefore, inputs in BCDL are represented as a double array i.e. the inputs and their sizes. Gates. The circuit connections are represented with gates gs where s ∈ {1, . . . , m}, and the circuit wires wu where u ∈ {1, . . . , k}. Then all gates are represented as an array of length m and k is the total number of unique wires in the circuit. g Each element gs inside this array is a gate composed of multiple inputs wi s g and one output wos , where i = o and i, o ∈ u. The gate gs is represented as an array of circuit wires wu , where first wires represents input wires (e.g. two g g g inputs w0s and w1s ) and the last wire (w2s ) is an output wire. In this thesis work, each gate is a two input gate5 . 5 The security of the Yao protocol is still not prove for more than two inputs per gate. 19
    • Truth tables. Each gate inside the circuit has its own truth table tgs . This table is represented as an array, where a gate gs is paired to a truth table tgs . The output value tgs from a gate gs depends on the binary representation of the h input h of the fixed bit size r, where h ∈ {0 . . . 2r − 1}. I.e. if the input size is r = 2 and the binary input is h = 1, then its binary representation would be h = 012 . In this case, for an AND gate a result would be tgs = 0. Thus, there 01 is an obvious link between gate input size and truth table size, while output values tgs have to be inserted respect to required gate. h Outputs. The outputs format of a BCDL object is exactly the same to its inputs format. Each output (or result) has specific output size depends on the formula described with SBCL. The only difference in respect to inputs is that the g output is an array of the output wires for specific gates wos . Owners. A circuit described in a BCDL object also requires that all circuit vari- ables(input and output) have their owners, as previously shown with an ex- ample in section 3.1.2, where all the variables have their owners. Looking at descriptive parts of the gates and the truth tables, there can be concluded that a gate can be notated as Gs (gs , tgs ). A compiler has been developed to generate the BCDL object from in-memory formula. This BCDL object will contain all the mentioned information for the circuit that computes an arbitrary business function from the formula tree object. For example, the BCDL object exported in JSON6 format looks something like following: var circuit = { "input":[[{"wires":[0,...,31],"name":"2*d*fa"}... "tt":[[0,1,1,0],[0,0,0,1],[0,1,1,0],... "output":[[{"wires":[24009,24010,24011,24012,24013,... "gates":[[0,32,128],[0,32,129],[1,33,130],[130,129,131],... } Once the circuit is created it is required to check the circuit’s correctness. In this case the correctness check supports only integer numbers, because operations are limited to the unsigned integer numbers to maintain technical simplicity. Thus, the in-memory formula tree to BCDL compiler includes many novel tricks for reducing the number of resulting gates in the circuit. 6 JSON is a light weight markup language suitable for data representation in the JavaScript scripting language. 20
    • Capability to compile a formula tree together with a constant values will affect evaluation performance of the Yao protocol, especially in a web environment. That’s because each additional operation will increase the final circuit size. There has been decided to precalculate all public informations, e.g. sharing the same input value from both sides, necessary for secure function evaluation. This precalculation is done before the evaluation of a circuit, providing a minimized circuit as much as possible ready to directly improve the protocol evaluation performance. In this software version the ”formula-to-circuit-compiler” cannot export constant value into the circuit. However compiling formula tree that contain constant values will throw an exception informing user about unsupported functionality. 3.3.2 Formula Circuit Composition To compose a binary circuit there has to be a logic behind when the circuit size start to increase. A good solution to represent an economic formula trough a boolean circuit is to provide basic arithmetical operations as prepared building blocks. Each of these building blocks is stored inside a Java class with some internal logic for a generic construction of the block, independent on the size of the inputs. The preparation of this basic arithmetic blocks is done with help of a base Gate class which is extended by each derived gate class inside the circuit. There have been prepared a classes for a basic logical operation gates and a gates that represents an artificial boolean value inside the circuit. Beside the basic logical operations there is also a derived logical operation class. All this classes extend the base Gate class whose illustrated attributes in figure 3.6 are the following: win is an array of Wire instances wi where i ∈ {1 . . . n} and n is the size of input bits for specific gate; tt array is a truth table of Integer elements tg inside, where g ∈ {0, . . . , 2n − 1}. Truth table output is represented with Integer and it is paired to a g input where g is inserted as a binary value; wout is a Wire element holding the information for gate’s output wire wo where o = i. This makes it clear that each Gate element can have only one output wire. With the help of this three attributes the basic logic operations can be represented, such as AND, OR and NOT. The same structure is appropriate to represent derived logic operations, e.g. XOR operation. Said that, there can be even constructed more complex gates of different input sizes, but with only one output. 21
    • Figure 3.6: A circuit basic gates classes from binary.circuit.gate package For the basic and derived logic operations there have been provided classes illus- trated on the right side of the 3.6 figure. The classes GateAnd, GateOr, GateNot and GateXor extends base Gate class, and their constructors require the input size argu- ment. A class constructor will generate automatically the truth table for a specific binary operation gate. The GateZero class is also extended from class Gate, but with some slight differ- ence. Looking at the GateZero class on UML diagram in the figure 3.6 the difference between this class and the other gate classes can be noticed. The static function getZeroGate() returns the unique GateZero object for the overall circuit. That is because the output of gate gz is always artificial zero, independently of the binary input value. Later in text it is explained why this gate will be used multiple times inside a BCDL object. In this phase of development each circuit arithmetic building blocks, used to compose a BCDL object, requires the equal operands size. This is a crossing point in between the compilation of SBCL to the BCDL object. The SBCL offers con- struction of an in-memory formula with a specific input size for each input variable. Thus, if x and y are the size of the inputs, where x = y, then the GateZero output wire have to be used for a |x − y| most significant bits on the min(x, y) input. The result of the process is x, y = max(x, y) and all provided arithmetic building blocks can be used for the construction of a BCDL object. An interesting optimization point is focused to this problem.7 There has been also provided a GateOne class extended from Gate. After previous 7 Discussed as a future development in chapter 6. 22
    • Figure 3.7: A circuit’s InputVariable and OutputVariable classes from binary.circuit.variable package extended from abstract class Variable example, it is obvious that this gate will return artificial value tgo = 1 independently h on the binary input value h. All wires in the circuit can be divided in two groups, the variable wires and wires in the middle. The variable wires can be separated into input(in-degree 0) and output variables. That’s why some wires have to be memorized inside the Variable class. On the right side of the figure 3.7 the base Variable class is shown with the name and the wires attribute. The attribute name is used only if the variable is of importance for a final BCDL object, e.g. an information about the circuit output variable used as an input variable to another circuit may have no importance. There is also a method getSize() which returns the number of Wire elements inside the wires array. As expected, a method as isNamed() ensuring the importance of the variable for a final BCDL object, i.e. if a variable is named than it should be a part of final BCDL object. On the left side of the figure the classes are presented for the input and the output variables nominated as InputVariable and OutputVariable respectively. These classes extend Variable class and an abstract method addOwner(owner). In the first version of the BCDL specifications these methods differ on the owners number. At first version an InputVariable can have only one owner, while an OutputVariable can have multiple owners. While a name attribute is not obligate, the wires is an obligate attribute indepen- dently on type of the variable i.e. input or output. It is obvious that a BCDL object can be evaluated even without the owners, but in the secure two-party computation protocol proposed by Yao [28] all the variables must have the owners. As it has been shown, it is necessary to construct an economic formula circuit out of the arithmetic building operation blocks. In the figure 3.8 all classes for a four arithmetic blocks builders are shown. A base, or a parent, class per each building block class is an instance of the Operator class. The Operator class is 23
    • an abstract class with a protected abstract function createCircuit(vina, vinb, vout) extended to the all arithmetic blocks. Each arithmetic block will override the abstract function of Operator class from a binary.arithmetic package. This abstract method is protected Circuit createCircuit(Variable vina, Variable vinb, OutputVariable vout) used to create a specific arithmetic circuit block, providing input parameters vina, vinb, vout. All these parameters are arrays of wires for variable inputs (vina, vinb) and array of wires intended to the output of the circuit (vout). Mentioned function require two Variable arguments for left and right operands, and an out- put OutputVariable argument. While this function is protected and dedicated for internal circuit construction logic, there has been ensured an another function for public calls. In figure 3.8 it is shown a public call function getCircuit in two forms. Both functions require two Variable arguments for left and right operands, while only one of them expect voutName argument used to nominate OutputVariable of returned Circuit class. Here, the nomination of the output variable is important only if this output is required in a final BCDL object. Inside the class Circuit all the informations are stored to build a BCDL object. In the Circuit class attributes are inputs, gates and outputs, stored as arrays of Variable, Gate and OutputVariable elements, respectively. These attributes are presented in the figure 3.8, together with their types. All these elements inside the arrays are generated together with a Circuit class returned from getCircuit(vina, vinb, vout) function. It is obvious when looking at the figure 3.7 that an inputs attribute should be an array of InputVariable elements. This fact shows that an input into the Circuit instance can be also an output from another Circuit element. Thus, referring again to the figure 3.8 and the Circuit class, a function prepareCircuit() shall eliminate OutputVariable elements from whom are unnamed from outputs and all from inputs. Afterward a BCDL object is prepared for future evaluation. In a final BCDL object every wire wi has its unique identification number. Uniqueness of each wire is required for correct evaluation of the circuit explained later in text. Therefore, composition of overall circuit may require multiple arith- metic blocks or, in other words, added circuits to the main circuit. While circuit becomes more complex its getting more difficult to manage a uniqueness wire identi- fication number. Although, keeping uniqueness is even harder if static BCDL objects as GateZero can be reused for each building block of the final circuit. 24
    • Figure 3.8: Circuit arithmetic blocks classes from binary.arithmetic package Figure 3.9: A WireManager class for managing of all the Wire objects in a circuit. There has been developed WireManager class in order to facilitate manage- ment for a wire identification uniqueness in a final BCDL object. Therefore, in a WireManager class a function getWire() shall be called for every Wire instance. As expected, unique WireManager instance stores every produced Wire instance inside the wires attribute. Idea behind this is to use one static global wire identifi- cation attribute gwid inside the Wire class. Once a final BCDL object is constructed a function setWiresId() needs to be invoked from unique WireManager instance. This function will invoke the function setWid() for all instances produced from WireManager. Afterwards each Wire instance is identified in respect to the position inside the wires array. Looking at the figure 3.8, particularly on class Circuit, it is clear that a BCDL object can be also generated from an in-memory formula tree. Composing the circuit out of the in-memory formula object requires a compiler that will go through entire rooted tree. Therefore an method inside the Operand class, from tree.arithmetic package8 , named getSize() will help in BCDL object construction. From the fol- lowing figure 3.10 can be understood how the circuit is constructed from the tree 8 Refer to figure 3.2 for detailed explanation of the tree.arithmetic package. 25
    • Figure 3.10: Flow diagram for generation of the BCDL from in-memory formula rooted tree, starting from root Operation element. root Operation. The algorithm for circuit construction will start from binary tree root, which is an Operation instance. Every Operation instance contains a left and a right Operand instance, as shown in figure 3.2. As it has been shown on circuit generation flow diagram a first checked Operand is a left one. If this instance is an oper- ation (e.g. MulOperation) than the algorithm would invoke, for the second time, generateCircuit(formula) for that particular Operation. Else, if the Operand is a FormulaVariable then an InputVariable instance from the binary.circuit.variable package. This function is recursively called trough entire tree until it reach a tree leafs or FormulaVariable instance for both operands. A function returns a specific operation building block which is added to the main circuit of the instance which called the method. Afterward the algorithm goes for the right Operand instance and repeat the same process. As a very final step the algorithm will process in a same manner with building block of current instance. For the arithmetic block will use as 3.3.3 Circuit Correctness As has been shown, four of the arithmetic building blocks have been provided for circuit construction. Still in a future development of an arithmetic block there is always a place open for an improvement. Therefore, a system to prove correctness of the circuit had to be developed. Further in the text is shown an improvement of the Division block and testing for the following circuit. Some building blocks, particularly the Division block, have evolved in planning 26
    • and development process of a JELS circuit9 . I.e. in the development process of this thesis work a two versions of the Division building blocks were proposed. The division building block takes as input two positive numbers, a and b , both having l bits. The output is a number o = a/b, having l bits. A first circuit performed as proposed by Oberman and Flynn (1997) in [18] by first calculating the reciprocal of b, b−1 , with the iterative Newton-Raphson approximation, and then performing a multiplication to obtain o = a ∗ b−1 . This circuit had a total gate number equal to (log2 l − 1) ∗ (2(6l2 − 8l + 3) + 5l − 3) + 6l2 − 8l + 3 = log2 l(12l2 − 11l + 3) − 6l2 + 3l. For an l = 32 the circuit size is equal to 53647 gates. A second proposed building block for division by Kerschbaum and Schr¨pfer has o reduced the size of the first proposal, for a l = 32 input size, by factor three. At the moment the circuit is still if phase of development, therefore a reader is referred to the [19] for a detailed explanation. In this section the correctness is focused on an overall BCDL object and not just for the specific block. Thus, if a requested is to test specific building block than an input formula can be just a single arithmetic operator. Formula tree object can be used to compute formula output over predefined function, inside abstract Operand class public abstract Integer getValue(HashMap<String, Integer> inputs); where function call in classes Constant and Variable, that extends Operand class will return number values, while Operation class call same function for left and right Operand objects. In case of that one of operands is another Operation object, than call becomes recursive trough entire tree. Custom input variable objects return their values go over provided parameter HashMap<String, Integer> inputs containing all possible values inside the tree. Parameter inputs contains String for key values and Integer represents value used for this input variable. In case of circuit correctness there been provided a fallowing static function inside Evaluator class public static int evaluate(Circuit c, HashMap<String, Integer> inputs); requiring Circuit object to evaluate and HashMap for input variables values. 9 Abbreviation of the JELS stands for Joint Economic Lot Size explained later in chapter 5. 27
    • At the end, its enough to create random Integer values of proper input size for each input variable inside HashMap table and to provide this instance to the previously mentioned functions, comparing returned result. This is good approach because sometimes you can’t test all possible inputs because of overall circuit input size. 28
    • Chapter 4 Web Based Secure Business Computation The secure business computation is a new concept in a business world, but still there is a missing system to provide SFE for an economic function. In FairPlay [7] project has been shown that a SFE can be done using a Yao protocol, but this system isn’t suitable for an economic function. Beside that, the methods for doing business evolved rapidly and these methods tend run business on internet, what would require to make an web oriented SBC application. Developing a web based application for the secure evaluation, in the manner suggested by Yao [28], is a real challenge. This chapter gives an introduction to libraries developed for web based secure business computation application. Then follows a presentation of the subsystem developed for browser to browser message exchange. It will explain the cryptographic libraries for secure computation, which were required by the original solution of Yao [28]. Once message exchange system and the libraries were described, an overall description for web application (work flow) libraries and its structure are presented. The figures give detailed formal descriptions of the libraries and protocols while the text tries to explain their details supported by some examples. All the libraries and message exchange subsystem were developed as a part of this work. At the very end, the main target is to use this functionality on a real business case. Therefore, the task was not only to create a system itself, but also an appli- cation demo to be demonstrated in public. The final web application is presented as a pair of client focused sub-applications which run in an internet browser. For that reason, the SBC progress is displayed to the business partners in a user friendly GUI. This application requires from business partners to insert their private inputs 29
    • and to run the evaluation, while at the end they should verify result, confidentiality1 and integrity2 provided by this system. 4.1 Browser To Browser Message Exchange In everyday business each partner requires to be transparent and independent re- spect to the other partners. To make them independent, an independent working environment has to be developed for each partner. In todays business an inter- net browser became an interesting basis for the business applications. An internet browser can interpret, in this case, a JavaScript code required to run a business application. In order to evaluate a n-party protocol each party is obligate to exchange mes- sages with other parties until the protocol is evaluated. Since this work focus on the Yao’s protocol to evaluate the JELS economic function, where n = 2, requirement is a secure two-party computation system. This specification gave an option to develop a message exchange subsystem to support only n = 2 parties. It is expected that a ”theoretical” system as this one has to be less complex and therefore a scenario with n = 2 had been accepted to maintain the simplicity of developed code. Following the analysis of a general service in a web environment, took this sub- system to a multiple message exchange session provider. This subsystem will provide a selection to the user between options to host or to join this subsystem. Hence, another exchange session can be created on a same web server without any influence to the other exchange sessions. It is well known that an internet browser is designed to open a TCP/IP chan- nel with a web server in order to exchange application data. This data exchange allows a client/server application to run. But in order to run the SBC in a web environment there have to be at least two clients processing the data among their internet browsers. This is why there has to be developed a subsystem dedicated to help in a message exchange between the browsers trough a web server. Usually, among client and server data is exchanged with favor of HyperText Transfer Pro- tocol (HTTP). The HTTP protocol will satisfy a subsystem requirements, plus it will make profit out of an Asynchronous JavaScript And XML (AJAX) technology. With the AJAX technology a GET/POST HTTP request/response is executed in an application background, while user can have a complete control over the application. The HTTP GET method is used to download data and to use basic functions for 1 Confidentiality ensure privacy, it prevents unauthorized represent of the secret data. 2 Integrity ensures correctness, the original data cannot be changed or substituted. 30
    • data manipulation on the web server. While the HTTP POST method its therefore exclusively used to upload data onto the web server. This technology opens a door to a completely new business logic on a web page and gives to a user more friendly Graphical User Interface (GUI). While almost every browser on the todays market provide an AJAX object in its local library, a creation of an AJAX object is different in some browsers. This differentiation comes because of the difference in browsers class name for the AJAX object. Therefore, a JavaScript function has to be provided to discover the AJAX class name inside the most popular web browsers. Afterward this JavaScript object is going to be used for all HTTP requests. Inside a specially developed library app/appAjaxReq.js there is a function called getXMLHttpReq() which tests and returns a valid AJAX object for the specific browser. For example, there is a conflict between IE7+, Firefox, Chrome, Opera, Safari where object is called with XMLHttpRequest() function, and in IE5, IE6 there the object has to be called with a ActiveXObject("Microsoft.XMLHTTP") command. After the creation of a XML HTTP Request (XHR) instance, a HTTP request can be made directly from JavaScript. A first step is to call open(type,url,async) used to initialize the object. In this function a three arguments are requested: Request Type: Request method type, only GET or POST URL: Web server Unique Resource Location (URL) string Async: Boolean value indicates which if a request should be dispatched in asyn- chronous mode The async argument is really important in this case. If the async value is true, request will be executed in the asynchronous mode and rest of the JavaScript code will continue to run. In this case, it is necessary to have an event manager to discover the origin of the event. If the async value is false, the request will be executed in the synchronous mode and the application will freeze until a web server responds. In the final application version the synchronous method has been used, instead of asynchronous, for every AJAX call. This has been done in order to skip necessity to have an event manager to discover the origin of the event used to prevent confound of the web server responses. Knowing that an AJAX object can execute only the GET and the POST request definitely helped to maintaining the simplicity. For each HTTP parameter used in a client exchange session a dedicated AJAX library will contain a function dedicated to 31
    • one of two possible requests. Following JavaScript functions, in app/appAjaxReq.js library, ware provided for these operations • ajaxDoGet(url, param, destObject) request with the HTTP GET method • ajaxDoPost(url, data, destObject) request with the HTTP POST method used to simplify GET or POST method call of an open(type,url,async) function predefined inside the browser’s AJAX library. The arguments url and destObject stays for URL of a web server that provides some service and an object where function stores a return value, respectively. In case of GET request, there is a param argument where all required parameters of a HTTP GET request should be placed. While POST request has data argument that is an instance of a byte array to upload on a web server. In an ideal application case the AJAX technology combined with a Comet tech- nology. The Comet technology offers a server push3 methodology, instead of a pull4 methodology used in this work. In scenario with the Comet technology an overall result of TCP/IP packages efficiency will increase in a SBC application. As it has been said two browsers can exchange data only if there is a web server in between. There has developed a exchange session manager class ManagerME in- tend for management of a multiple parallel exchange sessions. Below this exchange mechanism is one browser’s (or client’s) instance of a dedicated message box class Browser.MessageBox. A client has to administer his message box in order to keep it up to date. These concepts are described in details in the following chapters. 4.1.1 Exchange Session Manager A browser exchange sessions manager on a web server shall provide a robust ex- change service, to keep securely stored data directed to a client. It has to support multiple independent exchange sessions, together with user dedicated functions to host a session and to join an existent session. While secure storage is an important issue there is also a feature of a great importance, the latency. All this issues are ”unimportant” in a test environment (as in this work), but in a real web server there are hundreds or thousands of the exchange sessions this can become an enormous concern. 3 Push technology, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server. 4 Pull technology or client pull is a style of network communication where the initial request for data originates from the client, and then is responded to by the server. 32
    • Figure 4.1: Ideal session activation flow in two-party message exchange system The message exchange system has to be deployed on a web server approachable to all SBC players. This system has help running a multiple parallel and independent SBC sessions. Running in parallel would mean that a multiple n-party SBC can be evaluated at the same time. This independence give guaranties that each client has one and only one exchange session on a web server, refereed to his current exchange session ID information stored in browser. If client wants to host/join another session the old exchange session ID will be overwritten. Any client can host/join a message exchange session in any point of time, even in the middle of a SBC evaluation. Once client host/join a new session, his internet browser stores an information regarding a currently hosted/joined exchange session. This information will be stored until client chose to host/join an another session or to delete the information. The reader is referred to the figure 4.1 for the host/join exchange session step. If an exchange session is created (hosted), the host client becomes automatically a part of this session. His internet browser should store his current exchange session ID as a browser cookie. The created exchange session shall stay an inactive session until all the players join. That’s why the host must invite (e.g. email, SMS, letter etc.) a guest to join the exchange session, as represented with gray arrow in figure 4.1. Afterward, once all the required clients join the session it becomes an active session (figure 4.1). Once session is active no additional players can join the session. If some other player tries to join the session an exception will be thrown to inform the player about the exchange session status. 33
    • There is also an advantage if subsystem is designed to provide only n = 2 ex- change sessions. In this case, a web server can automatically recognize designation player in an exchange session ID where player is trying to send a message. Otherwise it would require additional message destination parameters in a HTTP request. In n > 2 case the system requires further development. This system should contain an information about the destination inside a HTTP request, while n = 2 parties system transmits messages directly to the opposite party. Dynamic server responses were inevitable, since all message exchange requests goes over HTTP request methods (GET, POST). Therefore, Java Servlet technology with its HTTPServletRequest and HTTPServletResponse classes entirely fulfilled elaboration requirements. An extended Servlet class ServletME runs on a web server and listens for incoming • doGet(HttpServletRequest request, HttpServletResponse response) • doPost(HttpServletRequest request, HttpServletResponse response) requests. A doGet function call responds on HTTP GET method requests, while doPost responds on POST method requests. A personal message exchange ser- vice(read, delete,...) for clients is administered trough GET method, while all the POST method are exclusively for message sending, uploading data to a message box. The decision on which method to use is what purpose is directly related to HTTP protocol specification. E.g. Microsoft Internet Explorer has a maximum uniform resource location (URL) length of 2,083 characters. It also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs5 . I.e. if GET method is used there is a limit to a maximum of 2,048 characters, minus the number of characters in the actual path. This is more than enough to control a web server via parameters. However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL. The ”unlimited” parameters in header of the POST method were not enough to transfer entire circuit, since the application expects only one (huge) BCDL object. Instead it is decided to transfer BCDL object in a data section of the HTTP POST method. All HTTP GET request should contain one and only one parameter, because only first parameter is going be processed by ServletME and all the others will 5 RFC 2616, ”Hypertext Transfer Protocol – HTTP/1.1,” does not specify any requirement for URL length. 34
    • be discarded6 . Single parameter rule is not valid only with one specific applica- tion request, this request is the host/join HTTP GET request which requires two parameters. This specific GET request will contain message exchange session ID string which will be used to host/join message exchange session. The difference is introduced because need for some additional information e.g. the file contains the BCDL object, which will be evaluated in the final web application. Once client hosts an exchange session on ServletME, his browser receives an unique JSESSION cookie from a HTTPSession class. The browser will use this cookie for identification purpose in future requests. Actually, Servlet uses HTTPSession in- stance to store some additional parameters for specific client. Similar to the Servlet’s browser recognition, a message exchange system is going to use JSESSION value to discover his message exchange session. The JSESSION value is stored in bwId vari- able in a BrowserME class. Since every client has to provide an unique exchange session ID parameter to host/join the session, the Servlet will store this parameter as esId attribute in the browser’s HTTPSession instance. After this step, the esId value is linked to JSESSION (which is equal to bwId) value. The bwId value will be used to restore the message exchange session instance through the esId value. Working environment is managed though ManagerME class. This class is de- signed to simplify creation of an exchange session. This is made with help of a MessageExchange class where esId and bwId values are stored, in SessionME and BrowserME instances respectively. Basically, the ManagerME keeps multiple MessageExchange instances stored in an array. Manager has openSession(esId, bwId) function dedicated to creation of a MessageExchange instance. This func- tion is used to host/join an exchange session with provided parameters. Obvi- ously, a player invokes this function to register his bwId for specific esId inside the ManagerME. Once player tries to host/join a session the manager will check if there is already an existent exchange session with equivalent the esId value. If there is no equivalent esId, the player will be considered as a host and a function hostSession(esId, bwId) will be invoked. If equivalent esId already exists, the player will be considered as a guest and a hfunction joinSession(esId, bwId) will be invoked. Usage of the ManagerME makes everything automatized, in fact an user should use available management requests designed as the HTTP request parameters. Most of these HTTP management commands should be used without a parameter value. 6 One parameter rule is present for subproject simplicity. 35
    • For an example, the fallowing HTTP request sends a valueless getMsg parameter as http://10.55.145.XXX:8080/WebYao/ServletME?getMsg This command will call deployed ServletME Servlet in order to read a message from the browser’s message box. On HTTP request reception, a Servlet restores the exchange session (esId) attribute stored in HTTPSession trough bwId. As said, with assistance of JSESSION cookie the attribute values can be restored from Servlet. This means that client will have to provide esId value only once, when he host/join the session. Following HTTP parameters are dedicated to management of an exchange session on a web server: • GET: esId - host or join to the specified exchange session • GET: esActive - valueless parameter used to check if exchange session is active The parameters are transfered trough HTTP GET method where only esId param- eter is expected to have a value of his exchange session. Both responses is going to have string value ”true” or ”false”. The esId request returns true if player has successfully hosted/joined the session and esActive returns true if all players joined the session. A false value can sometimes be expressed trough exception message e.g. if player tries to join multiple times an exchange session or if player tries to join an active session. However, only a response with data content ”true” is a success- ful/positive operation. Previously mentioned parameters are meant to invoke the following functions, with ”es” prefix, from app/appAjaxReq.js library : • esOpen(url, esId, destObject) host/join exchange session • esActive(url, destObject) check if exchange session is active where url is the URL of the ServletME instance and detsObject is an object used to store a response value. The esOpen function requires an exchange session esId argument, client is willing to host/join. All the other commands are related to message box operations and those will be explained in details in the following section 4.1.2. 36
    • 4.1.2 Browser Message Box Starting at ManagerME class that contains a vector of a MessageExchange classes where you can find a SessionME and array of BrowserME classes particularly linked to an exchange session, all the way to MessageBox class. As has been said, every browser has its own message box on a web server. This box is represented as a Browser.MessageBox class. An owner of this message box will have benefit to receive messages and to manage it through the HTTP requests. Since each client’s browser instance can be involved in only one message exchange session, it indicates that a browser instance can have only one active message box. In fact, any client can open multiple sessions and therefore multiple message boxes, but only if the browsers don’t share memory space. If client tries to host/join multiple exchange sessions with the same browser a JSESSION value remain the same and it will refer only to the last hosted/joined session. Important notice is that client can’t go backward and reuse an existing message box if he has hosted/joined a different session. The message box class has to be simple as possible, therefore it can receive one and only one message. This message cannot be overwritten if there is another incoming message, instead the mail box owner have to read the message first and than to execute command that will delete the message. The message box has to be managed and messages should be sent by client, hence there has been provided a few management commands. The managing commands are following: • Received message 1. READ: Read a message from the box. If there is no message in the box return ”false” value. 2. DELETE: Delete a message from the box. If there had been a message in the box return ”true” value, otherwise return ”false”. • Intended message 1. REQUEST TO SEND: Ask is a receiving box capable to receive a message. Response is the boolean ”true” or ”false” value 2. SEND: Send a message. A response is ”true” value if the message is sent successfully , or ”false” otherwise. where all the commands are obvious except the ”request to send” command. If client pi wants to send a message to pj , where i = j, firstly he should send a ”request to 37
    • send” to a web server. The pi can check if there is already a message in pj message box. If there is the message, pi can move on with sending a ”small” size packets to a web server, until pj is available to receive the message. Without this command a pi would be forced to send ”large” packets, and this can be highly inefficient if the pj message box is unable to receive those packets. There has been predefined a limit l of messages inside the message box. The limit has to be enough to exchange all the necessary data between two browsers, while subsystem complexity is reduced to minimum. This limit is set to limx→∞ l = 1 where x is the number of messages on wire directed to one of the message boxes. Of course, each client is responsible to maintain his message box in order to allow new messages to be received. Therefore, each client has to know the subsystem’s predefined maintenance commands used for read, delete, send etc. Some protocols can require more than one message to be sent (or to be received) at the same time, which would make this exchange aspect ineffective. The mentioned inefficiency can be noticed e.g. in an OT protocol part inside the Yao’s protocol when a multiple binary inputs has to be exchanged in order to evaluate the circuit. Since this system relies on Yao’s protocol, exchanged messages can be adopted to perform this subsystem with maximum efficiency, e.g. parallelization of OT7 step. An advantage in the accepted n = 2 exchange scenario is that each client pi can send a message to the opposite party pj without any informations on message destination. This feature is allowed by background logic of the subsystem where i, j ∈ {0, 1} and i = j are used to discover who is a pj party. Therefore, pi will send a message to the ServletME and the message will be stored directly in a pj ’s message box. All HTTP requests from clients will be sent with help of the AJAX technology. These requests are predefined on a ServletME used for message box management over few basic predefined functions to read, send, delete message. Requests to the web server, followed by responses to the browser, should contain following HTTP parameters: • GET, getMsg - get message from personal message box • GET, delMsg - delete message from personal message box • GET, reqSend - request to send message to other client • POST, without a parameter - send message to other client 7 Oblivious Transfer(OT) is a cryptography technique described later in chapter 4.2.2 38
    • Figure 4.2: Ideal message exchange flow in an active session of two-party message exchange system In order to exchange messages the clients will have to send one of these HTTP requests to a web server over a previously opened exchange session (figure 4.2). This session with another browser has to be also active before sending a message. As it has been shown, the clients also need to have some additional parameters (commands) used to execute a few basic controls over their mail boxes, e.g. delete a message before receiving another one. There are two possible responses for each HTTP upload (POST) request method to a server, ”true” or ”false”. If there is no message inside the box, the message will be stored and server will return value ”true” as in figure 4.2. Response will be ”false” if there is an undeleted message in the box, thus sent message will be discarded. For that reason, one of the GET parameter requests reqSend is intended to spare unnecessary network traffic i.e. sending a messages that cannot be stored. All these methods have been designed to provide message exchange in between players browser for the SBC with help of following cryptographic libraries. 4.2 Cryptographic Library A generic type of secure computation (SC) was suggested by Yao [28] in his seminal work where he introduced the notion of a secure function evaluation (SFE). In that work Yao raised the issue of two millionaires Alice and Bob, eager to determine whom of them is richer, but reluctant to reveal their actual wealth. Assuming Bob’s and Alice‘s amount of a wealth is i and j respectively, where i, j ∈ [0, N ] and N ∈ N. 39
    • In order to determine who is richer they should evaluate a following protocol 1 i≥j f (i, j) = 0 otherwise. where f = 1 claims that Bob is richer. In secure multi-party computation (SMC) the millionaires problem represents only a special case of a broad issue. In SMC [11], set of n players Pi , where i ∈ {1, . . . , n} wish to jointly compute an arbitrary function of their private inputs y1 , . . . , yn = f (x1 , . . . , xn ) with each party Pi private input xi . There is no Pi that is willing to reveal his private input xi to Pj , where i = j. This rule is also valid for the outputs where each party Pi receives only their output yi without learning or inferring anything else, except what can be inferred from input xi and yi [10].8 In general definition the SMC allows to the players P1 , . . . , Pn computation of a public function f (x1 , . . . , xn ) = (y1 , . . . , yn ). The computation is privacy preserving, i.e. nothing else is revealed to a player than what is inferable by his private input and the outcome of the function. This work, more generally, focuses on the following two-party SFE problem. Alice has an input x = x1 , . . . , xs and Bob has an input y = y1 , . . . , yr where s and r are their input size respectively. They both are willing to learn f (x, y) for an agreed public function f , but without revealing any information on their inputs. In order to evaluate the SFE with help of a Yao protocol, there have been developed indispensables JavaScript libraries for the final web application. As a part of this work, the following libraries were developed: • crypto/digest/sha1.js Secure Hash Algorithm SHA-1 JavaScript library • crypto/ot Oblivious Transfer JavaScript package • crypto/yao Yao’s garbled circuits JavaScript package where crypto/ot and crypto/yao are composed out of multiple objects. All these libraries are sorted by dependence, but each library is going to be explained in details in following sections. 8 In a two party setting the function y = f (x1 , x2 ) = x1 + x2 , where y is output for each Pi . The party Pi cannot compute function y without learning the party’s Pj input xj . But it is obvious the each player can reveal the other players input if commits a simple subtraction. In order to keep both inputs private an introduced secret sharing scheme by Shamir[25] and Blakley[2] needs to be applied. 40
    • bit size Output Internal state Block Max message Word Rounds 160 160 512 264 − 1 32 80 Table 4.1: Characteristics of Secure Hash Algorithm SHA-1 4.2.1 Secure Hash Algorithm SHA-1 Theory. A hash function is a deterministic procedure that takes an arbitrary block of data and returns a fixed-size bit string, the hash value, such that change to the data will ideally change the hash value. A message digest is a secure one-way hash function that take arbitrary-size data and outputs a fixed-length hash value. The SHA is called secure because it is designed to be computationally infeasible to recover a message which produce the same message digest. In this work a library has been developed that produces a 160 bits long message digest. This is the Secure Hash Algorithm SHA-1, derived from his predecessor SHA- 0. SHA-1 is a symmetric cryptographic function that is actually used in the Yao protocol for actual circuit garbling described in section 4.2.3. It has been chosen because for convenience of a block cipher usage9 , therefore it supports a variable input length. Some of its main characteristics are presented in table 4.110 . Practice. This function is the most frequently used function in the entire appli- cation i.e. this function will be called multiple times for every wire in the circuit. Because of that, the key objective to achieve is to obtain a hash function which performs as fast as possible, but written as a JavaScript library. Consequently, exclusively for this application, a JavaScript library sha1.js in crypto/digest package has been developed. Whole (mostly binary) background processing is hidden behind a dedicated function which requires a message as an argument. This function is defined as function sha1(message) and returns the message hash value in a BigInteger11 object. This is a key function of the library, while all the other functions are used as a behind logic used by the key 9 In cryptography, a block cipher is a symmetric key cipher operating on fixed-length groups of bits, called blocks. 10 Internal state means the internal hash sum after each compression of a data block. 11 The jsbn is a pure JavaScript implementation of arbitrary-precision integer arithmetic. Basic library (jsbn.js) contains BigInteger implementation which is just enough for RSA encryption and not much more. The rest of the library (jsbn2.js) include most public BigInteger methods. 41
    • function. It is important to notice that the message argument is also a BigInteger object. This was useful since all the random values used in circuit were already represented as a BigInteger object. Its performance was the most important point since overall time increases linearly with time necessary to compute hash function. This time cannot be neglected when a circuit size increase to, and exceed, 60 000 gates. In performance comparison with the other, well known, open source SHA-1 libraries (available on Internet) this library had the best performance. 4.2.2 Oblivious Transfer Theory. An important primitive in SMC is Oblivious Transfer (OT) introduced by Michael O. Rabin in 1981.12 The OT is a widely used primitive in many secure computation protocols. For example, in Yao’s garbled circuits (section 4.2.3), in the Fairplay system by Malkhi [7] as well as in the multi-party version of Fairplay, FairplayMP [1]. Both Fairplay systems enhance the Yao‘s original construction.13 In this case the most basic set-up is used. In general description, Bob has two bits(messages) m0 and m1 , while Alice has a bit of choice b. Evaluating the protocol will reveal mb to Alice, but nothing is learned about m¬b and Bob didn’t learn the Alice’s secret input b. Used oblivious transfer scheme is based on the RSA cryptosystem, as can be concluded from the following paragraph. Consider a party P1 eager to send k of its n inputs to party P2 while resting assured that P2 cannot learn anything about the other n − k values. Furthermore, P2 is unwilling to reveal to P1 which k of the n inputs has been choose to receive. Even at [23] is presented the first 1 − 2 oblivious transfer scheme14 , which can be generalized to 1 − n and k − n OT schemes, [16] and [9] respectively. Plenty of research has been conducted on efficient and secure OT protocols. Naor and Pinkas [17] significantly improve their earlier 1 − n approach, but they were surpassed by the OT scheme of Tzeng [26], who also devises enhanced k − n OTs [5]. The Chu and Tzeng [5] OTn protocol of will be presented. Required protocol’s k system parameters (g, h, Gq) where g and h are generators of the Gq group of prime order q, subgroup of Z∗ . q 1. P2 choose k inputs he want to retrieve, denoted σ1 . . . σk , and constructs a 12 Rabin’s form was improved later by Shimon Even, Oded Goldreich and Abraham Lempel[3], in order to build protocols for secure multiparty computation. It is generalized to 1-out-of-n OT 13 Yao original construction is described in [29]. 14 One out of two oblivious transfer scheme, also denoted OT21 42
    • polynomial f (x) = b0 + b1 x + . . . + bk−1 xk−1 + xk , such that f (x) = 0 if x ∈ σ1 . . . σk . Additionally, they choose a polynomial f (x) = a0 + a1 x + . . . + ak−1 xk−1 + xk , where ai being uniformly random in Zq , to mask f (x) by Ai = g ai hbi . 2. P1 receives kAi s from P2 and computes k−1 k Bi = g f (i) hf (i) = A0 Ai . . . Ak−1 (gh)i mod p 1 i k where Bi is used as a public key to encrypt each message mi , ci = (g ki , mi Bi i ) and ki is sampled uniformly randomly from Z∗ . q 3. P1 sends the nci s to P2 . Since Bi = g f (i) hf (i) = g f (i) h0 = g f (i) , mi can be decrypted by P2 , using a secret key f (i), if i ∈ σ1 . . . σk . 15 Execution of such a protocol multiple times can allow to Alice to secretly choose vector of bits, or in other words, e.g. secret integer input.16 It has been developed 1-out-of-n OT where n will be replaced with the number in the protocol. In this work n = 2 has been used, since messages are binary values. The implementation described by Naor and Pinkas [17] is a best-known implementation that allows both extensions to be efficiently incorporated (with limited scalability). The inclined reader is referred to Goldreich [10] for further deliberations on OT. Practice. This is a vital part of the Yao’s protocol and its performed before the evaluation step. Here occurs an exchange of encrypted binary values between host and guest. These values are used for as guest’s input to the binary circuit, but without reveling to host the actual input value. This part of the protocol has to be repeated for every guest’s input bit. More precise, for every input bit the OT process has to be repeated until pj reveals the input y necessary for the evaluation. The pj has a vectorial input and it is going to be transfered in ”parallel”, in one message. The parallelization of the OT protocol will increase efficiency of the load in TCP/IP package. Required data to transfered in one OT process is trivial. E.g. instead of sending a 32 TCP/IP packages for a 32 bit input, only one TCP/IP package will be sent that contains all data in one ”parallelized” OT message. This message is actually a string which describes an object in JSON format. This also satisfies a message box limitation where limx→∞ l = 1 mentioned in section 4.1.2. 15 Vσi Let ci = (Ui , Vi ), then mσi = f (σ ) Uσ i i 16 Furthermore, such a protocol can be extended to choosing among more than two options. 43
    • In this work the 1-out-of-n Oblivious Transfer technique has been used. This technique is designed for only 2 parties. These two parties will be called host and guest. The host is offering n messages mi , where i ∈ {0, . . . , n − 1} and n ≥ 2. The guest uses his choice value c to discover one, and only one, message mc without reveling c to the host. The value of n in this work will be n = 2 for only two bits m0 and m1 . The functions for serialization and deserialization of private key and public key have to be provided. A public key will be generated from a dedicated function of private key object. This public key has to be transmitted over the network to a guest. Once oblivious transfer start, the guest should own a public key and cipher for every message. All this data is stored in a public key object and the idea is to transfer serialized objects (except actual private key) in JSON format. This ability has to be provided for further development i.e. trying to make smoother data communication between two different types of systems. To bring this into practice the oblivious transfer scheme must be followed. It relies on the RSA cryptosystem, thus private and public key objects were developed. All objects from following listing are used to contrive oblivious transfer process to run. This library’s path is crypto/ot and its also a JavaScript library where every object contains ”ot” prefix: • otPrivateKey.js is used to create OT private key object • otPublicKey.js is used to generate OT public key object out of specific pri- vate key • otHost.js is an OT host object which provide messages • otGuest.js is an OT guest object which should choose a message • crypto/ot/par is OT parallelization library – otHostPar.js is similar to an array of otHost objects – otGuestPar.js is similar to an array of otGuest objects where objects from crypto/ot/par package were developed as an expansion to crypto/ot objects. From this libraries it can be clearly noticed that technique relies on RSA cryptosystem. The cryptosystem instances are automatically used by inner functions in the host/guest objects. All previously listed objects from crypto/ot package are developed as the part of this work. Key objects for an application are OTHost whose constructor requires an array of messages to be chosen, as 44
    • function OTHost(messages, csr), and OTGuest whose constructor requires a choice index, as function OTGuest(choice, csr), from the messages array in the OTHost constructor. Both cases require a csr argu- ment as well. This argument is a CSRandom object internally used as a cryptograph- ically secure random number generator17 . The messages array m0 , . . . , mn−1 is an array of BigInteger objects, while the choice c is an integer value. Reason to chose a BigInteger object as a message will be explained later on in section 4.2.3. To provide parallelization there were introduced additional JavaScript objects OTHostPar and OTGuestPar. These classes contain the same constructors as OTHost and OTGuest classes, but with arrayed requested arguments. That is a matrix of messages mji in OTHostPar object and an array of choice values cj in OTGuestPar object, where j is the OT index. The inner functions are also the same, the only deference is that parallelized object will have an array to process instead of only one object. E.g. private/public key generation for only one OT process i.e. every input bit will require private/public key. In next listing the ”oth” and ”otg” OT functions are sorted by steps in execution process (refereed to host/guest): 1. OTHost’s function othGetPublicKey() returns public key intended to guest 2. OTGuest’s function otgSetPublicKey(otPubKeyString) stores public key out of string received from host 3. OTGuest’s function otgEncodeChoice(toJson) return guest’s encoded choice intended to host, where toJson is a boolean value used to request response in stringified JSON format 4. OTHost’s function othCreateCiphers(encodedChoice, toJson) creates mes- sages ciphers out of guest’s encoded choice 5. OTGuest’s function otgDecryptChoice(ciphers, cipherRandom) decrypts cho- sen message from received ciphers18 17 A cryptographically secure random numbers are crucial in cryptography and therefore a CSRandom class is ”imagined” as their generator. The CSRandom is an important object and it is described in appendix A. 18 A inclined reader is refereed to [17] for description of cipherRandom value. 45
    • Listed functions are designed to be used in single OT execution, dough OTHostPar and OTGuestPar from crypto/ot/par library use same functions but for multiple OT executions. The functions for serialization of the OTPrivateKey data and OTPublicKey ob- ject in JavaScript have been provided. A BigInteger number is transformed into the string, rather than transmitting entire BigInteger object. The deserialization pro- cess is exactly opposite, therefore with an exception on creation of the BigInteger objects from strings. A BigInteger is indispensable in RSA cryptography, hence all this deserialized objects will used for all further computations. 4.2.3 Garbled Circuits Theory. Before elaborating on specific protocols for SMC we need to formalize the notion of security and define allowed adversely behavior. Any secure function evaluation (SFE) has to privately compute the correct outputs [Canetti [3], p. 151]. A private computation reveals no input or output data of any party, except what each party can infer from his own input and output. The computation is performed correctly if Pi party receives his output yi , such that y1 , . . . , yn = f (x1 , . . . , xn ) is calculated on all consistently submitted inputs. The first general SFE protocol for functions represented as one-pass boolean circuit was introduced by Yao [29] and has been adapted to manifold applications. The original protocol could only be employed in a two-party setting with semi-honest parties19 , but was extended to to be suitable for multi-party SFE applications by Beaver [6].20 In the two-party setting the protocol to securely evaluate (yA , yB ) = f (xA , xB ) can be outlined as follows [7]: 1. Alice and Bob agree on a circuit C(xA , xB ) = (yA , yB ) to evaluate f . There- after, Bob constructs the encrypted circuit EC(EiA (xA ), EiB (xB )) = (EoA (yA ), EoB (yB )) and sends it to Alice, along with his input EiB (xB ) and the key for Alice‘s output oA . The construction of EC requires several steps [13]. Assume that circuit C comprises gate g, with two input wires wi1 and wi2 as well as one output wire wo . For each wire, two random keys t0 and t1 are generated to mask wire value i i 0 and 1, respectively. The wire keys are only known to Bob. Alice, who will 19 A rigorous security proof is presented by Lindell and Pinkas [13]. 20 Or the presence of active adversaries by Goldreich [11] 46
    • Figure 4.3: Steps to create the Permuted Encrypted Garbled Truth Table 0 1 be evaluating EC, can not distinguish between wi and wi , thus remaining oblivious of the wire value. To hinder Alice from gaining knowledge of all σ κ θ output wire keys of gate g and limiting their to obtaining wo = g(wi1 , wi2 ) where σ, κ, θ ∈ 0, 1, the truth table (TT) of g needs further processing. For κ θ σ κ each entry (wi1 , wi2 ) the corresponding output value wo is encrypted using wi1 σ and wi2 as keys, hence, Alice can only decrypt a single entry of the TT for further circuit evaluation. Concludingly, Bob permutes the entries in the TT, yielding the permuted encrypted garbled truth table (PEGTT), wherein the position of a specific entry reveals no information about the actual wire values as in figure 4.3. A more formal construction of the PEGTT can be found in Catrina [4]. Malkhi [7] propose a cut-and-choose enhancement to this step. Bob constructs m encrypted circuits ECi and sends all of them to Alice, who chooses one ECη to be evaluated. Bob reveals the secrets of the other ECi where i = η to Alice, enabling her to verify the construction of them, since C is known to both. Therefore the probability for Bob to successfully cheat by 1 constructing tampered circuits is reduced to m. 2 2. Alice obtains EiA (xA ) from Bob, without revealing xA . A OT1 protocol is employed |xA | times, in order to provide Alice with the appropriate wire keys wi i for xA [i] = σi , without disclosing wi¯i . σ σ 3. Than Alice calculates (EoA (yA ), EoB (yB )) from EC(EiA(xA), EiB(xB )) and sends EoB (yB ) to Bob. Both parties decrypt their respective inputs and con- clude the SFE. 47
    • Figure 4.4: An overview of Yao protocol. In this work a shorter version of the Yao protocol has been accepted. This version skips cheat probability step and assumes that Bob is already trusted party. Since, in a real-world scenario cheating leads to bad reputation, this can be sufficient motive to adopt short version of the Yao protocol. The basic symmetric cryptographic function used for a circuit encoding(garbling) is SHA-1, which has been described in the section 4.2.1. The encoding of the circuit can be implemented using a pseudo-function (as is described in detail, for example in [15]), where the output of the function is used as a one-time pad21 that masks the values in the truth table representing a gate in the circuit. There has been used the masking values SHA-1(wi ||k||x||y), SHA-1(wj ||k||x||y) for entry (x, y) of the table of gate number k, whose input wires are i and j.22 The underlying security assumption is that SHA-1 is pseudo-random function keyed by wi or wj and applied to other parameters. Following enumeration shall clarify the steps to evaluate the Yao protocol from figure 4.4 in more details: 1. Translate the common functionality f into a circuit C as described at the beginning of the section. 2. Bob runs the circuit encryption algorithm on C (see figure 4.4). 3. The output is a vector g of n (garbled, keyed, encrypted and sorted) gates g1 , . . . , gn (with references to the input gates or wires). 21 In cryptography, the one-time pad is an encryption algorithm in which the plaintext is combined with a secret random key or pad, which is used only once. 22 Note that wires i and j could be input into multiple gates. 48
    • 4. Bob sends g , the keys for his garbled inputs and the random (garble) bits for all output wires to Alice. 0 1 5. Bob prepares Alice’s garbled input bits kwA and kwA . x 6. Alice obtains via oblivious transfer all encrypted kwA . A 7. Alice executes the garbled circuit. The result is a vector of output bits y . 8. Alice sends y to Bob. There are many other SC schemes for general purposes and specific tasks that goes beyond the Yao‘s protocol. Those have been proposed in the literature. Practice. As can be concluded from the theory, the main objective is to develop libraries to support evaluation of the Yao protocol. Firstly, a main JavaScript li- brary has to be developed in which functions can be used for Yao protocol execution, excluding OT protocol. This library has to provide functions for a circuit wire cod- ing, PEGTT generation, Output Translation Table23 (OTT) generation and circuit evaluation. Secondly, two JavaScript objects have to be developed intended to host and guest, or Bob and Alice respectively. These classes should use functions from the main library to accomplish their protocol requirements. The guest will evaluate the circuit will expect from host to send encrypted (garbled) circuit, host’s garbled inputs and decryption key for the output bits, or OTT. For example, host object has to be able to create encrypted circuit out of BCDL object and to pack all necessary data in order to transfer to guest Yao object. From here Yao guest object should be able to unpack the received data and to evaluate the garbled circuit once OT process is completed. This system requires, as mentioned in previous chapters, a symmetric crypto- graphic function library (section 4.2.1) used for a circuit garbling and a library for oblivious transfer feasibility (from section 4.2.2). Of course, whole system relies on browser to browser exchange subsystem presented in this chapter under section 4.1. Both players should run this application from their web browsers, hence the usage of this system is inevitable for Yao protocol and oblivious transfer data exchange. All objects from the following listing are used to accomplish specific Yao protocol tasks. The libraries path is crypto/yao where every instance contains ”yao” prefix. There is a one JavaScript library and two JavaScript objects: 23 Output Translation Table is some sort of decryption key for the circuits output bits. This information is obligate, since guest should decrypt circuit’s output after evaluation. This was already pointed out in the theory paragraph. 49
    • • yaoGarbledCircuit.js is a main library with dedicated functions used to garble and evaluate the circuit. • yaoHost.js is an object intended to the host with all the necessary functions used to accomplish host’s part of the protocol • yaoGuest.js is an object intended to the guest in a Yao application where host/guest object are developed to have benefit from yaoGarbledCircuit.js library. This library deals with a BigInteger objects in more that 90% of its content. Thus, inner functions use BigInteger predefined functions for power, module, shift, AND, OR and XOR operations. The entire crypto/yao package is developed as the part of this work. Key objects for an application are YaoHost whose constructor requires an array of chosen circuit inputs, BCDL object and CSRandom object, as function YaoHost(input, circuit, csr), and YaoGuest whose constructor requires array of the chosen inputs and BCDL object, as function YaoGuest(input, circuit), where circuit argument is BCDL object they’ve agreed upon.Only YaoHost require a csr argument. This argument is a will be used internally as a cryptographically secure random number generator used to garble the circuit24 . In next listing the ”yaoh” and ”yaog” protocol functions are sorted by steps in execution process (refereed to host/guest): 1. YaoHost’s function yaohCreateWireCodes() returns encrypted wi codes for all wires in the circuit 2. YaoHost’s function yaohCreatePEGTT() will return circuit’s Permuted En- crypted Garbled Truth Table 3. YaoHost’s function getOTT(gates, wireCodes, outputWires) return Out- put Translation Table before evaluation 4. YaoHost’s function yaohPackData() returns packed data ready to be trans- fered to the YaoGuest object 24 Same as in host/guest constructors in Oblivious Transfer library from section 4.2.2. 50
    • 5. YaoGuest’s function yaogUnpackData(dataString) shall unpack and store the data received from the YaoHost object 6. YaoGuest’s function yaogEvaluateCircuit() will evaluate the circuit, once guest has all necessary data, and return the result25 As mentioned, the listed functions from JavaScript objects are designed to use func- tions from yaoGarbledCircuit.js library, in order to accomplish Yao protocol and to facilitate data exchange between the YaoHost and YaoGuest instances. 4.3 Web Yao Application Structure Infrastructure of application has to be designed to use entire crypto package de- scribed in section 4.2. Even if the all necessary functions have been provided in this package, there is also a necessity for work flow of those subsystems. Therefore, an application work flow package has to be developed. This package has to provide work flows for message exchange session, oblivious transfer and yao protocol subsystems. A web application have to be separated in two smaller applications, host and guest specific applications. Both these applications should contain objects from crypto package in order to go through all necessary processes, until circuit result is revealed to both parties. E.g. even if oblivious transfer is a part of the Yao protocol the libraries were separated, but still both libraries have to be employed. As such, both main web applications objects will contain three sub-library ob- jects. The first object will open and activate a obligate browser to browser message exchange session. The second one will start first part of Yao protocol. The second section will finish, in its second part, after the oblivious transfer. The third ob- ject will provide the application for OT protocol. Exact application steps will be explained later in this section. One of key requirements was to automatize the entire web application flow, hence a JavaScript /app package has been developed. With this package the application flow is fully automatized, once player inserts his input data and starts with execution. In following listing describes all package libraries and objects from figure 4.5: • appAjaxReq.js library is used to facilitate usage of an AJAX GET/POST request in a web application • appBw2bw.js object was written to follow step execution in a browser to browser exchange session to effectuate an active session 25 A inclined reader is refereed to [17] for description of cipherRandom value. 51
    • Figure 4.5: Web application structure objects • appHost.js is a work flow object for every host’s step until application exe- cution is over • appGuest.js is a work flow object for every guest’s step until application execution is over • app/ot package contains OT work flow objects – appOtHost.js is a JavaScript object used for host’s OT execution – appOtGuest.js is an object used for guest’s OT execution • app/yao package contains Yao protocol work flow objects – appYaoHost.js object contains 2 parts for a host’s Yao protocol execution – appYaoGuest.js is a 2 part JavaScript object for a guest’s Yao protocol execution All listed objects are previously mentioned application objects, with exception on appAjaxReq.js which is a facility library for AJAX requests. All the application objects are closed in a their step execution function. This function shall be invoked in order to proceed to a next application’s step. It will automatically check a sub- application’s inner state value and regarding to that value the function shall decide which command to execute. Once application arrives to predefined lastState value, it will move on to the next sub-application until the main application steps are completed. Thus, application steps are limited by its final state hard coded in lastState variable, while current state can be read from state variable. These functions are developed for web application functions with the ”mb” prefix from the JavaScript library app/appAjaxReq.js: • mbGetMsg(url, destObject) get a message from the box • mbDelMsg(url, destObject) delete a message in the box 52
    • • mbReqSend(url, destObject) check a message can be sent • mbSendMsg(url, message, destObject) send a message where url is URL of the ServletME class and detsObject is an object to receive a response value. It is obvious that all these functions are valueless except the last one, where a message argument is a pointer to the message to be sent. This function calls the ajaxDoPost function, while all the others invokes the ajaxDoGet function from the appAjaxReq.js library already mentioned in the section 4.1. The browser to browser message exchange sub-application for host and guest are the same. This object is named AppBw2bw and it contains only one application step. It is already mentioned that the message exchange session will be inactive until all players join the session. Thus, this step will constantly test the statement of the exchange session. Once session becomes active the application will move on the AppYaoHost/AppYaoGuest object in the first part of Yao application. Both, the host and the guest, Yao sub-applications are divided in 2 parts. First part shall be executed before OT step of the Yao protocol (figure 4.4). The second part shall be executed once the OT process in accomplished. Hence, the two parts of the host/guest Yao protocol in a web application contain fallowing states: • Host - Supplier (part 1) 1. Create wire codes for entire circuit 2. Create Permuted Encrypted Garbled Truth Table (PEGTT) 3. Create Output Translation Table (OTT) 4. Garble Host’s inputs used for evaluation 5. Pack data necessary for the encrypted (garbled) circuit evaluation 6. Send request to transmit data to guest’s message box 7. Acknowledge of data reception • Guest - Buyer (part 1) 1. Check in message box for garbled data transmitted by host 2. Store data in YaoGuest object 3. Delete received data message from message box • Host - Supplier (part 2) 1. Wait to receive the circuit evaluation result from guest 53
    • • Guest - Buyer (part 2) 1. Prepare host’s and guest’s garbled inputs and evaluate the circuit 2. Send request to transmit the circuit evaluation result 3. Acknowledge of result reception A reader can notice that there is no single lastState value for this object. Instead this object has lastState1 and lastState2 values. This is exactly the same ap- proach as in the other applications, it can be rather considered as two separated sub-applications. Once application arrives to predefined lastState1 value, it will move on to the OT sub-application. On the lastState of OT sub-application the main application will execute once again the Yao sub-application (2nd part). It will start from lastState1 until it reaches the lastState2 inner state value. As said, after the first part Yao sub-application the main application will proceed to OT sub-application. The final application will use only crypto/ot/par package, the OTHostPar and OTGuestPar objects. This can be seen in following host/guest state listing of the oblivious transfer work flow in a web application: • Host - Supplier 1. Create public keys for Guest 2. Send request to transmit public keys 3. Acknowledge of public keys reception 4. Wait to receive encoded choice of message from Guest 5. Create encoded choice ciphers 6. Send request to transmit ciphers 7. Acknowledge of ciphers reception 8. Delete Guest’s encoded choice message from message box • Guest - Buyer 1. Read public keys submitted by Host 2. Setup public keys 3. Delete Host’s public keys message from message box 4. Encode circuit input choices 5. Send request to transmit encoded choices 6. Acknowledge of encoded choices reception 7. Wait to receive ciphers for each message 54
    • Figure 4.6: Web Yao application layered communication between host and guest 8. Decode chosen messages The parallelization is obvious since host is creating multiple keys in first OT step. Each key is going to be used for one OT process i.e. one key for every guest’s input bit. Also in this listing can be noticed that in this process there is a lot of interaction between players. This interaction relies on the previously mentioned appAjaxReq.js library. The key objects in main application are AppHost and AppGuest, located in the app package. These objects are fully automatized. From this point, in any custom web application a constructor of the JavaScript object AppHost shall be called with function AppHost(input, circuit, csr, urlMsgBox) which require four arguments. It requires desired host’s input to the circuit, cir- cuit itself as BCDL object, cryptographically secure random generator and URL to browser to browser message exchange web server26 . After the AppHost initialization the AppYaoHost and AppOtHost objects will be generated internally. As has been said, once the AppHost object is generated all the steps should be executed with only one function. Since there are multiple sub-applications, there has to be provided additional function to check internal sub-application state. Mentioned functions, for AppHost, are the following: • apphExecute() will return current application state after the application step execution • function apphIsLastState() returns boolean value that says if application has reached its last state 26 The URL value shall be direct link to the ServletME, as described through example in section 4.1.1. 55
    • Figure 4.7: Entrance portal for the web SBC application Of course, the AppHost object will call this sub-application functions automatically. Thus, every sub-application has this functions, even AppHost. After execution step the execution function shall return application current status value. This values is going to be used to visualize steps in an application GUI, in client’s browser. In this listings were only presented host’s application functions with ”apph” prefix. The AppGuest object have the same functions (even constructor arguments) as AppHost, but with prefix ”appg”. 4.4 Graphic User Interface Design It has been said, and showed, in the section 2 that the final web SBC application starts with an internet portal. On this portal a player can host a SBC and invite the guest to join. This section will only provide additional information by explaining a scenario from 4.7 and 4.8 figures. Once player enters the portal he can expect a few input requests. On the left side of the figure 4.7, a player should choose preferred function to compute with his business partner. When partner chooses the evaluation function, than he should input required emails into text boxes. After that he should just press ”Host SBC” button that will despatch player’s request to invite guest (or buyer) to join the newly created SBC session. From that point, player is automatically redirected to the host (or supplier) SBC 56
    • Figure 4.8: The web SBC application in the middle of an evaluation application and his invitation mail will be sent to the guest from the hosting web server. Now, the host can input the requested data and initiate the SBC execution. This event will take block player’s inputs and than player has to wait until the guest joins. When player receives the join link he is going to be redirected to the buyer’s application. Once both players have started with application execution than they can see the visual status of their secure business computations, as on the left side of the figure 4.8. Application tends to check all check boxes, until the SBC is completed and result is computed (for guest) or receved (for host). This result will be shown in SBC output text box, as shown on the right side of the figure 4.8. Of course, this completes the secure business computation and now they may start another one. 57
    • Chapter 5 Evaluation The Secure SCM project will apply secure multi-party computation protocols to collaborative Supply Chain Management (SCM). The privacy guarantees of secure multi-party computation, i.e. the confidentiality of the inputs, fully remove the data sharing risks, i.e. no supply chain participant has to reveal its data. Nev- ertheless, the resulting globally optimized supply chain, has clear cost advantages over currently available solutions with local decision making. These advantages will provide a new perspective to collaborative supply chain management extending its scope to a number of application domains including manufacturing, logistics, design outsourcing, and others. Improvement of SCM is a Secure SCM project funding, but this work shows an example of secure collaboration. Therefore, in this chapter briefly introduces a Joint Economic Lot Size (JELS) function used in the collaborative SBC model. 5.1 Joint Economic Lot Size In a simple supply chain setting there is a single buyer (party A) and a single supplier (party B) of a specific product. The buyer and the supplier have negotiated a fixed supply quantity of d units per period. Without loss of generality it is assumed that the buyer decides upon his order quantity, denoted by qA , and the (corresponding) number of orders d/qA which he places to the supplier. It is assumed that the supplier has sufficient capacity to fulfill the buyer’s orders and that the supplier’s lead time is zero. The buyer’s total relevant costs T RCA (qA ) are given by d · fA qA T RCA (qA ) = + · hA qA 2 58
    • Figure 5.1: Periodic progressions of the supplier’s and buyer’s inventories under a lot-for-lot production policy. where fA denotes the buyer’s fixed cost per order and hA his inventory holding cost per unit and period. The first term in this expression represents the fixed ordering costs and the second term the inventory holding cost. Under the given assumptions, qA the average inventory per period is 2 (see figure 5.1). The buyer’s economic order ∗ quantity (EOQ), denoted by qA , can then be expressed as ∗ 2 · d · fA qA = hA It is assumed that the supplier follows a lot-for-lot production policy. He cannot accommodate lot-streaming and delivers the entire production batch after its com- pletion. The supplier’s total relevant costs T RCB (qB ) are d · fB d · qB hB T RCB (qB ) = + · qB 2 c where qB denotes the supplier’s production lot size, c the production capacity per period, fB the setup cost per production lot and hB his inventory holding cost per unit and period. ∗ The supplier’s economic lot size, denoted by qB , can be expressed as ∗ 2 · c · fB qB = hB Under the assumption of a lot-for-lot production policy, the lot size of the supplier will correspond to the order size of the buyer, i.e. qB = qA . The inventories of the 59
    • Figure 5.2: Supply chain’s costs versus lot size supplier and buyer will have the periodic progressions as depicted in figure 5.1. If there is no joint decision making between the buyer and the supplier, both parties ∗ ∗ would like to realize their individual optimal quantities qA and qB . In this work it is ∗ assumed that the buyer places orders of size qA and that the supplier has no means ∗ to influence the buyer’s decision. In this case qB = qA , resulting in total joint costs of ∗ ∗ ∗ JT RC(qA ) = T RCB (qA ) + T RCA (qA ) Based on these results it is easy to explain the underlying rationale of the JELS ∗ ∗ model: for any setting in which qA = qB there will be a ”Joint Economic Lot Size” (JELS) that leads to minimal joint costs of the buyer and supplier such that ∗ ∗ ∗ JT RC(qJ ) < JT RC(qA ). The JELS, denoted by qJ , can be expressed as: ∗ 2 · d · (fA + fB ) qJ = hB d· c + hA ∗ The figure 5.2 depicts the supply chain’s costs versus lot size. Obviously, qJ lies ∗ ∗ between qA and qB . 5.2 Setup Based on the general description of secure two-party computation provided in the previous chapters now it will be shown how a secure protocol for the JELS model 60
    • Figure 5.3: JELS circuit can be implemented. Thus, in the following text first propose the relevant JELS ∗ circuits for computing qJ . Thereupon it must be specified what the building blocks are used for the development of a BCDL object for the JELS model. Given a secure protocol, two supply chain parties can engage in collaborative planning without having to reveal any private data in the process of calculating the ∗ joint result. In order to implement a secure protocol for computing qJ based on Yao’s protocol we thus need to construct the corresponding boolean circuit BCDL ∗ object for qJ . It is emphasized that the necessary boolean circuits are one-pass, i.e. they may not contain feedbacks, registers nor similar constructions. To reduce the complexity of the circuits, it should compute qJ 2 instead of qJ . This significantly ∗ ∗ reduce the number of necessary gates, i.e. root computation is saved in the circuit for qJ 2 . Instead, qJ 2 can be used locally and non-securely to compute qJ without ∗ ∗ ∗ any loss of privacy, since both values can be transformed into their counterpart by a simple arithmetic operation. A qJ 2 formula can be represented as concatenations of basic arithmetic opera- ∗ tions. It can therefore directly compile the boolean circuits from the formulas given that we have building blocks for the basic arithmetic operations (in terms of sub circuits). Figure 5.3 depict the composition of basic arithmetic operations into a boolean circuit according to the formula of qJ 2 . It is assumed that all input and ∗ output values are within a jointly agreed domain D = [0; 2l − 1]. In figure 5.3 gray values on the left denote the private part of the buyer’s input to the circuit, while gray values on the top denote those of the supplier. 61
    • Firstly, a Boolean Circuit Description Language (BCDL) object has to be gen- erated before evaluation. It can be described with a SBCL1 , which will be parsed to In-memory formula2 object and then compiled to BCDL object, as described in section 3.3. Once BCDL object is created, the next step would be to deploy browser to browser message exchange system, and to upload the JELS BCDL object together with the web application onto the web server. In this work a demo web application stands behind a GUI where host (Supplier) is asked to insert his email address and guest’s (Buyer) email address in order to start SBC. Once supplier executes the SBC session the system will automatically send invitation email to the buyer. In this invitation the buyer can see who hosted the SBC session. If buyer is willing to execute the SBC with supplier he should click on direct link, written in email, to join SBC session. When buyer joins the session he should insert his private data and start the computation. Now both players can only wait until protocol is evaluated. In order to speed up secure computation all circuit input variables shall be pre- calculated values, otherwise the circuit size will increase which will linearly increase the computation time. Following code demonstrates JELS model described with SBCL for precalculated input values: 1: default-bits:32 2: 3: _2dfA:Bob 4: hA:Bob 5: _2dfB:Alice 6: dhB_c:Alice 7: qJstar2:Bob, Alice 8: 9: qJstar2=(_2dfB+_2dfA)/(dhB_c+hA) In this formula Bob is a supplier and Alice is a buyer. An example of precalculated value is 2 · d · fA required to be inserted by Bob. He can’t input all three values if desire is to minimize the circuit, because otherwise three building blocks has to be used. Detailed description of the SBCL language can be found in section 3.1.2. Previously described SBCL object will be parsed to in-memory formula and then compiled to BCDL. A final JELS BCDL object, with 32 bit input size, exported to JSON JavaScript variable looks like following: 1 Secure Business Computation Language is described in section 3.1.2 2 In-memory formula is described in section 3.1. 62
    • Figure 5.4: Number of gates in JELS circuit, respect to input size var circuit = { "input":[[{"wires":[0,...,31],"name":"2*d*fa"}... "tt":[[0,1,1,0],[0,0,0,1],[0,1,1,0],... "output":[[{"wires":[24009,24010,24011,24012,24013,... "gates":[[0,32,128],[0,32,129],[1,33,130],[130,129,131],... } This circuit weights 23914 gates and 24042 wires, while its memory size is 676.006 bytes, or 660KB. These from all gates there are 2 ∗ 158 = 314 for 32 bit addition and 23599 for 33 bit division. There can bi noticed that one gate is missing and this is a zero gate that is static for entire circuit, thus it will be reused whenever there is a necessary for binary zero value. Once the BCDL object is ready the web based SBC application, from section 4.3, should be tested. These testings were run in a test environment and as such cannot be considered relevant to real business application. But yet, all the data from test can be used in a consideration for ”minimum” time required for entire flow of the application. The tests were run on one work station which runs 32-bit operating system Windows Vista Enterprise with Service Pack 1 on Intel Core Duo T7300 2.0GHz with 2.00GB of RAM memory. This work station runs a web server on Apache Tomcat 5.5 required for the ”browser to browser” message exchange subsystem and the web SBC application with its libraries. As testing browsers there have been used Mozilla Firefox 3.6 and Google Chrome 4.0, the latest available versions at the time. It is important to mention that every instance (or process) runs on one Intel core, 63
    • by affinity settings in Windows Task Manager. While there was a support in Mozilla Firefox to run a two separated instances, there was none for Google Chrome. For that reason, there has been installed a VMware Player 3.0 to run a Linux Ubuntu 8.4 virtual machine. The virtual machine was set to use one, previously mentioned, Intel core and 512MB of RAM memory. In particular, this virtual machine was used to compare evaluation performance for two different instances of Google Chrome browsers. Running two different instances is important for comparison equality. But, the key solution was to use two instances which will use a separate memory space for their cache operations i.e. cookie storage. Thus, an instance require its own JSESSION cookie in order to run message exchange session, which is inevitable for the web SBC application. All the tests start its execution once the application runs on both parties. But still, the application start its execution with confirmation of an exchange session activation. If one party executes the application before activation of the message exchange session, it would have to wait until the other party joins the exchange session. This will increase overall time of the execution. 5.3 Results Results are represented rispect to their effective time and their wait time, in seconds. The actual timing of effective or wait time is not present on the chart, instead they are presented by section. In total there is four sections: browser to browser message exchange activation, first part of Yao’s protocol, OT protocol and secong part of Yao’s protocol. All these web SBC sections are sorted on the charts in down up order, as presented in section 4.3. All the timings are related to execution of the AppHost, and AppGuest, step execution function apphExecute() described in the section 4.3. The effective time means that application has changed its state after performing an execution on sec- tional objects e.g. AppOtHost, AppYaoHost, etc. Everything else counts as the waiting time in overall time of the web SBC application execution. Since most im- portant time is their wait efficient time, the following text will focus mostly onto it. Referencing to the figure 5.5, it can be seen how two Mozilla Firefox 3.6 per- formed on the same work station, where each had one dedicated Intel core. Im- portant notation is that the host had more efficient time in the first part of Yao’s 64
    • Figure 5.5: The web Yao application benchmark for two instances of Mozilla Firefox 3.6 on the same work station protocol, while in the second part he had only mostly wait (inefficient) time. This follows in relation to the exactly opposite result of the guest party. In the figure 5.5 host performed first part of Yao’s protocol in 85s, while gest performed the second part of Yao’s protocol in 226s. The approximate total web SBC application run time was 323 seconds. The figure 5.6 shows comparison between Google Chrome 4.0 and Google Chrome 4.0 that runs on virtual machine. They both performed on the same work station, where each had one dedicated Intel core. It is important to notice that Linux Ubuntu 8.4 virtual machine performed extremely fast, comparing to Windows Vista SP1. It can be noticed in the figure 5.6, for the first case, that the host performed first part of Yao’s protocol in 44s, while gest performed the second part of Yao’s protocol in 79s. The approximate total web SBC application run time was incredible 129 seconds. In the second case, the host performed first part of Yao’s protocol in 20s, while gest performed the second part of Yao’s protocol in 272s. The approximate total web SBC application run time was 297 seconds. These results are extremely different respect to the previously discussed from figure 5.5. It is obvious that Google Chrome 4.0 on Linux Ubuntu virtual machine performed more than twice as fast, as one that runs on Windows Vista, for the first 65
    • Figure 5.6: The web Yao application benchmark between Google Chrome 4.0 and Google Chrome 4.0 that runs on virtual machine part of Yao protocol. In second part of the Yao protocol the Linux Ubuntu virtual machine performed more than three times faster. While there is still a big question regarding this results it was obvious that Linux Ubuntu 8.4 performed better, in this particular case. The figure 5.7 shows comparison between instance of Google Chrome 4.0 and instance Mozilla Firefox 3.6 that runs on the same work station, where each had one dedicated Intel core. It is important to notice that Linux Ubuntu 8.4 virtual machine performed extremely fast, comparing to Windows Vista SP1. From the chart 5.7, in the first case, the host performed first part of Yao’s protocol in 87s, while gest performed the second part of Yao’s protocol in 274s. The approximate total web SBC application run time was poorly 380 seconds. For the second case, the host performed first part of Yao’s protocol in 42s, while gest performed the second part of Yao’s protocol in 193s. The approximate total web SBC application run time was 245 seconds. These results are satisfying and similar to some previously discussed results from figures 5.5 and 5.6. It is shown that Google Chrome 4.0 on Windows Vista performed in the first part of the Yao protocol, while Mozilla Firefox 3.6 on Windows Vista performed in the second part. 66
    • Figure 5.7: The web Yao application benchmark between Mozilla Firefox 3.6 and Google Chrome 4.0 on the same work station VF VF VC UC UC VC VF VC VC VF Yao1 / Yao2 85 226 44 79 20 272 87 274 42 193 Total 323 129 297 380 245 ≈ in seconds Host is left; V - Vista, U - Ubuntu VM; F - Firefox, C - Chrome Table 5.1: The web Yao application benchmark. Results form effective Yao and total evaluation run time Of course that there could be some performing variations, but these values are measured multiple times and only the best performed were chosen. But these vari- ations are almost irrelevant, like e.g. first and fourth test where Mozilla Firefox performed wiht variance of ≈ 2%, as shown in table 5.1 Additionally, these results don’t (almost) have any network delay, but it should be considered that the delay time directly effect overall execution time. Yet, effective time can be counted as definite, since most of it is spent on computation. 67
    • Chapter 6 Conclusion and Future Work Applied SBC on the JELS model is extremely relevant from an industry perspective. It exhibits numerous features that makes it very attractive for secure multi-party computation in a supply chain context. The practical obstacles related to the JELS model implementation has been shown: improving supply chain efficiency through a joint economic lot size between a buyer and a supplier is inhibited by need to reveal sensitive private cost and capacity data. It is assumed that in most supply chain settings neither one of the parties would want to share this data. Secure two-party computation is seen as a viable measure to overcome these obstacles. The main objective was to provide web based generic secure function evaluation system. The work was separated in two parts. First part required to develop high- level secure economic function description language SBCL. The second task was to parse SBCL and to compile BCDL object. Additional tasks were to minimize number of gates in the boolean circuit. In the second part the first obstacle was to make possible communication in between two internet browsers. The second one was to develop all the cryptographic libraries indispensable for the SBC application, while time limits have to be satisfied. And third task was to develop libraries intended to enable the web SBC application flow smoothly and automatically. An additional task was to prepare demo version which will be presented to future partners. The result is the fully operational application presented in chapter 4. It can be concluded that all objectives of this thesis work were accomplished. This work benefits from cutting edge technology in security models and proto- cols. Learning them were interesting experience, especially in a highly professional working team. An interesting fact was that boolean circuits were modeled in soft- ware, evaluated in an internet browser and all for business purpose. These extremes are interesting since they all appertain to the information engineering topic, so as 68
    • the course of my university. In conclusion, the overall work was really good planed, professionally supported and I would estimate this work as an excellent carrier ex- perience. After this research work the ideas continue to be developed even further. In fact, the current implementation of the secure two-party computation system can be extended in many ways. Some considered future work ideas follow up in text. Preliminary analysis suggests that the protocol’s performance significantly de- pends on the division operation. Thus, future work can be dedicated to finding improvements for building blocks of the protocols.1 Finding new improved building blocks for division is likely, and thus it will be of low priority. This could lead to two further contributions to the state-of-the-art: a prototype of the JELS model soft- ware for future demonstration and an analysis of the performance characteristics of different secure (two-party) division protocols and other future protocol design. Currently there is no implementation can prevent a malicious party from abort- ing the protocol prematurely(unfair termination) e.g. after learning its output and before the other party learns its output.2 There is no perfect solution for this pro- tocol issue and existing solutions are complex, but some can be implemented [20]. One of interesting future improvements is BCDL circuit compiler integration in L1 language. This language is used for faster development and benchmarking of cryptographic protocols described in Schr¨pfer [24]. It already supports evaluation o of circuits, but has no circuit generation component. While the generic construction of Yao can be used to implement any function- ality, more efficient constructions can be designed for specific tasks, e.g. computing comparisons or intersections, evaluating polynomials or querying a database. A se- cure protocol for a more complex tasks can use a circuit whose inputs are results of specialized constructions. For example, the protocol in [21] runs a circuit that com- putes statistical data based on the secure database queries results, or the protocol in [13] runs a circuit that uses the results of oblivious polynomial evaluation. This system is built for secure business computation between two parties. There is also a large body of research on SMC, for either combinatorial or algebraic circuits, with different trust assumptions (see e.g. [11, 14, 6]). A natural future step is to implement the SBC paradigm in the multi-party scenario. An additional open challenge is to devise fair termination protocol techniques even for SMC. 1 Proposed division block by Kerschbaum and Schr¨pfer has significantly reduced the size [19]. o 2 On the other hand, a premature termination of the protocol by one party is detected by the other party, which in many scenarios can then take measures against the corrupt party. 69
    • Appendix A Cryptographically Secure Random Number Random numbers are crucial in cryptography. Typically, they are added to the input data as padding to ensure the uniqueness when generate secure cryptographic keys. The security of these cryptographic procedures relies on random number that cannot be predicted. A true random number should not be influenced by external conditions, therefore some computers use a hardware-based random number generator, which measures an unstable electronic circuit or radioactive decay or other random physical process and thus can achieve independence of external effects. This is the case where such a hardware may not be practical, and computers have to fall back on software algo- rithms. Pseudo-random number generators use deterministic algorithm to generate random numbers, they are initialized, or ”seeded”, using a random number such as the current time. There was an obvious necessity for Cryptographically Secure Random number generator. That is why a CSRandom class has been provided. This class doesn’t offer cryptographically secure random numbers, instead it is designed as an option for future development since at the moment there were no libraries available that can handle the problem. Otherwise the possibility to track down the random number generator can put entire system to risk. For example, ff the algorithm and the initial seed values are known, the random numbers can be predictable. That is why these random number generators are termed pseudo-random number generators. In the final web SBC application CSRandom class is used for the pseudo-random number generation. It is used in all, previously mentioned, cryptographic libraries from crypto package. Thus it is meant to benefit from the dedicated CSRandom 70
    • object function in order to provide OT and Yao cryptographic steps with crypto- graphically secure random number generator. This function is function getCSRandom(bits, prime) where the requested arguments are integer random number bit size and request for boolean value, if prime number is requested. Return value is meant be BigInteger number from JavaScript Big Number library, or jsbn.js library. 71
    • Bibliography [1] N. Nisan A. Ben-David and B. Pinkas. Fairplaymp: a system for secure multi- party computation. In Proceedings of the 15th ACM Conference on Computer and Communications Security, pages 257–266, New York, NY, USA, 2008. ACM. [2] G.R. Blakley. Safeguarding cryptographic keys. In Proceedings of the 1979 AFIPS National Computer Conference, pages 313–317, Monval, NJ, USA, 1979. AFIPS Press. [3] R. Canetti. Security and composition of multiparty cryptographic protocols. Journal of Cryptology, 2000. [4] O. Catrina. Cryptographic aspects - secure computation models and frame- works. Technical report, SAP AG and Technische Universiteit Eindhoven and International University in Germany, 2008. SecureSCM Deliverable D9.1. [5] C.-K. Chu and W.-G. Tzeng. Efficient k-out-of-n oblivious transfer schemes with adaptive and non-adaptive queries. In PKC 2005: Proceedings of the 8th International Workshop on Theory and Practice in Public Key Cryptography, pages 172–183, Berlin, Heidelberg, 2005. Springer. [6] S. Micali D. Beaver and P. Rogaway. The round complexity of secure proto- cols. In Proceedings of the twenty-second annual ACM symposium on Theory of computing, pages 503–513, New York, NY, USA, 1990. ACM. [7] Benny Pinkas Dahlia Malkhi, Noam Nisan and Yaron Sella. Fairplay - a secure two-party computation system, 2004. [8] Funke Daniel. Secure evolutionary algorithms for collaborative supply chain planning. Master’s thesis, Baden-W¨rttemberg Cooperative State University, u 2009. 72
    • [9] C. Crepeau G. Brassard and J.-M. Robert. All-or-nothing disclosure of secrets. In Proceedings on Advances in cryptology, pages 234–238, London, UK, 1987. Springer. [10] O. Goldreich. Volume 2: Basic applications. In Foundations of Cryptography, Cambridge, UK, 2004. Cambridge University Press. http://books.google.com/books?id=Cy1wnNUT3DYC. [11] O. Goldreich, S. Micali, and A. Wigderson. How to play any mental game or a completeness theorem for protocols with honest majority. In STOC ’87: Proceedings of the nineteenth annual ACM conference on Theory of computing, pages 218–229, New York, NY, USA, 1987. ACM. [12] A. Karatsuba and Y. Ofman. Multiplication of many-digital numbers by au- tomatic computers. In Proceedings of the USSR Academy of Sciences, pages 293–294, 1962. [13] Y. Lindell and B. Pinkas. A proof of yao’s protocol for secure two-party com- putation. Technical report, Cryptology ePrint Archive, 2004. [14] S. Goldwasser M. Ben-Or and A. Wigderson. Completeness theorems for non cryptographic fault tolerant distributed computation. In Proceedings of 20th Annual Symposium on the Theory of Computing (STOC), pages 1–9, 1988. [15] B. Pinkas M. Naor and R. Sumner. Privacy preserving auctions and mechanism design. In Proceedings of the 1st ACM conf. on Electronic Commerce, 1999. [16] M. Naor and B. Pinkas. Oblivious transfer and polynomial evaluation. In Proceedings of the thirty-first annual ACM symposium on Theory of computing, pages 245–254, New York, NY, USA, 1999. ACM. [17] M. Naor and B. Pinkas. Efficient oblivious transfer protocols. In SODA ’01: Proceedings of the twelfth annual ACM-SIAM symposium on Discrete algo- rithms, pages 448–457, Philadelphia, PA, USA, 2001. Society for Industrial and Applied Mathematics. [18] Flynn Michael J. Oberman, Stuart F. Division algorithms and implementations. In Proceedings of IEEE Transactions on Computers, pages 833–854, 1997. [19] R. Piberbik, F. Kerschbaum, and A. Schr¨pfer. On the computation of secure o economic joint lot sizes. In To be published., pages 1–20, 2010. [20] B. Pinkas. Fair secure two-party computation. In Proceedings of Eurocrypt 03, LNCS 2656, pages 87–105. Springer-Verlag, 2003. 73
    • [21] R. Kumar M. Reiter R. Rubinfeld R. Canetti, Y. Ishai and R. Wright. Selective private function evaluation with applications to private statistics. In Proceed- ings of Twentieth ACM Symposium on Principles of Distributed Computing (PODC), 2001. [22] N. P. Redkin. On the minimal realization of a binary adder. In Proceedings of Probl. Cybern, pages 181–216, 1981. [23] O. Goldreich S. Even and A. Lempel. A randomized protocol for signing con- tracts. Communications of the ACM, 1985. [24] A. Schr¨pfer, F. Kerschbaum, D. Biswas, S. Geißinger, and C. Sch¨tz. L1 - faster o u develop-ment and benchmarking of cryptographic protocols. In Proceedings of ECRYPT Workshop on Software Performance En-hancements for Encryption and Decryption and Cryptographic Compilers (SPEED-CC ’09), 2009. [25] A. Shamir. How to share a secret. In Proceedings of Communications of the ACM, pages 612–613, 1979. [26] W.-G. Tzeng. Efficient 1-out-n oblivious transfer schemes. In PKC ’02: Pro- ceedings of the 5th International Workshop on Practice and Theory in Public Key Cryptosystems, pages 159–171, London, UK, 2002. Springer. [27] Heribert Vollmer. Introduction to Circuit Complexity: a Uniform Approach. Springer Verlag, 1999. [28] Andrew Chi-Chih Yao. Protocols for secure computations (extended abstract). FOCS, 1982. [29] Andrew Chi-Chih Yao. How to generate and exchange secrets. In Proceedings of the 27th Annual Symposium on Foundations of Computer Science, pages 162–167, Washington, DC, USA, 1985. IEEE Computer Society. 74