Attestation & Verification

An attestation report is a cryptographically signed statement produced by the hardware that says: “Code with this exact measurement is currently running inside a genuine TEE on this hardware.” It is the foundation of the zero-trust guarantee in Enterprise Federated deployments.

What an attestation report contains

The AMD SEV-SNP attestation report produced by the Confidential Notary includes:

The report is signed by an AMD private key rooted in the CPU’s hardware. AMD publishes the corresponding certificate chain, so any party can verify a report’s authenticity without trusting VeriProof or Azure.

The attestation flow

When the Confidential Notary starts:

Confidential Notary (inside TEE)
  1. Generate ephemeral RSA key pair
  2. Call ACI attestation sidecar → obtain SNP hardware report
     (report_data = SHA-512(ephemeral_public_key))
  3. Submit report to Azure MAA endpoint
  4. Receive MAA JWT token (signed by MAA, contains measurement)
  5. Bind ephemeral key to attestation token
  6. All subsequent communications from the notary are signed
     with the ephemeral key — recipients can verify the notary's
     identity against the MAA token

The MAA JWT is valid for a configurable window. The notary refreshes its attestation token on a rotation schedule.

Verifying an attestation token

Enterprise customers receive the notary’s MAA attestation token as part of the deployment manifest. To verify it:

Using the Azure SDK

import requests
from azure.identity import DefaultAzureCredential
 
# The MAA token is a standard JWT
import jwt  # PyJWT
 
maa_endpoint = "https://sharedeus.eus.attest.azure.net"
token = "<MAA-JWT-from-notary>"
 
# Fetch the MAA signing keys
jwks_uri = f"{maa_endpoint}/.well-known/openid-configuration"
config = requests.get(jwks_uri).json()
jwks = requests.get(config["jwks_uri"]).json()
 
# Decode and verify
from jwt import PyJWKClient
from jwt.exceptions import InvalidTokenError
 
jwk_client = PyJWKClient(config["jwks_uri"])
signing_key = jwk_client.get_signing_key_from_jwt(token)
 
decoded = jwt.decode(
    token,
    signing_key.key,
    algorithms=["RS256"],
    audience="https://sharedeus.eus.attest.azure.net",
)
 
# Check the measurement matches the expected VeriProof notary build
expected_measurement = "your-expected-measurement-hex"
actual_measurement = decoded["x-ms-isolation-tee"]["x-ms-sevsnpvm-launchmeasurement"]
 
if actual_measurement == expected_measurement:
    print("✅ Notary is running authentic, unmodified VeriProof code")
else:
    print("❌ Measurement mismatch — code may have been tampered with")

Expected measurement values

VeriProof publishes the expected launchmeasurement for each Confidential Notary release in the release manifest. Match the measurement in the attestation token against the published value for your installed version.

What attestation proves

Future TEE platforms

The attestation interface is designed to be provider-agnostic. When AWS Nitro Enclaves and GCP Confidential Space support is added:

• Nitro will use COSE-signed attestation documents verified against AWS’s certificate chain
• GCP Confidential Space will use OIDC tokens verified against Google’s PKI

The verification logic differs per platform but the semantic guarantee is identical.

Next steps

• AMD SEV-SNP in VeriProof — hardware configuration details
• Blockchain Anchoring — how commitments computed inside the TEE are anchored on-chain
• Enterprise Architecture — deployment guide for Enterprise Federated