I understand your concern. I'm also learning this as we go.
Just to note:
routstrd: routstr daemon that you run locally. it's a client that communicates with Routstr nodes
Routstr nodes (they run routstr-core): providers who offer AI models for sats.
routstrd uses our sdk which in turn uses tinfoil's SDK (https://github.com/Routstr/routstr-sdk/blob/main/client/TinfoilSecure.ts) to encrypt the message body on the client side to Tinfoil's servers where decryption happens. They have TEE-terminated TLS so you can be sure that the decryption happens inside their TEE. (source: https://confidentialinference.net/providers/tinfoil).
So Routstr nodes, Private Provider (npub1fet…jzfa) in this case, cannot read any of your messages, you can verify this by running a node yourself. If there is a way to read your messages it has to be on the Tinfoil side, that is if their system is not well set up. Let's look at Tinfoil:
Here we are attesting that their TEEs run their released binary on Github. Yes, we are essentially trusting that new Github binaries don't contain any backdoors. These are the guarantees we have:
1. The enclave is real AMD SEV-SNP hardware. SEV-SNP report verified against AMD VCEK.
2. The code inside is the auditable open-source release. Sigstore bundle for tinfoilsh/confidential-model-router.
3. The measured code is what's actually running. Enclave measurement == signed release measurement
4. The request body can only be read by that enclave. EHBP encrypts to attested HPKE public key
5. A third party can't pretend to be Tinfoil. Certificate SANs bind HPKE key + attestation hash to *.tinfoil.sh
Auditing everything is very hard for us. Happy to hear any feedback here and improve our setup and/or support better TEE inference providers if any.
Tagging the TEE experts I know here: aljaz (npub1alj…g9jp) Gzuuus (npub1gzu…a5ds) semisol (npub1226…grkj)
