Remote attestation verification

How exactly the report has to be verified, depends on the application and if it has to be verified locally. Whenever TLS is used and the server is an enclave, then always the hash of the servers certificate in the TLS session should be included in the optional user data field of the remote attestation report and sent to the client first. The client then has to verify the qoute by verifying the certificate chain, the enclaves attributes and the measurements. Additionally, the TLS certificate of the current TLS session with the enclave has to be extracted, hashed and checked if the hash matches the certificate referenced in the attestation report. Then, the client can be sure to talk to the right enclave. The assumption relies on, that only the enclave should know the private key associated with the certificate.

Local report verification

In case the verification happens locally on a clients system, then using a desktop application connecting to the SCSC and the used frontend is trusted, then the report can already be verified here. The best option here is to use a desktop application created by the customer itself, or an open-source one and verify the code beforehand. This way you can be sure that the code is trustworthy. When the SCSC is actually the frontend, it get's more complicated. The frontend should not verify itself, when it is untrusted, otherwise a ring relationship is created and the frontend could easily skip the verification step unnoticeable for the user. To still guarantee security, the frontend must offer a possibility to download it's attestation report, which the user must then verify itself. This also applies for a untrusted frontend connecting to a SECS. By hardcoding the remote attestation verification of the SECS into the frontend, the frontend can be used as a trust anchor, only the frontend's report has to be verified by the client. Should the frontend be not able to verify the attestation report, because it does not work in the used programming language or there are not enough libraries available, it can't be used as a trust anchor and the client has to verify both reports. To do this, the client needs the respective certificates and remote attestation reports, which have the hash of the certificate as optional user data. See the next chapter for a solution, where an untrustworthy frontend is used to connect to a SCSC.

Attestation Verification Service

From the previous subsection, it is clear that verifying an attestation report can often be very difficult and depends on the application for local report verification. An attestation verification service (AVS) may be used to be independent of the application for attestation verification. As the name suggests, it is a service used for attestation report verification and is mainly used when the network communication from the client to the enclave is secured by TLS. Expected measurements from multiple SCSCs can be hard-coded into the attestation verification service or must be additionally provided by the requester or a trusted entity. In order to verify the attestation reports in RA-TLS, the attestation verification must be outsourced to the AVS in the protocol flow. This means that until the AVS has verified the attestation, no further protocol flow can take place.

For TLS, the client can provide the AVS with the attestation report and the certificate (or certificate's hash) used by the enclave for the TLS connection. Verification of an attestation report is valid only as long as the referenced certificate is used in the current TLS connection. If the certificate changes, a new attestation report is required. The application should always provide it's attestation report first for new TLS connections. Then the AVS can verify the report. After validation, the client can be confident that it is talking to an expected enclave, assuming the AVS is not malicious.

When a browser connects to an enclave, it must first establish a TLS connection to the enclave. Most browsers provide an option to download the certificate of a TLS connection. It is important not to send any sensitive data yet. Since the frontend code is untrusted, it must be done manually to actually send the remote attestation report within a browser to the AVS. One option would be to provide a download button to download the attestation report. Another option would be to just provide the certificate and let the AVS retrieve the remote attestation report from the enclave itself via an endpoint.

This attestation verification service should be hosted by a different cloud provider (cloud provider B) and outside of the Kubernetes cluster, for greater security. Although the cloud provider hosting the SCSC cannot validate invalid attestation reports without the involvement of cloud provider B, cloud provider B can. However, an external attacker must now control the AVS and be able to route traffic for a benign SCSC to a malicious one. Then he could run any code he wants behind the route of an SCSC. If he only has control of the AVS, the most he can do is trigger a DoS attack by having clients refuse to connect to an actually benign SCSC. There should be no validation of false positives, since the attacker cannot deploy a malicious container inside the cluster in this attack model. By only being able to deploy a malicious SCSC and route traffic to it, this will be detected when the attestation report is checked.

In addition, it is difficult to avoid trusting cloud provider B. If the AVS is put in an enclave, the attestation report of the AVS has to be verified locally to be sure that the verification of the reports is correct. Naively, one might think that other users will verify the AVS, so I do not have to. Suppose cloud provider B is malicious, then he is able to select a small number of users or a specific user and redirect their traffic not to the AVS, but to a malicious one. This makes the whole thing more difficult to detect because the cloud provider is able to generate and use certificates for the domain. So now an attacked user has to do the validation for it to be noticed and provide the proof.

The only advantage an AVS might have is that it makes it easier to verify multiple reports. Only one report needs to be verified locally, and that is the one from the AVS. The best solution would be for the cloud customer to host the attestation verification service themselves, as they are trusted in this model.