Reproducing runtime and database attestation

Frontend-expected runtime pins ORAM UKI — 2026-07-24

These are the values the browser bundle expects for pir2. They are not a live-status feed. If the app shows a measurement mismatch, first confirm which VPSBG UKI or boot slice is actually running; only rotate these pins after intentionally deploying and verifying a new UKI.

Source of truth: web/src/attest-pin.ts::PIR2_TIER3_PIN.

What a mismatch means

A red runtime badge with MEASUREMENT pin mismatch means the server returned a valid SEV-SNP report, but the launch MEASUREMENT does not equal the frontend pin. That is different from noSevHost, and also different from DB proof failure.

Verify from pinned inputs

Download the published OVMF, obtain the operator-archived ORAM Tier 3 UKI if you have host access or rebuild it on a matching build host, then run sev-snp-measure. Finally, compare the predicted value with the live report and validate that report through the pinned AMD ARK.

1. Get the OVMF

   VPSBG's custom EDK2 build is used when measured boot is enabled in the portal.

   OVMF_SEV_MEASUREDBOOT_4M.fd (4.0 MB)

   Verify: sha256sum OVMF_SEV_MEASUREDBOOT_4M.fd → e4ac90be71f3b455922ebc7106c5630536bf67027de585e34319b0a42fcd716e

2. Get or rebuild the UKI

   The current operator-archived artifact is main-81dd96d4-db-proof-v2-20260724T112036Z-34b04d1bfc05.efi, the ORAM-enabled Tier 3 UKI that serves the database proof sidecar and direct ORAM lookups for db_id 0/1. It is a large runtime artifact, so this page pins the exact bytes by hash and records the rebuild route rather than inlining the UKI into the static proof bundle. The archive path below is operator-only; it is not a public download URL.

   Verify: sha256sum main-81dd96d4-db-proof-v2-20260724T112036Z-34b04d1bfc05.efi → 34b04d1bfc0501c0cc222aff446a55de0a74d4e5218a21a05bf8756f8293b681

   # Operator-only shortcut: retrieve the exact deployed bytes.
   scp pir-hetzner:/home/pir/uki-archive/tier3/main-81dd96d4-db-proof-v2-20260724T112036Z-34b04d1bfc05.efi .

   Or perform a functional source rebuild. This is not a byte-identical reproduction of the production artifact: the production C++ objects embed their checkout path, and exact output also depends on Rust 1.94.1, GCC 13.3, GNU ld 2.42, and the host's UKI inputs.

   git clone https://github.com/Bitcoin-PIR/Bitcoin-PIR.git BitcoinPIR-runtime-repro
   cd BitcoinPIR-runtime-repro
   git checkout 81dd96d442d39200fee7e6c97f5c308f38126756
   RUSTFLAGS="--remap-path-prefix=$PWD=/build/repo --remap-path-prefix=$HOME=/build" \
   SOURCE_DATE_EPOCH=0 cargo build --locked --release -p runtime --features cuckoo-oram --bin unified_server
   strip --strip-debug target/release/unified_server
   
   sudo env KERNEL=/boot/vmlinuz-7.0.0-28-generic \
   OUT="$PWD/bpir-tier3-functional-rebuild-81dd96d4.efi" \
   BINARY="$PWD/target/release/unified_server" \
   BPIR_UNIFIED_SERVER_BIN="$PWD/target/release/unified_server" \
   ./scripts/build_uki_tier3.sh

   Exact UKI bytes also depend on the documented build-host kernel, dracut, cloudflared, and initramfs inputs. The current deployment pins and validation gates are recorded in docs/history/PHASE3_ROADMAP.md.

3. Predict the MEASUREMENT

   The command below uses the exact operator archive. For a functional rebuild, substitute its filename and expect a different SHA-256 and MEASUREMENT unless every path and toolchain input is reproduced exactly.

   sev-snp-measure \
   	    --mode snp \
   	    --vcpus 2 \
   	    --vcpu-sig 0x00B10F10 \
   	    --ovmf OVMF_SEV_MEASUREDBOOT_4M.fd \
   	    --kernel main-81dd96d4-db-proof-v2-20260724T112036Z-34b04d1bfc05.efi \
   	    --guest-features 0x1

4. Verify the live report and AMD chain

   cargo build --locked --release --bin bpir-admin -p bpir-admin
   ./target/release/bpir-admin attest wss://weikeng2.bitcoinpir.org \
       --expect-measurement d7ae6fb895380b1408b5ba7640a2eaa091754fc6279b62eb96f4bd1eee5532e95bc1df3b1485a06b3f43d648d05d3245 \
       --expect-binary      cc4ec24b9ecf54c962d20843a374a8235d9b71954adf05bdb4d6bb3155e16b1e \
       --expect-ark-fingerprint 1f084161a44bb6d93778a904877d4819cafa5d05ef4193b2ded9dd9c73dd3f6a
   ./target/release/bpir-admin channel-test wss://weikeng2.bitcoinpir.org \
       --expect-ark-fingerprint 1f084161a44bb6d93778a904877d4819cafa5d05ef4193b2ded9dd9c73dd3f6a

   With the ARK pin, attest checks REPORT_DATA, binary, MEASUREMENT, AMD chain, and report signature on one response. channel-test then exercises a fresh attested encrypted session. Expected checkmarks: SEV-SNP REPORT_DATA binding verified, binary_sha256 matches expected, and Launch MEASUREMENT matches expected, followed by AMD ARK→ASK→VCEK chain and this attestation report's signature verified, then a successful encrypted handshake.

5. Smoke the ORAM path

   HASH=4242424242424242424242424242424242424242
   	cargo run --locked -p pir-sdk-client --example oram_local_smoke -- \
   	    --server wss://weikeng2.bitcoinpir.org --db-id 0 --padded-slots 25 "$HASH"
   	cargo run --locked -p pir-sdk-client --example oram_local_smoke -- \
   	    --server wss://weikeng2.bitcoinpir.org --db-id 1 --padded-slots 25 "$HASH"

   Expected runtime signal: sev_status=ReportDataMatch, secure_channel=established, and found=false for the all-42 smoke hash.

Pinned database proof delta 940611 to 948454

Runtime attestation proves which server binary is running. Database build attestation proves that the served PIR Merkle roots were produced by the SEV-SNP attested builder from the claimed Bitcoin Core UTXO snapshots.

Source of truth: web/src/attest-pin.ts::PRODUCTION_DB_PROOF_PINS and docs/history/DB_BUILD_ATTESTATION_PLAN.md.

Verify the live database proof

cargo build --release --bin bpir-admin -p bpir-admin
	./target/release/bpir-admin db-proof verify-live \
	    --server wss://weikeng2.bitcoinpir.org \
	    --db-id 1 \
	    --expect-build-kind delta \
	    --expect-from-height 940611 \
	    --expect-height 948454 \
	    --expect-from-block-hash 000000000000000000002c41243b3d74d135942031ef15f547bca1ce8f85eb99 \
	    --expect-block-hash 00000000000000000001ef683c02c383315db7e917c69d20f79e05985560a4e4 \
	    --expect-muhash cf4fc1f1dd400622a5b6f39eca7f764a30570c30cc668e04f00e8a3356c2a2ee \
	    --expect-bucket-root e2ba2eee6788424309a95f771893d5401cc8e3ceec6188dc2708900e211a910a \
	    --expect-onion-root f86baa3966a61cdcd70d8c0ad9bed233f591806eb351db2ae35ac0192a3fe997 \
	    --expect-builder-binary-sha256 34a677847b9be6580385c73f163279c81561772f8d3ad782d0ca08f1c01fad4a \
	    --expect-builder-git-commit 01e8db91d76037cd5562fce85c40e832ad156431 \
	    --expect-network-magic f9beb4d9 \
	    --expect-params-hash 2b3e488c04433ed8bd293fd3adab72b49bf52346b81160365486d76f9b4d4e39

Repeat with --server wss://weikeng1.bitcoinpir.org to confirm both hosts serve the same self-verifying proof bundle.

ORAM source binding BuildEvidence v2

The published proof binds the production Direct ORAM startup inputs to predecessor-free, AMD-attested full-build V2 database evidence. The historical v1 source proof disclosed its RNG seed and remains only as a negative forensic fixture.

What the browser verifies

• AMD ARK/ASK/VCEK verifies the builder SNP report signature, policy and pinned measurement.
• The report's REPORT_DATA is recomputed from the exact full-build V2 BuildEvidence; V1, reattestation and predecessor hashes are rejected.
• BuildEvidence binds the root payload, database/all-artifacts manifests and exact server MANIFEST.toml.
• The narrow typed [direct_oram] table supplies the exact input hashes, lengths, record counts and lookup layout.
• The current live proof for the selected db0 or db1 entry and the AMD-verified, production-pinned runtime both bind that same server-manifest root.

Published minimum artifacts

Capability boundary

Bitcoin/MuHash anchor proof 940611 → 948454

The delta database proof binds both endpoint block hashes and Bitcoin Core's MuHash at block 948454. The browser verifies a separate BHTM Merkle inclusion proof for each endpoint against the same SEV-SNP-attested mainnet-900000-954920 chunk root. The latest leaf also binds the database MuHash.

What the browser checks

• The verified live server proof matches the published manifest at both delta endpoints, the MuHash, and both PIR Merkle roots.
• Separate BHTM proofs recompute both endpoint leaf hashes and Merkle paths to the same attested chunk tree root.
• report-data.bin equals SHA512("BitcoinPIR/blockhash-to-muhash/report-data/v2" || attestation.bin).
• The SNP report's raw REPORT_DATA field equals report-data.bin.
• The SNP report's raw MEASUREMENT field equals the pinned BHTM UKI measurement.
• The AMD VCEK chain and report signature verify through the same WASM verifier used for runtime attestation.
• Both DB endpoint heights and block hashes equal their BHTM leaves; the latest leaf also equals the DB proof's Core-display MuHash.

The latest-block mempool.space link is an independent user cross-check, not an input to the cryptographic verifier. The earlier endpoint is checked by its own inclusion proof under the same attested root; the attested BHTM process also validates header linkage across the chunk.

Published proof artifacts

The production frontend loads the manifest below, verifies each artifact's SHA-256 and size, then verifies the DB/BHTM chain.

pir1 verification (Hetzner, no SEV)

weikeng1.bitcoinpir.org runs the db-proof unified_server binary on a Hetzner i7-8700. It is intentionally pinned independently from pir2's ORAM Tier 3 UKI. Without a hardware root of trust, the client verifies pir1's self-reported binary_sha256 against a pinned value.

Verify pir1

cargo build --release --bin bpir-admin -p bpir-admin
	./target/release/bpir-admin attest wss://weikeng1.bitcoinpir.org \
	    --expect-binary cc4ec24b9ecf54c962d20843a374a8235d9b71954adf05bdb4d6bb3155e16b1e

You can also check sha256sum /home/pir/BitcoinPIR/target/release/unified_server directly on the Hetzner host.

What this proves

• pir1 and pir2 have independent binary pins; pir2 is additionally bound to the ORAM Tier 3 UKI MEASUREMENT.
• For pir2, AMD signs the loaded confidential-VM runtime and channel binding.
• For pir1, binary-hash pinning detects drift but does not provide a hardware root of trust.
• The database proof binds delta_940611_948454's bucket and OnionPIR Merkle roots to Bitcoin Core's MuHash at block 948454.
• The ORAM source-binding proof binds the measured regenerate-on-boot path to exact Direct ORAM inputs in AMD-attested BuildEvidence V2 for block 948454.
• The Bitcoin anchor proof binds both delta endpoint block hashes and the latest MuHash to one blockhash-to-muhash chunk tree root signed by a separate SEV-SNP BHTM proof run.
• The web client refuses to upgrade to the encrypted channel if runtime pins do not match what the server reports.
• DPF, HarmonyPIR, and standalone OnionPIR verify each database proof in Rust/WASM, compare it with the production pin, install the verified bucket or Onion root, and bind the fetched tree-tops before issuing an address query.
• The ORAM smoke route confirms the live attested binary accepts padded direct ORAM requests for both production databases.

Out of scope

• The custom OVMF binary is binary-pinned, not rebuilt from EDK2 source by this project.
• The exact production UKI is currently retained in an operator-only archive, not a public download. Publishing the 311,033,344-byte artifact or a fully pinned public build environment remains necessary for independent byte-for-byte reproduction.
• The functional UKI rebuild depends on the checkout path, Rust/C++ toolchains, validated kernel, dracut, cloudflared, and initramfs inputs; the Git source checkout alone is insufficient to reproduce the complete UKI bytes.
• AMD's signing keys are trust roots; the project pins the AMD ARK fingerprint but cannot remove AMD from the trust base.
• The BHTM proof is an attested MuHash transition from Core-style stripped deltas. It checks header linkage and txid Merkle commitments; it is not a full Bitcoin consensus validator inside the TEE.
• The strict ORAM source-binding proof is intentionally not a live-image byte-match claim. The measured runtime is trusted to generate and maintain authenticated mutable ORAM state from the verified inputs.
• The v1 database proof does not commit the complete standalone OnionPIR query layout. The production web client therefore checks a separate, explicit layout pin and fails closed on mismatch; a future v2 proof can absorb those fields.