Confidential Workload Attestation Architecture Director

The mandate

The exchange encrypts sensitive legal material inside confidential virtual machines, but each provider exposes different measurements, endorsement chains, firmware states and failure semantics. Key-release rules currently trust provider-specific claims that cannot be compared, revoked consistently or explained to participating law firms. The defined problem is to make workload identity and release policy portable without pretending dissimilar trusted-computing bases provide identical guarantees.

The named deliverable is a Confidential Workload Attestation Reference Architecture and Conformance Suite. It must include a trust-boundary model, claims profile, endorsement and freshness rules, policy decision flow, key-release controls, revocation model, evidence retention, failure modes, provider adapter contracts, executable positive and negative tests, and a migration recommendation for existing workloads.

Four milestones apply: by day fourteen, agree threat model and provider evidence inventory; by week six, deliver the canonical claims and policy model; by week eleven, run the conformance suite against three providers and two firmware-change scenarios; and by week sixteen, submit the accepted reference architecture, exception register and adoption backlog. Milestone invoices depend on the corresponding artefacts.

Acceptance is decided jointly by the chief trust officer and architecture panel. They will sign only when each claim is traceable to a trust root and freshness mechanism, negative tests prevent key release for revoked, downgraded, replayed or unexpected workloads, provider differences remain visible, audit evidence can be reproduced, and an engineering team deploys one adapter using the specification without consultant-written production code.

The client will provide enclave configurations, attestation tokens, endorsement material, firmware histories, key-service policies, threat assessments, provider access, sample workloads and engineers cleared for testing. The engagement excludes application cryptography redesign, legal opinions on privilege, production rollout, provider procurement and operation of key services; unavailable hardware states will be documented as test limitations.

Why this is external work

Platform teams are experts in their chosen providers but have encoded those providers’ vocabulary into local trust decisions. Security assurance needs independence because the same teams designed the current release rules. A specialist who has compared attestation systems can expose non-equivalent claims and create a conformance boundary the exchange can govern without outsourcing judgment to one vendor.

What you will own

• Catalogue measurements, endorsements, certificates, firmware attributes, freshness proofs, debug states and identity claims exposed by each provider.
• Model threats spanning forged evidence, replay, downgraded trusted bases, malicious hosts, stale endorsements, policy drift and verifier compromise.
• Define a canonical claims profile that preserves provider-specific assurance differences while supporting common policy decisions.
• Specify key-release, denial, quarantine, recovery and revocation flows with evidence retention and human exception controls.
• Build executable conformance tests for valid launches, altered images, debug enablement, firmware change, revoked endorsements and unavailable verifiers.
• Demonstrate three provider adapters and quantify portability gaps, operational dependencies and residual trust concentration.
• Deliver the reference architecture, test corpus, implementation guidance, exception taxonomy and signed acceptance evidence.

Candidate qualifications

• Designed remote-attestation or measured-boot systems spanning confidential virtual machines, enclaves, trusted modules or comparable hardware roots.
• Implemented policy-based secret release using verified claims, freshness, endorsements and revocation rather than provider identity alone.
• Compared multiple confidential-computing architectures without flattening material differences in threat model or trusted-computing base.
• Built negative assurance tests for replay, downgrade, debug state, firmware transition, revoked roots or verifier unavailability.
• Communicated hardware trust boundaries to legal, privacy and operational stakeholders responsible for sensitive cross-border information.
• Delivered provider-portable security specifications that an independent client team implemented and validated after the engagement.

Non-negotiables

• Can attend the Montreal design workshops and regional provider tests while working inside the exchange’s controlled evidence environment.
• Will remain independent of confidential-computing providers, key-management vendors and attestation intermediaries during selection analysis.
• Brings hands-on attestation evidence from deployed workloads; encryption strategy or trusted-computing research alone is insufficient.
• Accepts executable negative tests and client implementation as conditions for final artefact acceptance.

1. 49 words maximum. Which attestation claim appears portable across providers but carries materially different assurance semantics?
2. 49 words maximum. Describe the smallest negative test that should prevent a verifier from releasing a production key.
3. 49 words maximum. How would you preserve provider differences while giving policy authors one usable claims vocabulary?