ungovernable.tech

Field guide[ GUIDE ][ CONFIDENTIAL COMPUTING ]

Verifying a confidential workload

Release a test secret only after the workload, hardware evidence and communication channel satisfy your policy.

Usable updated 2026-10-25 3 min read [ ADVANCED ]
Contents

Summary

This walkthrough uses Intel SGX with Gramine's RA-TLS secret-provisioning example, extending the TEE overview. It requires an SGX-capable environment, Gramine with DCAP support, and working DCAP infrastructure. The example releases a disposable test secret; adapt it only after reviewing the application and verifier.

1. Establish what you intend to trust

Obtain a reviewed Gramine source checkout matching the installed libraries. Use CI-Examples/ra-tls-secret-prov/secret_prov_minimal as the workload. Read its manifest and application before generating expected measurements.

Change sgx.debug to false in the minimal client's manifest template before building. Keep the executable, dependencies and provisioning server's CA certificate among the trusted files. If the verifier runs on another machine, configure its address and your own TLS certificate infrastructure before signing.

Do not take an expected measurement from the untrusted workload's own report. Derive it from the build you approved:

# From CI-Examples/ra-tls-secret-prov in the reviewed source checkout:
make app dcap
gramine-sgx-sigstruct-view secret_prov_minimal/client.sig

Record MRENCLAVE, MRSIGNER, ISV_PROD_ID and ISV_SVN. The example README documents these commands and its intentionally permissive test defaults.

2. Configure the verifier's acceptance policy

Run the provisioning server in an environment you trust. Set these variables from the reviewed signature information:

Setting Required check
RA_TLS_MRENCLAVE Expected enclave measurement
RA_TLS_MRSIGNER Expected enclave signer
RA_TLS_ISV_PROD_ID Expected product ID
RA_TLS_ISV_SVN Minimum accepted enclave security version

Do not set them to any: that skips the corresponding check. Keep the debug and outdated-TCB bypasses disabled. The documented variables are RA_TLS_ALLOW_DEBUG_ENCLAVE_INSECURE and RA_TLS_ALLOW_OUTDATED_TCB_INSECURE. Review hardware-configuration and software-hardening results explicitly rather than copying the test suite's overrides.

The RA-TLS reference describes how its verifier delegates quote checking to Intel's DCAP verification library. Working measurement comparisons alone are insufficient: hardware evidence and its supporting validation data must also pass your policy.

3. Attest, connect and release

Start the minimal provisioning server in its example directory on the verifier side:

cd secret_prov_minimal
./server_dcap

In the corresponding client directory on the SGX side, run:

gramine-sgx client

The client creates an RA-TLS certificate containing its SGX quote. The quote binds the TLS public key, so the verifier checks the evidence for the endpoint participating in the TLS session. The client also authenticates the provisioning server using its configured CA. Only successful verification should release the example secret through that connection.

4. Test rejection and repeat after updates

Change the expected measurement to a different value and confirm provisioning fails. Restore it, then confirm a debug enclave is rejected with the debug exception disabled. An updated application or manifest needs a new reviewed measurement; do not fix a failed update by allowing every measurement.

Distinguish a fresh TLS handshake from a blanket promise that all evidence is newly generated. Define evidence freshness and collateral-expiration policy explicitly, using the RATS architecture as a checklist for evidence, endorsements, reference values and appraisal.

Trust model / threat model

Trust includes Intel's attestation roots, the approved application and Gramine build, and the verifier's libraries, policy and reference-value distribution. A remote verification service adds its operator to that set. The host can still deny service; attestation is not a proof that application code has no bugs.

Readiness and limits

Usable integration pattern, with a demonstration service. Gramine explicitly describes its secret-provisioning service as minimal. Replace example certificates and secrets, retain strict checks, and review side channels before adapting it for sensitive workloads.

Primary sources

Page history

Updated
2026-10-25
Origin
Written for ungovernable.tech.
Improve this page
Suggest an edit — issues and pull requests are welcome.