Code-to-Data and Confidential Compute capabilities in EDC

[ma3u]

The functional requirement specification of the IDSA describes mandatory foundation and optional components for other data collaboration scenarios:

"Data sharing must accommodate a wide range of scenarios. From a simple file transfer between two storage providers, to API access for streaming or eventing, to quite complex implementations with secure execution environments through confidential compute enclaves, environment attestations, signed code, custom encryption algorithms, and more. Which solution is right depends on the protection needs of the data and the trust level between the participants."

Optional function for Processing Services

A data space can have participants that do not offer their data and are not the end users of data. At its most basic level, these can be participants that are offering algorithms and code for processing data as a data contract to deliver code libraries, signed containers, or entire virtual machines to other participants. For very computation intensive or special hardware requiring workloads these participants might offer their own infrastructure as part of the contract and use policies to control the use of their resources.

Many data spaces can be built on top of the peer-to-peer model, such as a data supply chain where data assets pass through multiple processors before reaching the end user. The implementation and capability of these services again depends on the architecture, policies, and rules of the data space.

Many projects like SafeFBDC, AgriGaia, Gaia-X4KI, Catena-X want to provide secure execution environments, so the data never leave the trusted premise environment of the data provider. There are various options:

1. Code-To-Data (C2D) between trusted partners

If partners trust each other the application can be transferred from the app provider to the app consumer. The app consumer hold the data. The data won't leave the data provider.

⚠️ We need a specification how to define the hardware and software requirements for the compute environment of the app. Based on the Dataspace Specification we will use the Catalog Binding. The W3C DCAT specification provides Class Catalog Vocabulary. Here a suggested W3C:DCAT DataSet element as JSON-LD serialization represents the hardware requirements for running a container or algorithm:

{
  "@context": {
    "dcat": "http://www.w3.org/ns/dcat#",
    "dct": "http://purl.org/dc/terms/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "ex": "http://example.org/"
  },
  "@id": "ex:HardwareRequirements",
  "@type": "dcat:Dataset",
  "dct:title": "Hardware Requirements for Running a Container",
  "dct:description": "This dataset defines the hardware requirements for running a container.",
  "dct:issued": {
    "@type": "xsd:date",
    "@value": "2022-01-01"
  },
  "dct:modified": {
    "@type": "xsd:date",
    "@value": "2022-01-01"
  },
  "dct:publisher": {
    "@id": "ex:HardwareRequirementsPublisher"
  },
  "dct:language": {
    "@id": "http://id.loc.gov/vocabulary/iso639-1/en"
  },
  "dcat:keyword": ["hardware requirements", "container", "CPU", "GPU", "RAM", "ConfidentialCompute", "CodeAttestation"],
  "dcat:distribution": [
    {
      "@id": "ex:CPU",
      "@type": "dcat:Resource",
      "dct:title": "CPU",
      "dct:description": "Minimum CPU requirements for running a container."
    },
    {
      "@id": "ex:GPU",
      "@type": "dcat:Resource",
      "dct:title": "GPU",
      "dct:description": "Minimum GPU requirements for running a container."
    },
    {
      "@id": "ex:RAM",
      "@type": "dcat:Resource",
      "dct:title": "RAM",
      "dct:description": "Minimum RAM requirements for running a container."
    },
    {
      "@id": "ex:ConfidentialCompute",
      "@type": "dcat:Resource",
      "dct:title": "Confidential Compute",
      "dct:description": "Confidential computing requirements for running a container."
    },
    {
      "@id": "ex:CodeAttestation",
      "@type": "dcat:Resource",
      "dct:title": "Code Attestation",
      "dct:description": "Code attestation requirements for running a container."
    }
  ]
}

2. Confidential Compute between untrusted partners

If the partners do not trust each other, a 3rd party can ensure the calculation through confidential computation. Confidential computing is a security and privacy-enhancing computational technique focused on protecting data in use. The technology protects data in use by performing computations in a hardware-based trusted execution environment (TEE).[3] Confidential data is released to the TEE only once it is assessed to be trustworthy. Different types of confidential computing define the level of data isolation used, whether virtual machine, application, or function, and the technology can be deployed in on-premise data centers, edge locations, or the public cloud.

A similar approach is the concept of data clean rooms. The concept of a data clean room is intended to be a data-focused equivalent to a physical clean room, with the goal of having a pristine environment where technology can't be contaminated by outside influence. Instead of being concerned with contamination by physical elements, the primary concern of a data clean room is keeping user data isolated and private.

This is just one of many possible scenarios how you can create a Trusted Execution Environment with Confidential Compute and the EDC:

See also related discussion thread edc provisioning

[gbrost]

Thank you for sharing this! Some comments/questions from my side:

1. In diagram 2, should arrow 6 point from DataProvider to AlgorithmProvider?
2. In step 5, is the some kind of code evaluation to assess trustworthiness of the app?
3. To make full use of a TEE, the data consumer will want to do a remote attestation before accessing the data app. This can either be performed by the consumer itself or by a Trusted Third Party (TTP). In this case, however, the overall process needs to be connected via something like a nonce to make sure the Consumer is talking to a properly attested DataProvider.
4. In this example, the DataProvider provides its data via an App running inside a TEE. An even more interesting example would be "Data Service Provider" running a trusted app and processing/aggregating data from one or multiple Data Providers as a kind of data trustee. This would really bring out the benefits of a TEE since all parties can make sure the App is run in a secure environment and we can guarantee which App we are communicating with.

Does this make sense?

[ma3u]

Thank you for your time to discuss the confidential compute today. I modified the sequence diagram for 2. confidential compute.

[ralfNeu]

Thanks @ma3u! Here are some comments/questions in addition to @gbrost.

• In diagram 2 role of the Customer is not clear for me. Is the Customer providing the retrived Image to the DataProvider?
• How will the result from Algorithm + Data be delivered to the customer? Should it be presented as Data Asset and registerd in the Catalog itself?
• Maybe the introduction of a TEE Provider might make sense from start, even if it cloud be performed by the Data Provider or Consumer. Just to separate roles clearly? From my experience with discussing this scenario, the fear to give the algorithm away is equal to the fear to give the data away.

[ma3u]

Thank you Ralf. Thank you for your feedback.

• The consumer consume the app and data.
• we decided to keep it abstract. the algorithm or app can be stored in a cloud storage or in a container repository. Thats an implementation detail
• We decided the consumer provide the Trusted Execution Environment (TEE) to keep it simple. Together with Fraunhofer AiSec there are various way to build trust with code attestation.

[gbrost]

We discussed and reworked the diagram, so I am fine with that. This potentially relates to the trust discussion:
https://github.com/eclipse-edc/Connector/discussions/2868

[ma3u]

Thank you Gerd for the input of the Fraunhofer AISEC.

[kainiklas]

Thans @ma3u for writing this down. Here are my comments:

• The "simple" scenario is clear.
• Code Attestation: This is probably something which you don't want to do every time before running the algorithm. I would suggest, that the algorithm provider hands in the code for attestation at the clearing house. The clearing house attests the code in a specific version, hash value, etc. creates a signature or similar which is attached to the algorithm in the fed.cat. Then, every user of the algorithm can check if the signature of the attestation is valid.
• The orchestration/ choreography is not clear to me: How can we assure, that data is only loaded into a secured environment with the agreed algorithm? Perhaps this is also a job for a clearing house, to check if the TEE setup is done correctly, so that the flow to load and process the data can be proceeded.

[ma3u]

We updated the Confidential Compute scenario with Fraunhofer AISEC. We decided to keep the implementation details abstract. We added the job of the clearing house in the sequence diagram.

[PeterKoen-MSFT]

the issue I see here is that there is not going to be the one implementation of TEE to satisfy all the needs. There will be a multitude of different TEE implementations, depending on the needs of the specific dataspace/participant needs.
Also it opens the discussion on data escrow scenarios where one participant collects data in a TEE from multiple providers, and algorithm(s) from other participant(s), execute the computation, manage the distribution of data exhausts according to policy and delete/clean up according to policies.
There is going to be a huge ecosystem for providing code/solutions for these implementations patterns with a lot of variations on the possible architectural patterns/attestation patterns.
Therefore I am convinced that it doesn't make sense to pro-actively define one implementation, but rather ask the community for use cases, expected business value and then suggest architecture attuned to the use cases. (my guess is that many will become economically unfeasible once you analyse the cost)

[ma3u]

Thank you Peter for your feedback. You are totally right. There are various ways to implement trusted execution environments. We want to show an exemplary path to implement such scenario in EDC.

[gbrost]

I totally agree not to define one implementation. However, I believe it makes sense to pro-actively think about trust anchors in advance and to design these concepts from the ground up. Basically, at the moment we see three technology stacks that do have a reasonable market share:

• AMD with SEV
• Intel with SGX
• ARM with TrustZone (only to some extent, maybe not that relevant, implementations vary more widely)

While there are some variations of the implementations, some aspects are consistent over:

• You can deploy a specific artefact (a VM in case of SEV-SNP or SGX-TDX, an enclave in case of SGX).
• You can use an attestation service to verify the integrity of the deployed artefact at startup and that the artefact runs inside of a TEE.

I think with these assumptions it is possible to model some interesting scenarios and map them to real-world requirements. I totally agree we should connect to the community to evaluate these use cases early on!

[mleberec]

Very good discussion which I was just made aware of.

As co-lead of the Gaia-X Infrastructure Service Characteristics I would like to point out that we (includes Intel and AMD plus a few other Gaia-X members so far) have been working on a self-description ontology for Compute Infrastructure services that looks a lot like @ma3u's JSON example and @gbrost's suggestions above. We would be very happy to have input from this group and shake down the model with the requirements from EDC. Let me know what the best process to include input from this group would be.

[ma3u]

I stored the UML definition files in my private GitHub repo temporality:

• compute2data.sequence.simple
• confidentialcompute.sequence.complex

[reisman234]

Thank you for the short discussion about the Simple Scenario. After a second look, I'm not sure if Compute2Data is the right name for that approach. IMO it should Code2Data (or App, how the moving part is called), for me Compute sound like moving real hardware around :D

[ma3u]

You are totally right. We discussed to transfer the App, Code, image from the App Provider to the AppConsumer / Data Consumer. I corrected this.

[fortanixinc]

What is unique about confidential compute in the context of data spaces is that the notion of trust has to span multiple participants, not just one environment at a time. In many cases in Code-to-Data scenarios, besides asking questions like "where is the data running?" another very relevant question would be "what code is running, in what environment, and under which guarantees?"

Here is where remote attestation and policy-based access would be useful constructs. Instead of having to rely on contractual trust between the participants involved, the data provider could check whether the workload running confidentially matches what is expected.

As data spaces evolve, there will be an increasing demand for the ability to protect both parties from each other. Data providers need guarantees that data is secure, and algorithm providers have assurances that code and intellectual property are safe during execution.

Having a solution capable of supporting different TEE technologies, attestation protocols, and deployment environments may prove very useful in this regard. What matters here is interoperability of trust mechanisms, not standardized confidential computing implementation.