Customer Verification

This guide explains how customers can independently verify zero-knowledge proofs generated by vendors.

Overview

As a customer, you can verify that a vendor's software does NOT contain specific banned packages without seeing their actual SBOM. The verification process:

1. Retrieve the proof from IPFS
2. Decode and send to verifier-service
3. Receive cryptographic confirmation

What You Need

From the vendor:

• Composite hash - To retrieve the proof from IPFS
• Root hash - SMT root hash (can also be retrieved from blockchain)

From your side:

• Access to a verifier-service (can be the vendor's or self-hosted)

Retrieving and Preparing the Proof

Step 1: Fetch from IPFS

Retrieve the proof using the composite hash provided by the vendor:

curl -s "http://ipfs-service/retrieve/<composite_hash>" > ipfs_response.json

The response contains:

{
  "proof": "<base64-encoded-proof-json>",
  "ipfs_cid": "Qm...",
  "composite_hash": "..."
}

Step 2: Decode the Proof

The proof field contains base64-encoded JSON. Decode it to get the verification request:

jq -r '.proof' ipfs_response.json | base64 -d | jq . > proof.json

The decoded proof.json contains:

{
  "proof": "<base64-encoded-risc-zero-receipt>",
  "image_id": ["123456789", "987654321", "...", "..."],
  "root_hash": "97fd46cc...",
  "banned_list_hash": "a1b2c3d4...",
  "compliant": true
}

Verifying the Proof

Send the decoded proof directly to the verifier:

curl -X POST "http://verifier-service/verify" \
  -H "Content-Type: application/json" \
  --data-binary @proof.json

Response

{
  "proof_verified": true,
  "root_hash": "97fd46cc...",
  "banned_list_hash": "a1b2c3d4...",
  "compliant": true,
  "image_id": ["123456789", "..."]
}

If proof_verified is true, the proof is cryptographically valid.

What Verification Proves

A successful verification (proof_verified: true) provides cryptographic certainty that:

• None of the packages in the banned list exist in the vendor's SBOM
• The SMT root hash matches the vendor's commitment
• The proof was generated by the authentic TrustBOM guest program
• No tampering occurred

Optional: Verify the Banned List Hash

If you want to confirm that the proof was generated for your specific banned list, you can compute the hash yourself and compare it to the banned_list_hash in the proof.

tip

This step is optional. The proof is valid regardless, but checking the hash lets you be certain that the proof covers exactly the packages you requested.

import json
import hashlib

# Your banned list (must match exactly what was sent to the vendor)
banned_list = [
    "pkg:npm/log4j@2.14.0",
    "pkg:npm/event-stream@3.3.6"
]

# Compute hash using compact JSON (no spaces)
banned_json = json.dumps(banned_list, separators=(",", ":"))
banned_hash = hashlib.sha256(banned_json.encode()).hexdigest()

print(f"Expected hash: {banned_hash}")
# Compare with banned_list_hash in proof.json

Self-Hosting the Verifier

For maximum trust, you can run your own verifier instance:

docker run -p 8081:80 ghcr.io/tuberlin-blockchain-prototyping/sharing-sbom-system/verifier-service:latest

Then verify against your own instance:

curl -X POST "http://localhost:8081/verify" \
  -H "Content-Type: application/json" \
  --data-binary @proof.json

Verification Errors

Error	Meaning
Root hash mismatch	Proof was generated for a different SMT
Banned list hash mismatch	Different banned packages were checked
Compliant flag mismatch	Expected vs actual compliance differs
Invalid proof	Proof corrupted or tampered
Verification failed	RISC Zero receipt invalid