Attestation Mechanism

How Nada Chains Verify Hardware, Code Identity, and Agent Authenticity

Purpose of Attestation

Attestation is the process by which a TEE proves to an external verifier that:

1. It is running on genuine hardware.

2. It is executing a specific, unmodified binary.

3. It has generated an enclave-bound public key.

4. It is isolated and protected from tampering.

5. The output originates from that enclave.

Nada extends traditional TEE attestation into a blockchain-verifiable attestation format suitable for SVM programs.

---

High-Level Flow

+------------------------+      +----------------------------+
|  Trusted Hardware      | ---> | Vendor Signing Authority   |
|  (SGX / SEV / Nitro)   |      | (Intel / AMD / AWS)        |
+------------------------+      +----------------------------+
              |                            ^
              | (1) Measurement Report     |
              v                            |
+----------------------------+              |
|  Nada Agent Runtime (TEE) |              |
+----------------------------+              |
              | (2) Attestation Quote       |
              v                              |
+----------------------------+              |
|   User / SVM Program      | <------------+
+----------------------------+
     (3) Verification

---

Components of an Attestation

A vendor attestation bundle contains:

1. Measurement

A cryptographic hash of the enclave binary:

M = SHA-256(enclave_binary)

This defines the code identity.

---

2. Enclave Public Key

The enclave generates:

agent_sk  (private)
agent_pk  (public)

Only agent_pk is included in the attestation.

This binds:

• the execution environment

• the measurement

• the agent identity

together.

---

3. Hardware Report

Vendor-specific:

• SGX: REPORT + QE report

• SEV-SNP: attestation report + platform certificate

• Nitro: attestation document (JSON + signature)

Example (Nitro-like):

{
  "image_hash": "...",  
  "public_key": "...",
  "timestamp": 1735671234,
  "pcrs": { "0": "...", "1": "..." },
  "sig": "..."
}

---

4. Vendor Signature

The vendor signs the attestation using their hardware root-of-trust:

sig_vendor = Sign_vendor_root( measurement || agent_pk || runtime_data )

---

Nada Attestation Format

Nada wraps the vendor data into:

pub struct NadaAttestation {
    pub vendor_quote: Vec<u8>,
    pub measurement: [u8; 32],
    pub agent_pubkey: [u8; 32],
    pub timestamp: u64,
    pub signature_vendor: Vec<u8>,
}

This allows a Solana/SVM program to verify everything inside BPF constraints.

---

Verification Steps (On-chain)

Step 1 — Parse Quote

Extract fields depending on TEE type.

let quote = parse_vendor_quote(raw)?;

Step 2 — Verify Vendor Signature

Each vendor’s public key is stored in a sysvar or registry account.

verify_signature(quote.data, quote.signature, vendor_pubkey)?;

Step 3 — Verify Measurement

Compare to approved measurements stored on-chain.

require!(registry.allowed.contains(&receipt.measurement));

Step 4 — Verify Enclave-Bound Key

Ensure the public key inside attestation matches the signer.

require!(quote.agent_pubkey == receipt.agent_pubkey);

Step 5 — Verify Output Signature

The enclave signed the output hash with its private key.

let valid = ed25519_verify(
    receipt.output_hash,
    receipt.output_signature,
    receipt.agent_pubkey
);
require!(valid);

Step 6 — Replay Protection

Check timestamp or nonce.

---

Example On-Chain Verification Code

pub fn verify_attestation(
    att: &NadaAttestation,
    registry: &Registry,
) -> Result<()> {
    let vendor_key = registry.get_vendor_pubkey(att.vendor)?;

    // Step 1: Vendor signature
    verify_vendor_signature(&att.vendor_quote, &att.signature_vendor, vendor_key)?;

    // Step 2: Check measurement
    require!(registry.allowed.contains(&att.measurement));

    // Step 3: Check enclave key binding
    let quote = parse_quote(&att.vendor_quote)?;
    require!(quote.agent_pubkey == att.agent_pubkey);

    Ok(())
}

---

Security Guarantees

1. Hardware Authenticity The attestation proves execution happened on genuine hardware.

2. Code Authenticity Measurement ensures the exact binary is known and approved.

3. Key Authenticity The public key is generated inside the enclave and tied to the measurement.

4. Result Authenticity The enclave signs results with its private key — impossible to forge.

5. Data Confidentiality Hardware protects the request and internal agent data.

6. State Isolation No external process can access enclave memory.