-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Azure attestation token repeat flaw? #230
Comments
Hi, |
Thank you for the quick response. I see, so even though a malicious server could pass the attestation 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? |
Yes, it's easy to modify the sample to include a nonce. On the server side, you would move the call to On the client side, you would split the data from the token into nonce and certificate and check the nonce. |
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 This same issue would still happen if the client used a nonce, if the impersonator could just manipulate the |
VerifyAzureAttestationToken will fail if the token is manipulated in any way. |
I have just spun up a server using the
azure_attestation
sample as primary inspiration. Inside ofserver.go
we have the following code: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?
The text was updated successfully, but these errors were encountered: