Feature: Use RATS EAT

[drasko]

Is your feature request related to a problem? Please describe.

No

Describe the feature you are requesting, as well as the possible use case(s) for it.

Currently we are sending binary AR: https://docs.cocos.ultraviolet.rs/attestation-attestation-report#attestation-report-structure

Instead of this, we should align to RATS EAT: https://datatracker.ietf.org/doc/rfc9711/, as other providers (Azure, GCP) do, and send EATs to our Relaying Party (CLI).

Indicate the importance of this feature to you.

Must-have

Anything else?

No response

[SammyOina]

@drasko

// EATClaims represents the Entity Attestation Token claims
type EATClaims struct {
    // Standard JWT/CWT claims
    Issuer    string `json:"iss,omitempty" cbor:"1,keyasint,omitempty"`
    Subject   string `json:"sub,omitempty" cbor:"2,keyasint,omitempty"`
    IssuedAt  int64  `json:"iat,omitempty" cbor:"6,keyasint,omitempty"`
    ExpiresAt int64  `json:"exp,omitempty" cbor:"4,keyasint,omitempty"`
    
    // Core EAT claims (RFC 9711)
    Nonce        []byte `json:"eat_nonce" cbor:"10,keyasint"`           // Freshness/replay protection
    UEID         []byte `json:"ueid" cbor:"256,keyasint"`                // Universal Entity ID
    OEMID        int    `json:"oemid,omitempty" cbor:"258,keyasint,omitempty"` // Hardware OEM ID
    HWModel      []byte `json:"hwmodel,omitempty" cbor:"259,keyasint,omitempty"` // Hardware model
    HWVersion    string `json:"hwversion,omitempty" cbor:"260,keyasint,omitempty"` // Hardware version
    SWName       string `json:"swname,omitempty" cbor:"270,keyasint,omitempty"` // Software name
    SWVersion    string `json:"swversion,omitempty" cbor:"271,keyasint,omitempty"` // Software version
    DebugStatus  int    `json:"dbgstat" cbor:"263,keyasint"`             // Debug status
    Measurements []byte `json:"measurements" cbor:"265,keyasint"`        // Software measurements
    
    // Platform type indicator
    PlatformType string `json:"platform_type"`
    
    // Submodules for vTPM and other components
    Submods map[string]interface{} `json:"submods,omitempty" cbor:"266,keyasint,omitempty"`
    
    // Platform-specific extensions (custom claims)
    SNPExtensions *SNPExtensions `json:"x-cocos-sevsnp,omitempty"`
    TDXExtensions *TDXExtensions `json:"x-cocos-tdx,omitempty"`
    VTPMExtensions *VTPMExtensions `json:"x-cocos-vtpm,omitempty"`
    
    // Original binary report (for verification)
    RawReport []byte `json:"raw_report,omitempty"`
}
// SNPExtensions contains AMD SEV-SNP specific claims
type SNPExtensions struct {
    Measurement    []byte `json:"measurement"`      // SNP MEASUREMENT field
    TCB            string `json:"tcb"`              // TCB version info
    PlatformInfo   uint64 `json:"platform_info"`    // PLATFORM_INFO
    Policy         uint64 `json:"policy"`           // POLICY field
    FamilyID       []byte `json:"family_id,omitempty"`
    ImageID        []byte `json:"image_id,omitempty"`
    VMPL           int    `json:"vmpl,omitempty"`
    SignatureAlgo  int    `json:"signature_algo,omitempty"`
    CurrentTCB     uint64 `json:"current_tcb,omitempty"`
    ReportedTCB    uint64 `json:"reported_tcb,omitempty"`
    ChipID         []byte `json:"chip_id,omitempty"`
    CommittedTCB   uint64 `json:"committed_tcb,omitempty"`
    LaunchTCB      uint64 `json:"launch_tcb,omitempty"`
}
// TDXExtensions contains Intel TDX specific claims
type TDXExtensions struct {
    MRTD         []byte            `json:"mrtd"`          // MRTD measurement
    RTMR         [][]byte          `json:"rtmr"`          // Runtime measurement registers
    XFAM         uint64            `json:"xfam"`          // Extended features available mask
    TDAttributes uint64            `json:"td_attributes"` // TD attributes
    MRConfigID   []byte            `json:"mr_config_id,omitempty"`
    MROwner      []byte            `json:"mr_owner,omitempty"`
    MROwnerConfig []byte           `json:"mr_owner_config,omitempty"`
    MRSEAM       []byte            `json:"mr_seam,omitempty"`
    TDXModule    *TDXModuleInfo    `json:"tdx_module,omitempty"`
}
// TDXModuleInfo contains TDX module version information
type TDXModuleInfo struct {
    Major    uint8  `json:"major"`
    Minor    uint8  `json:"minor"`
    BuildNum uint16 `json:"build_num"`
    BuildDate uint32 `json:"build_date"`
}
// VTPMExtensions contains vTPM specific claims
type VTPMExtensions struct {
    PCRs     map[string]string `json:"pcrs"`      // PCR values (SHA256/SHA384)
    EventLog []byte            `json:"event_log,omitempty"` // Event log
    Quote    []byte            `json:"quote,omitempty"`     // TPM quote
}
// DebugStatus constants (RFC 9711 Section 4.2.6)
const (
    DebugEnabled          = 0 // Debug is enabled
    DebugDisabled         = 1 // Debug is disabled
    DebugDisabledSinceBoot = 2 // Debug is disabled since boot
    DebugPermanentDisable = 3 // Debug is permanently disabled
    DebugFullPermanentDisable = 4 // Debug is fully and permanently disabled
)

Flow 1: Direct API Attestation

sequenceDiagram
    participant Agent as CVM Agent<br/>(Attester)
    participant AttSvc as Attestation Service<br/>(Evidence Generator)
    participant CLI as CLI<br/>(Verifier + Relying Party)
    participant Policy as Attestation Policy<br/>(Reference Values)
    
    Note over Agent,CLI: Direct Attestation API Call
    
    CLI->>Agent: Request Attestation(nonce)
    Agent->>AttSvc: FetchAttestation(nonce, platform_type)
    
    Note over AttSvc: 1. Get binary report from TEE<br/>2. Extract platform claims<br/>3. Create EAT token<br/>4. Sign with ECDSA key
    
    AttSvc-->>Agent: EAT Token (JWT/CBOR)
    Agent-->>CLI: EAT Token
    
    Note over CLI: Verifier Role
    CLI->>Policy: Load attestation policy
    Policy-->>CLI: EAT validation rules
    
    Note over CLI: 1. Decode EAT token<br/>2. Verify signature<br/>3. Validate claims vs policy<br/>4. Check nonce freshness<br/>5. Extract binary report<br/>6. Verify platform attestation
    
    CLI->>CLI: Make trust decision
    
    Note over CLI: Relying Party Role<br/>Trust established ✓

Loading

Flow 2: Attested TLS Handshake

sequenceDiagram
    participant Client as CLI<br/>(Relying Party)
    participant Agent as CVM Agent<br/>(Attester)
    participant AttSvc as Attestation Service<br/>(Evidence Generator)
    participant Policy as Attestation Policy<br/>(Reference Values)
    
    Note over Client,Agent: TLS Handshake with Attestation
    
    Client->>Agent: ClientHello + SNI(nonce.nonce)
    
    Note over Agent: Certificate Provider
    Agent->>Agent: Generate ephemeral key pair
    Agent->>Agent: Extract nonce from SNI
    
    Agent->>AttSvc: Attest(pubkey, nonce)
    
    Note over AttSvc: 1. Hash(pubkey + nonce)<br/>2. Get binary report from TEE<br/>3. Extract platform claims<br/>4. Create EAT token (CBOR)<br/>5. Sign token
    
    AttSvc-->>Agent: EAT Token (CBOR)
    
    Note over Agent: 1. Create X.509 cert<br/>2. Embed EAT in extension<br/>3. Sign cert with ephemeral key
    
    Agent-->>Client: ServerHello + Certificate<br/>(with EAT in extension)
    
    Note over Client: Certificate Verifier Role
    Client->>Policy: Load attestation policy
    Policy-->>Client: EAT validation rules
    
    Note over Client: 1. Extract EAT from cert extension<br/>2. Decode EAT token<br/>3. Verify EAT signature<br/>4. Validate claims vs policy<br/>5. Verify nonce matches<br/>6. Extract binary report<br/>7. Verify platform attestation<br/>8. Verify cert signature
    
    Client->>Client: Make trust decision
    
    Note over Client: Relying Party Role<br/>TLS connection established ✓
    
    Client->>Agent: Encrypted application data

Loading

Component Mapping

RFC 9711 Role	Cocos Component	Responsibilities
Attester	CVM Agent + Attestation Service	- Access TEE hardware - Generate binary attestation reports - Create EAT tokens with claims - Sign evidence
Evidence	EAT Token (JWT/CBOR)	- Contains platform claims - Includes measurements - Embeds binary report - Cryptographically signed
Verifier	CLI (Certificate Verifier)	- Decode EAT tokens - Validate signatures - Check claims against policy - Verify platform attestation - Produce attestation results
Reference Values	Attestation Policy JSON	- Expected measurements - TCB versions - EAT validation rules - Platform configuration
Relying Party	CLI	- Receive attestation results - Make trust decisions - Establish secure connections - Execute computations
Attestation Results	Verification outcome	- Trust level established - TLS connection allowed/denied - Computation authorized

[drasko]

@SammyOina format looks good, but one thing that bothers me is that we will be sending every time both SEV-SNP and TDX extensions. We should send one or another, depending on which platform we are.

[SammyOina]

It is either one depending on platform not both at once. Only current platform will be encoded in the token
@drasko

[drasko]

Can you write then there 2 EATs, one per platform, just that we see how they look like.

[SammyOina]

sev/snp

{
  "iss": "https://attestation.cocos.example.com",
  "sub": "vm-instance-12345",
  "iat": 1736694000,
  "exp": 1736697600,
  "eat_nonce": "MTIzNDU2Nzg5MGFiY2RlZg==",
  "ueid": "AQIDBAUGBwgJCgsMDQ4PEA==",
  "oemid": 4130,
  "hwmodel": "U0VWLVNOUCBNaWxhbg==",
  "hwversion": "B1",
  "swname": "CoCoS SEV-SNP Firmware",
  "swversion": "1.51.3",
  "dbgstat": 3,
  "measurements": "YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXowMTIzNDU2Nzg5",
  "platform_type": "amd-sevsnp",
  "x-cocos-sevsnp": {
    "measurement": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "tcb": "03.00.00.00.00.00.00.00",
    "platform_info": 1,
    "policy": 196608,
    "family_id": "AAAAAAAAAAAAAAAAAAAAAA==",
    "image_id": "AAAAAAAAAAAAAAAAAAAAAA==",
    "vmpl": 0,
    "signature_algo": 1,
    "current_tcb": 50462976,
    "reported_tcb": 50462976,
    "chip_id": "ZXhhbXBsZS1jaGlwLWlkLTEyMzQ1Njc4OTBhYmNkZWY=",
    "committed_tcb": 50462976,
    "launch_tcb": 50462976
  },
  "submods": {
    "vtpm": {
      "swname": "MS fTPM",
      "swversion": "2.0.0.0",
      "measurements": "dHBtLW1lYXN1cmVtZW50LWhhc2g=",
      "pcrs": {
        "0": "0000000000000000000000000000000000000000000000000000000000000000",
        "1": "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15",
        "7": "3d6772b4f84ed47595d72a2c4c5ffd15f5bb72c7507fe26f2aaee2c69d5633ba"
      }
    }
  },
  "raw_report": "cmF3LXNldi1zbnAtcmVwb3J0LWJpbmFyeS1kYXRhLWhlcmU="
}

tdx

{
  "iss": "https://attestation.cocos.example.com",
  "sub": "td-instance-67890",
  "iat": 1736694000,
  "exp": 1736697600,
  "eat_nonce": "YWJjZGVmMTIzNDU2Nzg5MA==",
  "ueid": "DxAREhMUFRYXGBkaGxwdHh8=",
  "oemid": 32902,
  "hwmodel": "SW50ZWwgVERYIFNhcHBoaXJlIFJhcGlkcw==",
  "hwversion": "1.5",
  "swname": "CoCoS TDX TD",
  "swversion": "1.0.1",
  "dbgstat": 3,
  "measurements": "cGxhdGZvcm0tbWVhc3VyZW1lbnQtaGFzaC1kYXRh",
  "platform_type": "intel-tdx",
  "x-cocos-tdx": {
    "mrtd": "1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
    "rtmr": [
      "0000000000000000000000000000000000000000000000000000000000000000",
      "abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcd",
      "fedcbafedcbafedcbafedcbafedcbafedcbafedcbafedcbafedcbafedcbafed",
      "1111111111111111111111111111111111111111111111111111111111111111"
    ],
    "xfam": 231928233615523847,
    "td_attributes": 549755813889,
    "mr_config_id": "Y29uZmlnLWlkLTEyMzQ1Njc4OTBhYmNkZWY=",
    "mr_owner": "b3duZXItaWQtOTg3NjU0MzIxMGZlZGNiYQ==",
    "mr_owner_config": "b3duZXItY29uZmlnLTAxMjM0NTY3ODk=",
    "mr_seam": "c2VhbS1tb2R1bGUtbWVhc3VyZW1lbnQ=",
    "tdx_module": {
      "major": 1,
      "minor": 5,
      "build_num": 230,
      "build_date": 20231115
    }
  },
  "submods": {
    "vtpm": {
      "swname": "swtpm",
      "swversion": "0.8.0",
      "measurements": "c3d0cG0tbWVhc3VyZW1lbnQtaGFzaA==",
      "pcrs": {
        "0": "0000000000000000000000000000000000000000000000000000000000000000",
        "1": "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15",
        "7": "8d6772b4f84ed47595d72a2c4c5ffd15f5bb72c7507fe26f2aaee2c69d5633ba"
      }
    }
  },
  "raw_report": "cmF3LXRkeC1yZXBvcnQtYmluYXJ5LWRhdGEtaGVyZQ=="
}