Secure Enclave Remote Attestation for Meter Identity Binding and Key Material Protection

[elizabetheonoja-art]

Problem Statement / Feature Objective

Meter identity is currently authenticated via a pre-shared key (PSK) derived from a hardware identifier and stored in a local database. This approach is vulnerable to key extraction from the database (even if encrypted at rest) and provides no strong binding between the cryptographic identity and the physical meter hardware. A secure enclave (Intel SGX / AMD SEV) remote attestation mechanism must be implemented where meters (or a hardware security module on behalf of the meter) perform a remote attestation against the utility backend, proving they are running known firmware in a trusted execution environment. On successful attestation, a session-bound asymmetric key pair is generated inside the enclave, and the public key is certified by the backend. All subsequent telemetry signatures are verified against this attested public key rather than a static PSK.

Technical Invariants & Bounds

• Attestation protocol: Intel SGX DCAP (Data Center Attestation Primitives) or AMD SEV-SNP guest attestation. The backend acts as the relying party (RelyingParty in RA-TLS or similar).
• Quote verification: backend verifies the SGX quote against Intel's PCS (Provisioning Certification Service) or a local caching proxy. Verification must complete within 200 ms per attestation.
• Session key: after attestation, an ECDSA P-256 key pair is generated inside the enclave. The public key is signed by the backend with its own ECDSA key, producing a meter certificate with 7-day validity.
• Telemetry signature: each meter event is signed with ECDSA P-256 using the enclave-protected private key. Signature size: 64 bytes (r||s DER-encoded). Verification rate target: 10,000 signatures/sec on a single core.
• Key revocation: a Certificate Revocation List (CRL) is published via a Soroban contract; the backend refreshes its CRL cache every 5 minutes.
• Enclave memory: SGX enclave memory limited to 128 MB EPC (Enclave Page Cache). The attestation handler must minimize enclave residency; the enclave exits after key generation and signing.

Codebase Navigation Guide

• src/identity/attestation.rs — new module: remote attestation verification, quote parsing, and certification.
• src/identity/signer.rs — new module: ECDSA P-256 signature verification and CRL checking.
• src/identity/cert_store.rs — new module: meter certificate storage (RocksDB column family) and CRL cache.
• src/transport/tcp/acceptor.rs — on new connection, initiate attestation handshake before allowing data transfer.
• src/blockchain/soroban/contracts/crl.wat — new Soroban contract for CRL publication and query.
• src/config/default.toml — add [identity] section: { attestation_enabled = true, crl_refresh_interval_s = 300, max_attestation_time_ms = 5000 }.
• Cargo.toml — add sgx-dcap-quote-verify (or equivalent), p256, ecdsa, x509-cert.
• tests/identity/attestation_test.rs — integration test with a simulated SGX enclave (using sgx-sim or a software TEE emulator).

Implementation Blueprint

1. In attestation.rs, define struct AttestationVerifier { pcs_client: PcsClient, config: IdentityConfig }. Implement async fn verify_quote(&self, quote: &[u8], expected_meter_id: MeterId) -> Result<AttestationReport> that parses the SGX quote structure, verifies the IAS/DCAP report signature, checks the TCB level (minimum: SWHardeningNeeded), and extracts the report_data which must contain SHA256(meter_id || backend_nonce).
2. ECDSA key certification: on successful attestation, the meter sends its ECDSA P-256 public key (signed by the enclave's attestation key). The backend verifies the signature, generates an X.509v3 certificate with a 7-day validity, signs it with the backend's CA key, and stores it in cert_store.
3. In signer.rs, implement fn verify_signature(meter_id, event_bytes, signature: &[u8; 64]) -> Result<()> that loads the meter's certificate from cert_store, extracts the public key, and verifies the ECDSA signature. Check the CRL before verification; if meter_id is on the CRL, return IdentityError::Revoked.
4. In cert_store.rs, store certificates keyed by meter_id in a RocksDB column family. Also store CRL entries as HashSet<MeterId> in a separate CF, with a background task refreshing from the Soroban CRL contract every 5 minutes.
5. In acceptor.rs, after TCP accept and TLS handshake, initiate the attestation challenge: send a random 32-byte nonce to the meter, set a 5-second timeout. Await the meter's attestation quote + ECDSA public key. Verify and return a session certificate. Until attestation completes, the connection is not authorized to send telemetry data; any data received before authorization is discarded.
6. Deploy a Soroban contract crl.wat that maintains a Vec<MeterId> (compressed via a Bloom filter for gas efficiency). The backend periodically pushes revoked meter IDs and queries the contract for CRL inclusion checks.
7. Write an integration test using sgx-sim (SGX software emulation) to simulate a remote attestation flow, verify that a legitimate quote results in a valid meter certificate, and that telemetry signed with the attested key passes verification. Also test that a revoked meter's signature is immediately rejected.

[clintjeff2]

Hello, I have 6 years of experience working on tasks like this and handling similar challenges across backend, frontend, and smart-contract development. I have carefully read and fully understood the task requirements, and I am confident I can deliver a clean, efficient, and well-tested solution promptly. I always ensure high-quality implementation, maintainability, and adherence to best practices.

Pull request in 5 hours.