Hacker News Reader

Comment by can16358p | Hacker News Reader

Okay I don't have much information about this whole attestation flow and one question boggles my mind. If someone can explain this in simple terms, I'd be thankful:

The post says build the repo and get the fingerprint, which is fine. Then it says compare it to the fingerprint that vp.net reports.

My question is: how do I verify the server is reporting the fingerprint of the actual running code, and not just returning the (publicly available) fingerprint that we get result of building the code in the first place?

View on HN

"Ask a VP.NET server for the fingerprint it reports" is a little bit simplistic. The process for actually doing this involves you handing the server a random number, and it sending you back a signed statement including both the fingerprint and the random number you gave it. This prevents it simply reporting a fixed fingerprint statement every time someone asks. The second aspect of this is that the key used to sign the statement has a certificate chain that ties back to Intel, and which can be proven to be associated with an SGX enclave. Assuming you trust Intel, the only way for something to use this key to sign such a statement is for it to be a true representation of what that CPU is running inside SGX at the time.

How do I know I'm connecting to the WireGuard instance being attested and not something else? Could the host run one attestable instance, but then have users connect to a separate, malicious one?

The attestation covers the public key, so you would only connect to an instance which has that public key.

In order for a malicious instance to use the same public key as an attested one, they’d have to share the private key (for decryption to work). If you can verify that the SGX code never leaks the private key that was generated inside the enclave, then you can be reasonably sure that the private key can’t be shared to other servers or WG instances.

> how do I verify the server is reporting the fingerprint of the actual running code

Since this was answered already, I'll just say that I think the bigger problem is that we can't know if the machine that replied with the fingerprint from this code is even related to the one currently serving your requests.

Reply on news.ycombinator.com