How to test verdictd

[graziadonghia]

Hello, I'm currently studying how Remote Attestation works in Inclavare Containers. I read that some technologies have been deprecated in favor of others (such as rats-tls instead of enclave-tls). I'm quite confused about the compatibility between components though, so I have a couple of questions:

1) From what I've understood, Verdictd is the newest developed technology, then how is it possible to build a remote attestation framework based on Verdictd? I mean, how can we eventually substitute this infrastructure with one based on rats-tls and Verdictd? I'm not sure I completely understood this schema.

2) Is it possible to test Verdictd with demo code? If yes, where is it in the repository?

Thanks in advance.

[jiazhang0]

@graziadonghia

1. Verdictd is following the IETF RATS architecture, and the infrastructure is only a best practice for hierarchical SGX attestation architecture. Of course, the hierarchical SGX attestation architecture is still useful, and it will be used in another project called enclave-cc. As you see, the agent-enclave is authenticated by remote attestation and the app-enclave is authenticated by agent-enclave with local attestation. But we don't continue to support this infrastructure.
2. Currently, verdictd is used to support remote attestation for CoCo project. Or simply follow the steps mentioned by here and there.

[graziadonghia]

Ok, thank you @jiazhang0. What if I try to test Verdictd and Rats-TLS inside a Kubernetes cluster? Should I run client and server in different pods, maybe with Occlum? I'm asking because I'm currently studying remote attestation processes in cloud environments involving Intel SGX technology.

[jiazhang0]

Ok, thank you @jiazhang0. What if I try to test Verdictd and Rats-TLS inside a Kubernetes cluster? Should I run client and server in different pods, maybe with Occlum? I'm asking because I'm currently studying remote attestation processes in cloud environments involving Intel SGX technology.

Verdictd is a specific implementation for the role of "Verifier" defined in RATS architecture mentioned above. In practice, relying party is the actual entity performing the Verifier. You can refer to this to see where relying party is deployed. In other word, Verdictd should be deployed in your local/trusted environment where kubectl runs, your secrets/keys are maintained, and your container is created.

In confidential containers scenario, there are 2 phrases: pre-container and post-container. In pre-container phrase, the TEE Pod is created and a remote attestation procedure occurs to allow relying party to authenticate the identity of TEE Pod and then authorize it to grant the access to sensitive secret such as container image decryption key. In this case, the TEE Pod acts as the role of "Attester" in RATS architecture and client in conventional network model. The relying party or Verdictd acts as the role of "Verifier" in RATS architecture and server in conventional network model. In post-container phrase, the workload service from your container image acts as server in conventional network model. If the attested and trusted communication channel is required between the application client and workload service, both the application client and workload service need to adapt to RATS-TLS. In this case, the application client and Verdictd act as the role of "Verifier", and the workload service acs as the role of "Attester". Usually your workload service is protected by TEE, so you can run your workload service with RATS-TLS in Occlum. RATS-TLS already supports it. For test purpose, you can simply run sample rats-tls-client application in Occlum.

Of course, if just simply test Verdictd and RATS-TLS based application, you can deploy Verdictd in host and RATS-TLS based application (such as rats-tls sample client) in TEE/Container/Pod.

[graziadonghia]

Ok, now I think I have understood. My idea is to build a basic container attestation framework based on this architecture. However I have other additional questions:

1) Let's say I have a Kubernetes worker node which contains some containers that run code in Occlum and the Attestation Agent running inside an Enclave. Having said that, the Attestation Agent wants to perform Attestation of a certain container: how is the Quote computed? Does it follow the SGX DCAP specifications? How is the Quote retrieved by the Attestation Agent?

2) Is the Quote signed using the DCAP certificate? I mean, the one created by following this guide

3) How is the Verdict job implemented? Is there a kind of DB that stores the container-related golden values?

4) How does the KMS work in Verdictd? How are keys provisioned?

[jiazhang0]

Ok, now I think I have understood. My idea is to build a basic container attestation framework based on this architecture. However I have other additional questions:

1. Let's say I have a Kubernetes worker node which contains some containers that run code in Occlum and the Attestation Agent running inside an Enclave. Having said that, the Attestation Agent wants to perform Attestation of a certain container: how is the Quote computed? Does it follow the SGX DCAP specifications? How is the Quote retrieved by the Attestation Agent?

2. Is the Quote signed using the DCAP certificate? I mean, the one created by following [this guide](https://www.intel.com/content/www/us/en/developer/articles/guide/intel-software-guard-extensions-data-center-attestation-primitives-quick-install-guide.html)

3. How is the Verdict job implemented? Is there a kind of DB that stores the container-related golden values?

4. How does the KMS work in Verdictd? How are keys provisioned?

By the way, Occlum with attestation-agent is supported by Enclave-CC project. It will be available in 0.3.0 release in CoCo release. So I assume your Kubernetes worker node is deployed with Enclave-CC solution.

1. The agent-enclave defined in Enclave-CC architecture will use SGX local attestation procedure rather than SGX DCAP remote attestation procedure to attest the app container. So the attestation-agent is not used to attest any container application or workloads. Usually, a remote attestation occurs when the "Attester" and "Verifier" are not located at the same node. In your scenario, both the attestation-agent and the attested app container reside on the same node. Of course, agent-enclave is launched by Occlum in the so-called agent container, so Verdictd requires to attest it with SGX DCAP remote attestation, and attestation-agent will generate the SGX DCAP quote with Occlum Attestation APIs where the underlying implementation still follows the SGX DCAP spec.

2. As mentioned above, the local attestation only needs SGX local report instead of SGX DCAP quote.

3. Verdict is deployed on the remote peer as the "Verifier". It is still a PoC so it doesn't use DB to store the golden values or so-called known reference values. Just use a configuration file to record the known reference values. In the production, a DB should be used to store the reference values.

4. Similarly, Verdictd doesn't use KMS to store the key. Instead, Verdictd simply provisions the content of key file to attestation-agent over the trusted channel established with RATS-TLS. In the production, a KMS should be used to store the keys and secrets.

[graziadonghia]

I don't know if I properly understood the first point, let me get this straight. If I have a Kubernetes cluster with both the container to attest and the attestation agent within the same node is it Local Attestation even if the Verifier is outside that node? Therefore, in order to have a Remote Attestation infrastructure I should have at least three separate nodes: attest agent, verifier and container to attest. Is it correct? I mean, the Local Attestation process involves the container and the Attestation Agent (hence the SGX REPORT data structure is considered), but if the Attestation Agent "converts" the REPORT in QUOTE and sends it to the Verifier through a secure rats-TLS channel then we have Remote Attestation, right?

Another thing, does it work anyway if I deploy my Kubernetes cluster with Inclavare Containers as it is explained here?

[jiazhang0]

I don't know if I properly understood the first point, let me get this straight. If I have a Kubernetes cluster with both the container to attest and the attestation agent within the same node is it Local Attestation even if the Verifier is outside that node? Therefore, in order to have a Remote Attestation infrastructure I should have at least three separate nodes: attest agent, verifier and container to attest. Is it correct? I mean, the Local Attestation process involves the container and the Attestation Agent (hence the SGX REPORT data structure is considered), but if the Attestation Agent "converts" the REPORT in QUOTE and sends it to the Verifier through a secure rats-TLS channel then we have Remote Attestation, right?

Another thing, does it work anyway if I deploy my Kubernetes cluster with Inclavare Containers as it is explained here?

The expected approach would be: verifier (verdictd) @ Remote node <- Remote Attestation -> agent-enclave @ K8s node <- Local Attestation -> app containers @ K8s node

And IC is used to support the deployment as mentioned by the link. However, we are shifting to Enclave-CC arch.

[graziadonghia]

Ok, thank you so much! I'm trying to setup the environment you suggested me, but unfortunately I cannot install Verdict. Even though I build it from the directory with cargo build --release the bin/ directory and therefore the executable file are not generated

[jiazhang0]

Ok, thank you so much! I'm trying to setup the environment you suggested me, but unfortunately I cannot install Verdict. Even though I build it from the directory with cargo build --release the bin/ directory and therefore the executable file are not generated

What is the build failure exactly?

[graziadonghia]

It simply doesn't create the binary which I should move to /usr/local/bin, but maybe I did some silly mistakes. However I have another question about the Remote Attestation infrastructure with a Kubernetes cluster explained here. Is it a problem if SGX DCAP is supported only on the node where I run the application I want to test? In order to build the cluster I have access to multiple machine but unfortunately just one among them supports SGX DCAP. My concern is mostly about the node where Verdictd is supposed to run, because I don't know if it can work when running on a machine that has SGX but doesn't have DCAP.

My idea is to build a cluster with 3 nodes (control plane with API server, verifier with verdictd, worker node with running enclaves), is it feasible if only the worker node has DCAP?

[jiazhang0]

@graziadonghia Verdictd as the Verifier role can be run in a non-TEE environment. This is the most of the situations we meet.

And yes, you can just enable DCAP in the worker node because only the worker node will run a SGX enclave instance as the attester role to launch a remote attestation procedure and request Verdictd to authenticate.