Hardware-rooted remote attestation is a key ingredient for distributed confidential apps. MarbleRun relies on the Data Center Attestation Primitives (DCAP) of the latest SGX-enabled Intel Xeon processors. At the time of writing, only Microsoft Azure had a public DCAP service deployed in their data centers. Hence, our demos are mainly tested and deployed on Azure Kubernetes Service (AKS). However, MarbleRun works with any DCAP service complying with the SGX specification. You can read more about setting up your own DCAP infrastructure in the Intel SGX development articles.
Initially, the MarbleRun Coordinator is deployed to the cluster.
The Coordinator generates an X.509 certificate chain with a root and intermediate certificate authority (CA).
It generates a remote attestation quote which contains the hash of the root certificate (as
report_data) as well as a hardware measurement of its enclave (
MRENCLAVE of the report).
The admin receives the quote and verifies the Coordinator's integrity via the measurement. Next, they verify that the quote contains the root certificate’s hash. This ensures that the certificate was indeed generated by this Coordinator and wasn't manipulated during transport.
After the successful verification of the Coordinator, the manifest can be uploaded to the cluster. The manifest describes which Marbles (services) are allowed to join the confidential mesh. The manifest contains their enclaves’ build-time measurements.
Marble deployment and attestation
The Coordinator enforces the manifest and only admits the desired Marbles to the cluster. Each Marble registers itself with a quote via gRPC to the Coordinator. This quote is tied to the TLS session of the gRPC call. It contains the Marble's measurements. The Coordinator compares them to the manifest to ensure the Marble's identity and integrity. The Marble's TLS credentials are generated by the Coordinator and signed with the intermediate certificate. The Coordinator's certificate chain as well as the freshly generated Marble certificate are then delivered to the Marble.
Confidential service mesh
The Marble and the Coordinator can now communicate securely and authenticated over TLS (with client authentication), using the Coordinator's CA as the root of trust. In the same way, Marbles can communicate via mutual TLS with other Marbles, because the X.509 certificates of both Marbles were signed by the same intermediate certificate.
If a client wants to connect to a Marble, the Coordinator acts as a trusted CA to establish a TLS connection and verify the Marble's certificate.
When the Coordinator receives an update to the manifest, e.g. a Marble is updated to a newer security version, a new intermediate certificate is generated. The communication between Marbles relies on the intermediate certificate as root of trust. This ensures that Marbles which were deployed before the update can't communicate with Marbles that have the newer security version.
The Coordinator issues one concise remote-attestation statement for your whole distributed app. The Coordinator's build-time measurement is distributed to the relying party (this must be done by the admin or operator). The relying party requests the Coordinator's quote and certificate chain. The quote contains the hash of the Coordinator's root CA certificate, which is verified against the received certificate chain. The quote also contains the Coordinator's measurement, which is verified against the build-time measurement.
The relying party then requests the manifest from the Coordinator and ensures it contains the expected Marbles and their expected measurements. The steps required on the client-side are described in our verification hands-on.