[viraptor]

The title here seems very different from the post. All that verification happens locally only. There's no remote validation at any point. So I'm not sure what's the reason to even apply this check. If you're running the model yourself, you know what you're downloading and can check the hash once for transfer problems. Then you can do different things for preventing storage bitrot. But you're not proving anything to your users this way.

You'd need to run a full, public system image with known attestation keys and return some kind of signed response with every request to do that. Which is not impossible, but the remote part seems to be completely missing from the description.

[FrasiertheLion]

The verification is not happening locally only. The client SDKs fetch the measurement of the weights (+ system software, inference engine) that are pinned to Sigstore, then grabs the same measurement (aka remote attestation of the full, public system image) from the running enclave, and checks that the two are exactly equal. Our previous blog explains this in more detail: https://tinfoil.sh/blog/2025-01-13-how-tinfoil-builds-trust

Sorry it wasn’t clear from the post!

[arboles]

What prevents the provider from sending to the client an attestation of hardware state and actually running another?

[viraptor]

The other comments are correct, but let me try for a different phrasing, because it's a complex topic. You have two parts for attestation: The hardware provides the keys and computation for the measurement state that you can't change as a user. The software provides the extra information/measurements to the hardware.

That means you can't simulate the hardware in a way that would allow you to cheat (the keys/method won't match). And you can't replace the software part (the measurements won't match).

It all depends on the third party and the hardware keys not leaking, but at long as you can review the software part, you can be sure the validation of the value sent with the response is enough.

[arboles]

I understand hardware attestation at this level, it's why you couldn't route a hardware attestation from a different machine, that's not the one the user cares about, that I'm working on understanding.

[viraptor]

Because to obtain the result of attestation, you'd need to actually run the prompt on the verified machine in the first place. (And in practice the signature would be bound to your response as well)

[arboles]

The attestation report is produced after the user sends a prompt to the LLM? I thought it was the proof the correct model weights are loaded on some machine.

[3s]

The attestation is tied to the Modelwrap root hash (the root hash is included in the attestation report) so you know that the machine that is serving the model has the right model weights

[FrasiertheLion]

When the enclave boots, two things happen:

1. An HPKE (https://www.rfc-editor.org/rfc/rfc9180.html ) key is generated. This is the key that encrypts communication to the model.

2. The enclave is provisioned a certificate

The certificate is embedded with the HPKE key accessible only inside the enclave. The code for all this is open source and part of the measurement that is being checked against by the client.

So if the provider attempts to send a different attestation or even route to a different enclave, this client side check would fail.

[arboles]

Is this certificate a TLS certificate? At least the TLS connection the user has should be with the "enclave", not a proxy server. If the connection is with a proxy server, the user can be MITM'd.

[FrasiertheLion]

Yes, it is a TLS certificate generated by the enclave on boot (the code responsible for doing this is open source and the attestation is also included in the certificate so you can check that this is exactly what’s happening). We go into more detail in our attestation verification docs here: https://docs.tinfoil.sh/verification/attestation-architectur...

[arboles]

Great. Thanks for the link also.

[julesdrean]

The provider cannot chose the attestation that is sent, the hardware assembles the attestation through mechanisms that it cannot control. That why it's called "trusted hardware" technology, you only need to trust the hardware (how it was implemented), and you don't need to trust the provider operating it.