natesales

Joined 4 years ago

Karma

Submissions

Member since

Apr 17

co-founder @ tinfoil. systems/security/applied physics.

View on Hacker News

Recent submissions

Comment · 1 year ago

All attestation verification happens client side. We have verifiers in Python [1] and Go [2] (which FFIs to our other SDKs like WASM and Swift). We push all the verification logic to the client so the verification process is entirely transparent and auditable.

[1] https://github.com/tinfoilsh/tinfoil-python [2] https://github.com/tinfoilsh/verifier

Comment · 1 year ago

An attacker would need to compromise our build pipeline to publish a backdoored VM image [1] and extract key material to forge an attestation from the hardware [2]. The build process publishes a hash of the code to Sigstore’s transparency log [3], which would make the attack auditable.

That said, a sufficiently resourced attacker wouldn’t need to inject a backdoor at all. If the attacker already possesses the keys (e.g. the attacker IS the hardware manufacturer, or they’ve coerced the manufacturer to hand the keys over), then they would just need to gain access to the host server (which we control) to get access to the hypervisor, then use their keys to read memory or launch a new enclave with a forged attestation. We're planning on writing a much more detailed blog post about "how to hack ourselves" in the future.

We actually plan to do an experiment at DEFCON, likely next year where we gives ssh access to a test machine running the enclave and have people try to exfiltrate data from inside the enclave while keeping the machine running.

[1] https://github.com/tinfoilsh/cvmimage

[2] https://arxiv.org/abs/2108.04575

[3] https://github.com/tinfoilsh/cvmimage/attestations

Comment · 1 year ago

We have to trust the hardware manufacturer (Intel/AMD/NVIDIA) designed their chips to execute the instructions we inspect, so we're assuming trust in vendor silicon either way.

The real benefit of confidential computing is to extend that trust to the source code too (the inference server, OS, firmware).

Maybe one day we’ll have truly open hardware ;)

Comment · 1 year ago

The keys are generated on the CPU and never leave the enclave, but the data is decrypted on the CPU so it hits the registers in plaintext.

When the enclave starts, the CPU does a few things:

1. The CPU does a key exchange with the GPU (in confidential compute mode [1]) to derive a key to encrypt data over PCIe

2. The CPU verifies the integrity of the GPU against NVIDIA's root of trust [2]

[1] https://developer.nvidia.com/blog/confidential-computing-on-...

[2] https://github.com/tinfoilsh/cvmimage/blob/b65ced8796e8a8687...

edit: formatting

Comment · 1 year ago

The verified trust boundary extends from the CPU to GPU [1], and TLS encrypts all data to/from the enclave and client so we can't see anything in the clear.

HTTP parsing and application logic happens on the CPU like normal. The GPU runs CUDA just like any other app, after it's integrity is verified by the CPU. Data on the PCIe bus is encrypted between the CPU and GPU too.