You do have to trust the SEP/TPM here, it sounds like. That is verified by having a third party auditor watch them get installed, and by the anonymous proxy routing thingy making it so they can't fake only some of them but would have to fake all of them to be reliable.
If they were okay with it being unreliable, then clients could tell via timing because some of the nodes would perform differently, or they'd perform differently depending on which client or what prompt it was processing. It's surprisingly difficult to hide timing differences, eg all those Spectre cache-reading attacks on browsers.
It does look like there's room to add more verification (like the client asking the server to do more intensive proofs, or homomorphic encryption). Could always go ask for it.
That's detectable through timing measurements, for the same reason you can't have data-dependent operations in cryptography.
Ok, where are the timing measurements?
In the hardware secure boot chain ;)
You do have to trust the SEP/TPM here, it sounds like. That is verified by having a third party auditor watch them get installed, and by the anonymous proxy routing thingy making it so they can't fake only some of them but would have to fake all of them to be reliable.
If they were okay with it being unreliable, then clients could tell via timing because some of the nodes would perform differently, or they'd perform differently depending on which client or what prompt it was processing. It's surprisingly difficult to hide timing differences, eg all those Spectre cache-reading attacks on browsers.
It does look like there's room to add more verification (like the client asking the server to do more intensive proofs, or homomorphic encryption). Could always go ask for it.