Integrating Secure Multiparty Computation into the EDC

[chart21]

Hi everyone,

we are working on integrating Secure Multiparty Computation (MPC) in the EDC. Secure Multiparty Computation lets multiple parties evaluate a function on joint data while maintaining complete confidentiality of each party's dataset. The technology can be used for use cases such as predictive maintenance where suppliers can benefit from the production data of a company that is reluctant to share that data and associated intellectual property with the supplier.

To integrate MPC into the EDC, the connector needs to support the following additional features highlighted in the figure below.

1. Integrate Secure Computation contracts. A secure computation contract should define which computation is performed on the distributed data of the companies. Here we only need to extend the existing contract offers with a few entries for agreeing on performing distributed computation rather than plain data exchange.
2. The Data plane is only used to let connectors exchange the endpoints of their servers running an open-source MPC library such as MP-SPDZ.
3. The parties involved in the computation need to present their access token obtained from contract negotiation to the servers running the computation. After authenticating all parties, the server can obtain secret shares from the parties, perform the computation, and only reveal the output.

Let us know if you are interested in such a solution or have any other comments.

[paullatzelsperger]

Hi @chart21. Reading this, I struggle to understand how this differs from a conventional data transfer, where the Asset represents an API, or rather: access to the API.

As stated in the diagram, the Asset just contains the MP-SDPZ URL/code. If some access token is required, that could be handled using EndpointDataReferences, the same way we do it for REST APIs.

The fact that an Asset is a "computation asset" is not relevant for EDC - the contract agreement would reference the "computation asset" anyway making that fact inherent, so no additional information is needed there.
The "terms" of the computation should be modelled using a policy.

The transfer process would simply stay open until the computation is finished, just like with "normal" API requests. The computation itself plus any ping-pong that needs to happen happens "out-of-band" (without EDCs involvement), basically your point 2).

If the question is, whether we would implement a tailored solution for that one use case, then the answer is almost certainly not.
There is, however, the possibility to reference your project in the friends list.

Out of sheer curiosity on my part, maybe you could provide a bit more info regarding the following aspects:

• Does the computation/algorithm itself represent intellectual property of some sort?
• How is the computation represented? is it a well-known algorithm? is it a signed docker image? a binary, or just a bunch of script files?
• Do both parties (i.e. provider and consumer) have to perform some part of the computation? If so, is it truly distributed? is it asynchronous?

[chart21]

Hi @paullatzelsperger. Thanks for the reply.

Indeed the overall process of the EDC does not change with our concept. However, we had to modify a few files, such as ContractOffer.java and ContractOfferFromIdsContractOfferOrRequestTransformer.java to add and parse the new fields in the contract offer. After accepting a contract, we also added the option to send over the code to the MP-SPDZ library. As these changes are not helpful for traditional data transfer contracts, I think your idea of adding our demo to the friends list is good.

Does the computation/algorithm itself represent intellectual property of some sort?

No, the idea is that each party involved in the computation reviews the code that gets executed on local data before accepting the contract. Upon acceptance, the code is transfered to the MP-SPDZ library that handles the computation.

How is the computation represented? is it a well-known algorithm? is it a signed docker image? a binary, or just a bunch of script files?

The computation is represented in a single Python file. This can be compiled by the MP-SPDZ library to enable a secure computation. Here is an example what code compatible with MP-SPDZ looks like.

Do both parties (i.e. provider and consumer) have to perform some part of the computation? If so, is it truly distributed? is it asynchronous?

Currently, our implementation assumes that the provider and the consumer each have the MPC library locally installed and wait for newly accepted contracts 24/7. Upon contract acceptance, they perform the computation synchronously, as MPC requires parties to communicate with each other when evaluating a function securely.
So yes, it is truly distributed, and no, it is not asynchronous. As asynchronous MPC protocols exist, this would be an option for the future, perhaps.

The implementation itself is use-case agnostic as you can propose arbitrary code that gets executed in this fashion. In case you are interested in the concept in general, we can also show you a quick demo.

[paullatzelsperger]

I would be curious to know what those changes are, could you post a Gist, or a link?

As these changes are not helpful for traditional data transfer contracts, I think your idea of adding our demo to the friends list is good.

For that, an issue must be opened using the "Adoption Request" template.

we can also show you a quick demo.

For that, the bi-weekly Q&A sessions would be a good platform. Dates can be found in the pinned discussion.

[chart21]

Here is an overview of the changes we did.

We will assume you have already installed MP-SPDZ on your machine. First, for the sake of adding the dataset description and MP-SPDZ code to your offer, you can simply modify the contractoffer.json file by adding a "datasetDescription" and "mp-spdzCode" field.

In the ContractOffer.java class we will also create the following fields:

private String datasetDescription;
private String mpspdzCode;

with their respective getters and builder methods:

@NotNull
public String getMpspdzCode() {
    return mpspdzCode;
}

@NotNull
public String getDatasetDescription() {
    return datasetDescription;
}

public Builder datasetDescription(String datasetDescription) {
    contractOffer.datasetDescription = datasetDescription;
    return this;
}

public Builder mpspdzCode(String mpspdzCode) {
    contractOffer.mpspdzCode = mpspdzCode;
    return this;
}

Now we should go ahead and find the ContractOfferFromIdsContractOfferOrRequestTransformer.java class. This is where we will parse our contractoffer.json file in order to get the recently added fields:

try {
    root = objectMapper.readTree(new File("CONNECTOR-PATH/samples/04.0-file-transfer/contractoffer.json"));
} catch (IOException e) {
    throw new RuntimeException(e);
}

JsonNode nameMP = root.path("mp-spdzCode");
JsonNode nameDD = root.path("datasetDescription");
String codeMP = nameMP.textValue();
String codeDD = nameDD.textValue();
Then we attach the parsed values to the contract offer: 
var contractOfferBuilder = ContractOffer.Builder.newInstance()
        .policy(policy)
        .consumer(contract.getConsumer())
        .provider(contract.getProvider())
        .datasetDescription(codeDD)
        .mpspdzCode(codeMP)
        .asset(asset);

The consumer is now able to view the new fields in the contract offer. Assuming the consumer is interested in running the function and wants to proceed with the contract agreement, our next objective is to send the provider’s IP address to the consumer. This could be done with a simple file transfer like the ones you can find in the hands-on tutorials.
We will transfer a .txt to the consumer. This file will contain the IP address of the provider.
Don’t forget to create this file and add its path to the FileTransferExtension.java class and a reference to it in the filetransfer class and contractoffer.json as explained in the EDC tutorials.
Furthermore, we also want to download the MP-SPDZ code into a new file in the consumer side so that our user can run this code. We do this by parsing the .json file again and writing it into a file. We will do this in the FileTransferDataSink.java class. The file created will be called demo.mpc and saved the location indicated below:

ObjectMapper objectMapper = new ObjectMapper();
JsonNode root = objectMapper.readTree(new File("CONNECTOR-PATH/samples/04.0-file-transfer/contractoffer.json"));
JsonNode nameMP = root.path("mp-spdzCode");
String codeMP = nameMP.textValue();

try (BufferedWriter bw = new BufferedWriter(new FileWriter("MPC-PATH/MP-SPDZ/Programs/Source/demo.mpc"))) {
    bw.write(codeMP);
} catch (IOException e) {
    e.printStackTrace();
}

Once we have the provider's IP address and the file with the MP-SPDZ code, we can let the MP-SPDZ library run the computation.

[paullatzelsperger]

Thanks for the detailed explanation, but the mpspdzCode should be a property on the Asset, or - if its a secret, put in the Vault and exchanged using the EndpointDataReference.

I would recommend reading up on the Dataspace Protocol, especially how assets are exposed as Datasets and Distributions.

In summary, the ContractAgreement and ContractOffer are not public extension points and I would advise against using it directly, as it may break in future releases, without prior notice.

TL;DR: what you want to do should be easily possible using EDC standard components, without any changes necessary to the code :)

[chart21]

Thanks, the difference would be that if we define the code as an asset it is accessible by the consumer only after the contract negotation, right? I guess that would work as well if the consumer does not start the computation in case the code looks differently than expected.