Fabian Schmid, TU Graz, WP 5
We developed a Multi-Party Computation (MPC) project using FRESCO. First, we had a privacy-preserving auction in mind. In such a scenario, everyone could bid in private, and only the highest bidder and bid would become known to the auctioneer. Then after several discussions with our partnering company, we came to a similar yet different use case. In our project, we want to enable small companies to buy from a much larger enterprise. With MPC, small companies would be able to keep their requested amount secret from their competition. Even the vendor will only discover the required items and suggested prices when the protocol finishes with success.
Well, that sounds fine, but what does the protocol do? In the first version, every customer submits their requested amount and suggests a price. Then everyone participates to secretly compare the required amounts with the available stock of the vendor. In parallel, all participants determine the average offered cost per unit and weigh it to the minimum price of the vendor. If the offers meet the prerequisites of a deal, everyone reveals their distinct amount and the total cost of the order to the vendor. The clients only learn whether the transaction was possible or not, even if they try to attack the protocol. Below we can see a schematic of the described MPC use case. IFX represents the vendor, while companies A_1 to A_n represent the customers.
As a foundation for our project, we use FRamework for Efficient and Secure COmputation (FRESCO). This framework provides the necessary functionality to build new MPC protocols such as ours.
From the demonstrator projects, we could quickly derive how to make our protocol. From there, we needed to add the security guarantees which we claimed.
We did not only want to write our protocol but also provide a starting point for future work. Providing a starting point seemed necessary to us, since setting up security against malicious adversaries in FRESCO can be quite tedious.
Since FRESCO is available in the public maven repository, we also developed our extension using maven. The use of maven assures ease of integration.
The inner workings of our protocol and future endeavors.
As explained above, every client must submit an amount and a price. The vendor has to provide the respective counterparts. Starting from there, we added additional features. It is also possible to state a requested delivery date for a specific amount. Contrary to that, the seller can also set individual pricing for different times and goods. These changes were in accordance with our partner and a demonstration of scalability.
We now have a small application showing the performance and usability of MPC. But there is still one significant difference to real-world applications, the backbone of secure communication is, of course, a private channel. We currently develop a TLS channel using the Java JCE framework. When adding this channel to our library, new projects can not only benefit from active security by FRESCO but also rely on a private and secure communication channel.
Providing the input
Our framework includes functionality for reading JSON data. This format provides for simple integration of input from databases or web services. Also, for our case, the vendor can easily update the available resources. In the following image, we can see such a sample input of the vendor.
Developing a new protocol
Until now, we talked rather generally about FRESCO, our use case, and our framework. But how exactly can it be used to develop further MPC projects? There are mainly two steps necessary to understand and create such protocols.
First, one must get some basic understandings of the core FRESCO functions and classes. These functions include foremost, the build computation method. There, the developer writes the code in several lambda expressions, which FRESCO then executes sequentially.
Secondly, one has to read into the Builder classes of our framework. This class sets up FRESCO in such a way that it is secure, plus it supplies general helpers such as JSON parsing. One can then extend the Builder such that it provides the input to FRESCO.
Following, one can see how such a buildComputation might look like.
Finally, we have to direct open questions to the project handout, which comes with the documentation of the code. Both will be in the final release of the project. There we discuss the technicalities more thoroughly.
