DEV Community

VoltageGPU
VoltageGPU

Posted on Originally published at voltagegpu.com

I asked whether my own API could get a customer both attestation proofs with nothing but a key. It could not. Here is what was missing.

#security #cloud #gpu #python

I sell Intel TDX virtual machines with a NVIDIA GPU passed through, and the whole pitch is "you generate the attestation yourself, on a challenge you chose, and you verify it without trusting me". Yesterday a customer asked a simple question: does that also work through the API, end to end, no dashboard? I said yes. Then I checked, following only my own public documentation, and the honest answer was: not quite. Two things were broken. Both are fixed now, and the run that found them is public, so here is the whole thing.

The test

Rules I set myself: an API key, the documentation page, nothing else. No internal tools, no peeking at the provider console.

  1. GET /api/confidential/vm/tiers returns the live inventory with price and, since this week, an attestation block per SKU: verified or not, on what date, the URL of the published evidence, and the exact commands to reproduce it inside the VM.
  2. POST /api/volt/ssh-keys registers the tenant's ed25519 public key. A confidential VM binds the key at creation and cannot be given one later.
  3. POST /api/confidential/vm/deploy with {"resource_name":"rtx6000b-small","hardstop_hours":1}. One hour (3.80 dollars) is charged upfront.
  4. GET /api/volt/pods polled every 15 seconds until the VM answers.
  5. SSH in, generate both proofs.
  6. Copy the bundle out, verify it on my laptop.
  7. POST /api/volt/pods/{id}/stop, unused part of the hour refunded per second.

Steps 1 to 3 went through in seconds. Step 4 is where it broke.

Broken thing number one: the SSH command the API gave was wrong

The pod listing returned a ready-made command, ssh wrk-xxx@ssh.voltagegpu.com. That gateway is for the container tier. A VM is reached directly, ssh -p <port> ubuntu@<ip>, and the listing simply did not contain the IP or the port. The dashboard knew them, because it reads a session-only route. An API user had no way to learn them at all. So the documentation said "ready to use SSH command" and the command answered Permission denied (publickey).

The fix is in production: the listing now returns provider_status, ssh_ready, ssh_host, ssh_port, ssh_user and a working ssh_command. One more detail I only learned by re-running the test: the address is assigned about 16 seconds after deploy, but sshd only answers once the provider reports running, around two minutes later. Between the two, ssh_ready is false and the command is null, so a script cannot connect too early.

Broken thing number two: the first reproduce command failed

The attestation block listed four commands, starting with pip install "voltage-verify[attest]". The VM image ships without pip. Anyone following the API to the letter would have failed on line one. The list now reflects what actually runs:

curl -sS https://bootstrap.pypa.io/get-pip.py | python3 - --user --break-system-packages
python3 -m pip install --user --break-system-packages "voltage-verify[attest]"
export PATH=$HOME/.local/bin:$PATH
voltage-verify manifest --challenge auto -o manifest.json
sudo env PATH=$PATH PYTHONPATH=$(python3 -c 'import site;print(site.getusersitepackages())') \
  voltage-verify attest --manifest manifest.json --mode single-gpu -o bundle.json
voltage-verify verify bundle.json --challenge <the challenge printed above>
Enter fullscreen mode Exit fullscreen mode

Inside the VM this took 19 seconds wall clock, including the pip bootstrap. The manifest step prints a random challenge; the TDX quote carries its SHA-512 in report_data, the NVIDIA tokens carry its SHA-256 as nonce, so both proofs are bound to the same value the tenant chose.

The part that matters: verifying outside the VM

A proof you can only check on the machine that produced it proves nothing about the machine. So the bundle came out over scp, and on a Windows laptop:

voltage-verify verify bundle.json --challenge ac7258...7389 --hwmodel GB20X --gpus 1
RESULT: VERIFIED

voltage-verify verify bundle.json --challenge 0000...0000
RESULT: NOT VERIFIED (manifest.challenge)

voltage-verify verify bundle.json --offline --challenge ac7258...7389
RESULT: VERIFIED
Enter fullscreen mode Exit fullscreen mode

The wrong challenge is the interesting line: a replayed bundle from another run, or another provider, is rejected. The offline run works because the Intel collateral (TCB info, QE identity, CRLs) is embedded in the bundle at attest time.

Then the stop call, and the refund: 3.20 of the 3.80 dollars came back. The whole run, deploy to verified bundle on my laptop to release, cost 0.60 dollars. Two more control runs after the fixes cost 0.14 dollars in total, one of them was stopped at 16 seconds and refunded in full because the machine had never actually started.

What is public

The bundle, the manifest, the checksums computed inside the VM, and the verification output from the laptop are at https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-api-2026-09-17/README.txt. Anyone can re-run verify on it. The public index of which SKUs have a published attestation, and which do not and why (8x H200, B200, B300 never available to test; the NVSwitch fabric not attestable from inside a TDX guest), is at https://voltagegpu.com/api/attestation/evidence, no account needed.

The verifier is MIT, on PyPI and GitHub: https://github.com/Jabsama/voltage-verify

What I take from it

"It works through the API" is a claim like any other. The only test that counts is the one that knows nothing but the documentation, and it found in ten minutes what a week of reading the code had not. If you sell attestation, run that test before a customer does.

Top comments (0)