Azure attestation token repeat flaw?

[JackEshkenazi]

I have just spun up a server using the azure_attestation sample as primary inspiration. Inside of server.go we have the following code:

// Create HTTPS server.
http.HandleFunc("/token", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte(token)) })
http.HandleFunc("/secret", func(w http.ResponseWriter, r *http.Request) {
   fmt.Printf("📫 %v sent secret %v\n", r.RemoteAddr, r.URL.Query()["s"])
})

The idea is that /token is a public endpoint from which anybody can get the Azure Attestation token of the server. Clients attest this token before sending a secret over a secure channel.

The problem with this is that anybody can GET this token and then echo back a copy of it on their own "/token" endpoint, and clients will attest them as being a trusted enclave. This seems to be a serious problem since it renders the example pointless to anybody that isn't the person that created the server (in which case you wouldn't even attest a trusted execution environment since you can trust yourself). The remote_attestation sample code seems to have the same problem.

There must be something I am missing. Is there a way to use a nonce provided by the attesting client to ensure the generation of a new token? How can we ensure that the server we are reaching didn't just steal their token from somebody else?

[thomasten]

Hi,
The token (as well as the report in the other sample) is not a secret. It contains only the certificate (i.e., public key) of the enclave. Without the private key, another party can't impersonate the enclave: the client uses the certificate to verify the TLS connection when calling the /secret endpoint.

[JackEshkenazi]

Thank you for the quick response.

I see, so even though a malicious server could pass the attestation attestation.VerifyAzureAttestationToken, and fully pass the report validation verifyReportValues, they will not be able to receive the TLS connection.

Is there no way to issue a challenge? In the openenclave library there is a way to issue a challenge to the enclave as part of the attestation. Is there any way do that with ego, where perhaps the client includes a nonce in the token request and then verifies that it was used during the generation of the token?

[thomasten]

Yes, it's easy to modify the sample to include a nonce.

On the server side, you would move the call to enclave.CreateAzureAttestationToken into the HTTP request handler and pass the received nonce concatenated with the certificate as the data argument.

On the client side, you would split the data from the token into nonce and certificate and check the nonce.

[JackEshkenazi]

Hi @thomasten, I have a followup question about this same topic.

What is stopping a malicious server that is trying to impersonate the enclave from repeating the same token grabbed from the public /token endpoint, and manipulating the report.Data so that it is a certificate based on a new private key? Wouldn't the client then be tricked into having a verified connection with the false enclave and thus think that it was the true enclave?

This same issue would still happen if the client used a nonce, if the impersonator could just manipulate the report.Data all the same (split the data to retrieve nonce and replace the certificate).

[thomasten]

VerifyAzureAttestationToken will fail if the token is manipulated in any way.