Ambiguities in attested TLS specification

[muhammad-usama-sardar]

Checking the documentation for attested TLS, I have the following questions:

1. It is never mentioned whether the solution is pre-/intra-/post-handshake attestation.
2. Why do you send nonce as SNI? This is mentioned in figures but never explained.
3. Is certificate self-signed? If yes, skip questions 4 onwards. The documentation says:

The relying party uses the Cocos CLI to verify the self-signed (or CA-signed) certificate and the attestation report that is part of it.

But the two cases are quite different. Why do you "verify" a self-signed certificate?

4. What is the "long-term identity" of the CC workload? How is "long-term identity" assigned to the CC workload? Which entity supplies this "long-term identity"? How is that Identity Supplier trusted?
5. How is CA-certified Long-Term Key (LTK) injected in the Confidential Computing workload in the first place? Which entity generates the LTK and how is that entity trusted?
6. How does the Verifying RP (RP+Verifier) get the public keys and reference values?

[danko-miladinovic]

Hi @muhammad-usama-sardar as you have noticed, our solution uses the same approach as Edgless. Below are the answers to your questions:

1. This is the intra-handshake attestation solution. The attestation report is inserted as an X.509 extension into the certificate. The attestation report is fetched on every TLS connection.

2. SNI is used to send the random nonce for the attestation report's proof of freshness. The SNI is used to transfer the nonce because we do not run multiple servers in our CVM, just one, the Agent, that is responsible for the TLS connection.

3. The certificate is self-signed and generated inside the CVM on every TLS connection. Optionally, the certificate generated inside the CVM can be signed by a CA.

4. The CVM is booted with a token issued by Prism (the CA). The CVM presents this token when submitting a CSR to Prism, and the CA signs the CVM certificate based on the validity of this token.

5. The token is retrieved by the Manager (the CVM orchestrator). CVMs are booted with this token provided via environment variables. Users of the CVM can download the Prism CA certificates to verify the signed CVM certificate.

6. The verifier gets the certificates from Prism.

In both cases, the CVM certificate and its keys are generated within the CVM. Essentially, the TLS connection is established the same way as any normal TLS connection (without an attestation), but on the client side, the attestation is extracted from the TLS certificate and verified.

The answers to the follow-up questions are:

1. Why do you use SNI extension for nonce? Why don't you define an extension of ClientHello?
   Edgless does not use SNI, which is one of the small differences between our implementations. We use the SNI to transfer the nonce because we use the standard Go TLS library for the communication, and that library does not support custom TLS extensions. It does not support Client Hello extensions. A similar implementation is available in the Mithril implementation of aTLS.

2. How do these 3 steps (steps 4 to 6) happen without having the CSP in TCB? How does the RP get to trust the Prism? How does the CVM get the token?
   This is an optional step. In this case, you would need to have an implicit level of trust in Prism. The token is provided by the Manager to the CVM via QEMU.

3. What exactly binds the Evidence to the specific TLS connection?
   The CVM generates a Public key (PubK) and a private key (PrivK) for every TLS connection. The same keys are used to generate the self-signed X.509 certificate. The PubK and the SNI nonce are part of the Evidence. When the Evidence is fetched from within the CVM, it is inserted as an X.509 extension into the self-signed X.509 certificate. The CVM itself is an in-RAM CVM, meaning it does not have a disk and runs entirely in RAM. We went with this solution for the CVM so we can easily measure the entire CVM.

[danko-miladinovic]

The CVM receives a computation manifest from Prism. The computation manifest defines who can send data and an algorithm to the CVM, and who can retrieve the result. To be more precise, the computation manifest is the identification of a consortium. The manifest is also part of the Evidence; the vTPM is used to hold the manifest.

[muhammad-usama-sardar]

The CVM generates a Public key (PubK) and a private key (PrivK) for every TLS connection. The same keys are used to generate the self-signed X.509 certificate. The PubK and the SNI nonce are part of the Evidence. When the Evidence is fetched from within the CVM, it is inserted as an X.509 extension into the self-signed X.509 certificate. The CVM itself is an in-RAM CVM, meaning it does not have a disk and runs entirely in RAM. We went with this solution for the CVM so we can easily measure the entire CVM.

This actually does not bind the Evidence to a specific TLS connection, and a relay attack is not avoided here. I encourage you to check out our paper and the implementation.

[muhammad-usama-sardar]

Edgless does not use SNI, which is one of the small differences between our implementations.

At least until a few months ago, Edgeless folks were using SNI [source].

We use the SNI to transfer the nonce

Actually, if you don't have multiple servers, you shouldn't be using SNI extension. You are misusing the SNI extension for nonce.

[danko-miladinovic]

Hi @muhammad-usama-sardar one additional point worth mentioning is that the CVM only communicates with users whose public keys are explicitly listed in the computation manifest. Conversely, users possessing the corresponding private keys will only successfully establish a connection with a CVM that presents the expected computation manifest and measurement. Essentially, this is mTLS + aTLS, which mitigates the effects of the relay attacks in Cocos.

[muhammad-usama-sardar]

Hi @danko-miladinovic, mTLS does not help much in this case. For technical reasoning, please see section 5 of this paper, which I mentioned above already.

[muhammad-usama-sardar]

Also, see this paper to get some insights more formally. I would like to see a precise diagram of your protocol, similar to Figure 5 in the paper.