A Rust-based system for secure attestation and identity management using SEV-SNP confidential computing, with blockchain anchoring for verifiable trust chains.
Patty will serve as an attestation shim service that anchors trust in the blockchain. The real purpose of this blockchain-attested layer is to manage other attested applications, performing the role of verifier in a RATS attestation scenario.
┌─────────────────────────┐
│ Blockchain │ ←── 1. Patty publishes its own SEV-SNP attestation
│ (Trust Anchor) │ ←── 2. Patty reads/verifies other Patty instances
└─────────────────────────┘
↑ ↓
Cross-instance verification
↑ ↓
┌─────────────────────────┐ ┌─────────────────────────┐
│ Patty Instance A │ ←BFT?→ │ Patty Instance B │
│ (Attestation Verifier │ │ (Attestation Verifier │
│ + Key Escrow Service) │ │ + Key Escrow Service) │
└─────────────────────────┘ └─────────────────────────┘
↑ ↓ ↑ ↓
3. Submit evidence 3. Submit evidence
4. Receive verification 4. Receive verification
5. Request keys 5. Request keys
6. Secure key release 6. Secure key release
↑ ↓ ↑ ↓
┌─────────────────────┐ ┌─────────────────────┐
│ Client Service A1 │ │ Client Service B1 │
│ (Attester) │ │ (Attester) │
└─────────────────────┘ └─────────────────────┘
┌─────────────────────┐ ┌─────────────────────┐
│ Client Service A2 │ │ Client Service B2 │
│ (Attester) │ │ (Attester) │
└─────────────────────┘ └─────────────────────┘
│ │
└─────── 7. Present verified ───┘
attestations to
external parties
│
┌─────────────┐
│ Relying │
│ Parties │
└─────────────┘
** Note: Client service to Patty mapping is not 1:1. Patty instances should operate in a cluster, using some distributed algorithm (RAFT? BFT?) to sync state.
Trust Flow:
- Self-Attestation: Each Patty instance publishes its own SEV-SNP attestation to blockchain for self-verification
- Cross-Instance Trust: Patty instances verify each other by reading blockchain attestation records
- Evidence Submission: Client services (attesters) submit their attestation evidence to Patty for verification
- Attestation Verification: Patty verifies the submitted evidence and issues attestation results
- Key Request: Verified client services request cryptographic keys/secrets from Patty
- Secure Key Release: Patty releases keys only to successfully verified client services
- Trust Presentation: Client services use Patty-verified attestations to prove to relying parties that they are running authenticated code
RATS Architecture Roles:
- Attester: Client services generating attestation evidence
- Verifier + Key Escrow: Patty instances performing attestation verification AND secure key management
- Relying Party: External entities trusting Patty-verified attestations
- Trust Anchor: Blockchain providing root of trust for Patty instances
This is a Cargo workspace with a modular library design:
patty/ # Workspace root
├── patty-lib/ # Core Patty protocol library
│ ├── src/
│ │ ├── attestation.rs # Attestation serialization & compression
│ │ ├── blockchain.rs # Generic blockchain client interface
│ │ ├── ethereum/ # Ethereum-specific implementation
│ │ │ ├── mod.rs # Module exports
│ │ │ ├── client.rs # Ethereum blockchain client
│ │ │ ├── contract.rs # Smart contract integration
│ │ │ └── types.rs # Ethereum transaction types
│ │ ├── identity.rs # Instance identity & cryptography
│ │ ├── sev_guest.rs # SEV-SNP hardware interface
│ │ ├── sev_verification.rs # AMD SEV-SNP attestation verification
│ │ └── lib.rs # Library entry point & exports
│ └── Cargo.toml
├── patty-app/ # Main RPC server application
│ ├── src/
│ │ ├── main.rs # Application entry point
│ │ └── rpc_server.rs # HTTP JSON-RPC server implementation
│ └── Cargo.toml
├── patty-policytool/ # Policy management utility
│ ├── src/
│ │ └── main.rs # Policy publishing & verification tool
│ └── Cargo.toml
├── patty-demo/ # Demo client services (separate README)
│ ├── src/
│ │ ├── lib.rs # Demo AI service implementation
│ │ └── bin/ # Safe vs compromised AI demo binaries
│ └── Cargo.toml
├── contracts/ # Smart contracts
│ ├── PattyAttestation.sol # Ethereum attestation storage contract
│ ├── deploy.sh # Contract compilation script
│ ├── foundry.toml # Foundry configuration
│ └── README.md # Contract documentation
├── k8s/ # Kubernetes deployment manifests
│ ├── patty-deployment.yaml # Main Patty server deployment
│ └── *.yaml # Additional service deployments
├── scripts/ # Deployment and utility scripts
│ └── generate-tls-certs.sh # TLS certificate generation
├── Dockerfile # Container build configuration
├── build-reproducible.sh # Reproducible build script
└── Cargo.toml # Workspace configuration
- Identity Management: Ed25519 keypair generation, instance IDs, report data binding
- SEV-SNP Hardware Interface: Direct hardware interaction via
/dev/sev-guest
- SEV-SNP Verification: Complete AMD PKI certificate chain validation and signature verification
- Attestation Verification: Verify client service attestation evidence using SEV-SNP reports
- Secure Key Escrow: Hold and release cryptographic keys only to verified client services
- Blockchain Integration: Generic
BlockchainClient
with Ethereum implementation - Data Compression: Efficient bincode serialization with LZ4 compression for blockchain storage
- Extensible Design: Ready for additional blockchain backends (Solana, etc.)
- HTTP JSON-RPC Server: Comprehensive REST API for attestation and service management
- Service Policy Management: Create and manage verification policies for client services
- Attestation Verification: Verify client service attestation reports against policies
- Key Distribution: Secure key release to successfully verified services
- TLS Support: Optional HTTPS with certificate-based encryption. Certificates are self-signed since we verify authenticity using the blockchain attestations.
- Hardware Integration: SEV-SNP device interaction and report generation
- Blockchain Publishing: Automatic publication of Patty's own attestation to blockchain
- Policy Publishing: Publish verification policies to smart contracts (owner-only)
- Policy Retrieval: Query current active verification policies
- Report Cleaning: Automatic removal of node-specific fields for consistent policies
- Kubernetes Integration: Policy embedding in deployment manifests
- Base64 Encoding: Standardized policy format for cross-platform compatibility
The Patty RPC server provides a comprehensive HTTP JSON API for attestation and service management:
Method | Endpoint | Description |
---|---|---|
GET |
/health |
Health check and version information |
GET |
/status |
Patty instance status, blockchain connection, SEV availability |
POST |
/verify |
Verify attestation for instance ID |
GET |
/api/v1/verify |
Verify attestation (query parameters) |
Method | Endpoint | Description |
---|---|---|
POST |
/new_service |
Create new service with attestation policy |
POST |
/publish_and_verify |
Verify service attestation and return keys |
GET |
/services |
List all registered services |
POST |
/service_details |
Get detailed service information and attestation history |
Create New Service:
POST /new_service
{
"name": "MyService",
"policy_description": "Service with emergency shutdown",
"policy_report": "<attestation_report_object>"
}
Verify Service Attestation:
POST /publish_and_verify
{
"service_id": "uuid",
"attestation_report": "<attestation_report_object>"
}
Service Details Response:
{
"service_id": "uuid",
"name": "MyService",
"public_key": "hex_encoded_key",
"current_policy": {...},
"attestation_count": 1,
"recent_attestations": [
{
"sequence": 1,
"measurement_preview": "hex_preview",
"report_data_preview": "hex_preview"
}
]
}
The RPC server supports optional TLS encryption (WIP):
# Environment variables for TLS
export PATTY_TLS_CERT=/path/to/cert.pem
export PATTY_TLS_KEY=/path/to/key.pem
# Generate self-signed certificates
./scripts/generate-tls-certs.sh
- Rust 1.70+ with Cargo
- Openssl
- SEV-SNP enabled VM (for hardware attestation)
- Ethereum node access (for blockchain integration)
# Build entire workspace
cargo build --release
# Run main RPC server (requires SEV-SNP VM)
cargo run --bin patty
# Run policy management tool
cargo run --bin patty-policytool -- --help
# Test library components
cargo test --package patty-lib
# Check code without building
cargo check
# Build reproducible (WIP) container
./build-reproducible.sh
# Run with Docker
docker run -p 8080:8080 patty:latest
# Deploy to Kubernetes
kubectl apply -f k8s/patty-deployment.yaml
# Blockchain configuration via volume-mounted files
mkdir -p /etc/patty/blockchain
echo "https://eth-mainnet.g.alchemy.com/v2/..." > /etc/patty/blockchain/rpc-url
echo "0xCONTRACT_ADDRESS" > /etc/patty/blockchain/contract-address
echo "0xPRIVATE_KEY" > /etc/patty/blockchain/private-key
# TLS configuration (optional)
export PATTY_TLS_CERT=/path/to/cert.pem
export PATTY_TLS_KEY=/path/to/key.pem
# Generate TLS certificates
./scripts/generate-tls-certs.sh
The library provides a clean abstraction for multiple blockchain backends through a unified BlockchainClient
interface. This allows seamless switching between different blockchain implementations while maintaining the same API.
Patty uses a dedicated smart contract (PattyAttestation.sol
) with a simplified dual-purpose design:
- Policy Management: Owner-controlled verification policies for attestation standards
- Attestation Storage: Complete attestation reports indexed by instance_id for efficient lookup
- Efficient Serialization: Full
AttestationReport
objects stored as compressed bincode for optimal gas usage - Gas Optimized: LZ4 compression reduces storage costs while maintaining fast decompression
- Query Interface: Retrieve attestations by instance_id and manage verification policies
- AMD PKI Verification: Complete SEV-SNP certificate chain validation including ARK/ASK/VCEK verification
-
Compile the contract:
cd contracts && ./deploy.sh
-
Deploy to testnet:
forge create --rpc-url https://rpc.sepolia.org \ --private-key 0xYOUR_PRIVATE_KEY \ src/PattyAttestation.sol:PattyAttestation --broadcast
-
Configure Patty with contract address:
echo "0xCONTRACT_ADDRESS" > /etc/patty/blockchain/contract-address
See contracts/README.md
for detailed deployment instructions.
- Ethereum (and EVM-compatible chains: Polygon, Arbitrum, etc.)
- Future: Solana, Bitcoin, custom chains
The library exposes core types for identity management, blockchain operations, and SEV-SNP attestation handling. The API is designed to be simple and extensible for different blockchain backends.
- Phase 1: Identity generation & SEV-SNP hardware binding
- Phase 2: Modular blockchain client architecture
- Phase 3: Ethereum smart contract & publishing implementation
- Phase 4: Cross-instance attestation verification with full AMD PKI validation
- Phase 5: Compressed bincode storage and policy management tools
- Phase 6: Client service attestation verification (RATS verifier role)
- Phase 7: Secure key escrow and release to verified services
- Phase 8: Production deployment & monitoring
Project Patty includes separate utilities for attestation publishing and policy management to maintain identical host_data
across all nodes:
The main patty
application runs in SEV-SNP enabled VMs to publish attestation reports:
# Run the main application in an SEV-SNP VM
cargo run --package patty-app
# On successful blockchain publishing, the tool will output:
# === Attestation Report for Policy Creation ===
# Copy the following base64 encoded report to create verification policies:
# --- BEGIN ATTESTATION REPORT ---
# <base64-encoded-report>
# --- END ATTESTATION REPORT ---
# Save this to a file and use with: patty-policy publish --report-file <file>
The patty-policy
tool runs outside SEV-SNP environments to manage verification policies:
# Save the base64 encoded report from step 1 to a file
echo "<base64-encoded-report>" > attestation_report.b64
# Publish a verification policy (requires contract owner permissions)
cargo run --package patty-policytool -- publish --report-file attestation_report.b64
# Get the currently active verification policy
cargo run --package patty-policytool -- get
The patty-policy
tool automatically cleans the attestation report before publishing it as a policy:
- Removes node-specific fields:
report_data
andsignature
are zeroed out - Preserves verification fields:
measurement
,host_data
, and other verification-critical fields remain intact - Maintains consistency: All attesting nodes will have identical verification criteria
This ensures that the verification policy applies to all nodes with the same software configuration while excluding node-specific identity information.
Project Patty includes comprehensive AMD SEV-SNP attestation verification following the official AMD specifications:
- Processor Identification: Automatic detection of AMD processor models (Milan, Genoa, Turin)
- Certificate Fetching: Retrieval of AMD certificates from Key Distribution Service (KDS):
- AMD Root Key (ARK) - Self-signed root certificate
- AMD SEV Key (ASK) - Intermediate certificate signed by ARK
- Versioned Chip Endorsement Key (VCEK) - Chip-specific certificate signed by ASK
- Certificate Chain Validation: Using
sev::certs::snp::Verifiable
trait for cryptographic verification - Signature Verification: OpenSSL-based ECDSA signature verification of attestation reports
- TCB Validation: Verification of Trusted Computing Base values against certificate X.509 extensions
- Complete PKI Validation: Full AMD certificate chain verification from ARK to VCEK
- Cryptographic Integrity: SHA-384 hash computation and ECDSA signature verification
- TCB Enforcement: Hardware/firmware version validation against certificate extensions
- Certificate Pinning Ready: Architecture supports ARK certificate pinning for enhanced security
- Processor-Specific Logic: Handles different AMD processor models and KDS requirements
The verification is implemented in sev_verification.rs
and integrated into the blockchain client for automatic validation of all attestation reports before policy comparison.
The SEV-SNP attestation report is a 1184-byte structure that contains hardware-verified measurements and metadata. Patty uses specific fields for identity binding and verification:
// SEV-SNP Attestation Report (key fields for Patty)
// Based on sev crate v6.2.1 AttestationReport structure
struct AttestationReport {
// === PATTY VERIFICATION FIELDS ===
version: u32, // Report version (verified: must be 2)
guest_svn: u32, // Guest security version number
policy: u64, // Guest policy flags
vmpl: u32, // Virtual Machine Privilege Level
sig_algo: u32, // Signature algorithm (verified: ECDSA P-384)
platform_info: u64, // Platform configuration
author_key_en: u32, // Author key enabled flag
// === PROCESSOR IDENTIFICATION ===
cpuid_fam_id: Option<u8>, // CPU family ID (for processor identification)
cpuid_mod_id: Option<u8>, // CPU model ID (for processor identification)
// === PATTY IDENTITY BINDING ===
report_data: [u8; 64], // ⭐ PATTY IDENTITY DATA (Ed25519 public key + timestamp + instance_id hash)
// === PATTY MEASUREMENT VERIFICATION ===
measurement: [u8; 48], // ⭐ CODE MEASUREMENT (SHA-384 of loaded code)
host_data: [u8; 32], // ⭐ HOST CONFIGURATION (consistent across Patty instances)
id_key_digest: [u8; 48], // Hardware root key digest
// === CRYPTOGRAPHIC VERIFICATION ===
signature: [u8; 512], // ECDSA P-384 signature (verified against VCEK)
// === TCB (TRUSTED COMPUTING BASE) ===
reported_tcb: TcbVersion, // Reported TCB version with bootloader, tee, snp, microcode
current_tcb: TcbVersion, // Current TCB version
committed_tcb: TcbVersion, // Committed TCB version
launch_tcb: TcbVersion, // Launch TCB version
// === CHIP IDENTIFICATION ===
chip_id: [u8; 64], // Unique chip identifier (used for VCEK certificate selection)
// === ADDITIONAL CONTEXT ===
current_minor: u8, // Current minor version
current_build: u8, // Current build number
current_major: u8, // Current major version
committed_build: u8, // Committed build number
committed_minor: u8, // Committed minor version
committed_major: u8, // Committed major version
}
Patty binds its cryptographic identity to the SEV-SNP attestation report through the report_data
field:
// 1. Generate Ed25519 keypair for Patty instance
let (identity, signing_key) = PattyIdentity::generate();
// 2. Create report_data with identity information
let report_data = identity.create_report_data();
// Structure of report_data[64]:
// [0..32]: Ed25519 public key (32 bytes)
// [32..40]: Creation timestamp (8 bytes, little-endian)
// [40..56]: SHA-256 hash of instance_id (16 bytes)
// [56..64]: Zeros (8 bytes reserved)
// 3. Request SEV-SNP attestation with identity-bound report_data
let attestation_report = sev_guest.get_report(report_data)?;
Identity Verification:
report_data[0..32]
: Ed25519 public key (proves identity binding)report_data[32..40]
: Creation timestamp (8 bytes, little-endian)report_data[40..56]
: SHA-256 hash of instance_id (16 bytes, additional verification)signature
: ECDSA P-384 signature verified against AMD VCEK certificate
Code Integrity:
measurement
: SHA-384 hash of loaded code/firmware (ensures code authenticity)host_data
: Host configuration data (consistent across legitimate Patty instances)version
: Must be 2 (ensures modern SEV-SNP features)
Hardware Validation:
sig_algo
: Must be ECDSA P-384 with SHA-384reported_tcb
: Trusted Computing Base version (validated against VCEK extensions)platform_info
: Platform configuration flagschip_id
: Unique processor identifier (used for VCEK certificate selection)cpuid_fam_id
,cpuid_mod_id
: CPU family and model IDs (for processor identification)
Policy Enforcement:
policy
: Guest policy flags (debug disabled, migration disabled, etc.)vmpl
: Virtual Machine Privilege Level (must be 0 for highest privilege)guest_svn
: Guest security version number (minimum acceptable version)
Designed to run in SEV-SNP enabled confidential VMs, providing:
- Hardware attestation via SEV-SNP reports
- Identity binding through cryptographic report_data
- Blockchain anchoring for verifiable trust chains
- Reproducible builds for measurement verification