Check the workload
Appraise the software evidence against your accepted measurements, signer and security policy, and bind it to the protected session.
Confidential computing & remote attestation
Protect the application.
Verify the workload.
Confidential computing introduces a new application boundary. Host services, key handling, evidence and acceptance policy all need explicit design. Canopy supplies reusable runtime and security components for that transition.
Canopy's secure-route protocol can combine Intel SGX DCAP evidence, application identity policy, fresh key agreement, and protected RPC in one session. The implementation has demonstrated a three-enclave hardware route. Customer deployments package that capability with the trust policy, credentials, collateral, trusted time, and qualification for their target hardware.
Canopy is designed to be attestation-backend agnostic. Its common evidence, claims, policy, and secure-session model provides the path to heterogeneous bilateral attestation: each endpoint can use a different evidence technology while sharing the same transcript-bound protected route.
Zero-trust networks & applications
Make access depend on evidence and authority.
Being on the network should not be sufficient to trust a caller or a workload. Canopy can support a zero-trust architecture by combining protected sessions and workload evidence with application-defined identity, permissions and release policy.
Limit the authority
Validate the caller’s identity and expose only the operations and data it is permitted to use. Keep these decisions in the application’s policy.
Canopy supplies components for this architecture. Identity issuance, authorisation, session lifecycle and operational enforcement must be composed and tested for the deployment.
This follows the resource-focused principle of NIST’s zero-trust architecture: network location alone does not confer trust.
Four questions. Four distinct checks.
01 · Can we connect?
Network controls determine reachability. A connection alone does not establish who or what is at the other end.
02 · Which workload is it?
A workload identity binds a name to a key. Its assurance depends on the issuer and the checks behind that identity.
03 · What software is running?
Hardware evidence can identify a defined software boundary. A relying party checks it against an acceptance policy and binds it to the session.
04 · Is the information accurate?
Approved software can still receive inaccurate inputs. Provenance and independent sources support assessment; attestation does not establish the truth of an observation.
Authorisation is a further application decision: what may this authenticated principal do with this resource? Accepted software evidence does not grant permission by itself.
What Canopy can do now
Mutual or one-sided attestation
A route can require peer evidence, present local evidence, or require both endpoints to attest before the secure session becomes active.
Bind evidence to the live session
Fresh nonces, endpoint identities, credentials, policy profiles, verifier challenges and both ephemeral key shares are covered by the attested transcript.
Apply workload and TCB policy
DCAP appraisal can enforce enclave and signer measurements, Product ID, minimum security version, debug state, collateral status and accepted TCB results.
Protect RPC end to end
Accepted evidence feeds the same X25519 key agreement and AES-256-GCM protected-RPC layer used across direct and multi-hop Canopy routes.
Intel SGX DCAP
Canopy includes quote generation, host QvL verification, enclave-side QvE/TVL verification, normalized claims, trusted-time integration points and fail-closed policy. Fake and SGX-simulation backends are also available for integration and CI testing without presenting themselves as hardware evidence.
Secure-route capability
Transcript-bound evidence, mutual secure-route handshakes, protected RPC, replay
protection, policy-controlled claims, expiring sessions and background re-attestation and
rekey.
Hardware demonstrated
Three independently loaded Release enclaves established protected routes through an
intermediate enclave, completed a 100-sample RPC benchmark, and rejected a deliberately
wrong signer.
Customer deployment
Each production profile freezes and qualifies the accepted TCB state, hardware fault
tests, workload identity, credentials, trusted-time authorities, and trust policy for the
customer's environment.
Browser and external-client attestation
Canopy also provides a protected-session profile for browser JavaScript, Node.js and native clients. It binds the client nonce, selected interface fingerprints, origin or carrier context, effective configuration, workload identity and fresh session keys to the evidence before application RPC begins.
The JavaScript client includes local appraisal for integration testing and a Microsoft Azure Attestation adapter that validates DCAP binding and signed MAA results against independently supplied trust keys and application policy. Customer delivery packages the browser assets, independently trusted keys, key lifecycle, application policy, and target-hardware appraisal as one reviewed profile.
Deployment model and optional expansion
Customer-qualified SGX
A production engagement packages current-TCB hardware qualification, trusted-time
authorities, identity policy, route credentials, collateral handling, and operational
rotation around the implemented DCAP route.
More confidential-computing platforms
Beyond SGX, the roadmap tracks AMD SEV-SNP, Arm CCA and Arm PSA. Intel TDX, AWS Nitro,
TPM/DICE and confidential-GPU evidence are deployment-led future backends.
Heterogeneous bilateral attestation
The backend-neutral bilateral model is designed for each endpoint to present a different
evidence profile — for example SGX on one side and SEV-SNP or CCA on the other — while
sharing the same transcript binding, normalized policy decision, and protected-RPC
channel.
External-client delivery
Browser packaging and the authenticated MAA trust-key lifecycle are configured with the
customer profile. Optional cross-zone relay and a future WebTransport profile build on the
existing protected external session.
Cryptographic agility
A future secure-session version will support reviewed suite migration, including
evaluation of hybrid X25519 plus ML-KEM key establishment without downgrade.
Attestation is part of the trust decision
Platform evidence proves the properties selected by policy. Canopy then binds that verdict to the live encrypted route; application authentication and object-level authorization remain explicit controls rather than assumptions hidden inside a quote.
Assess the control against the threat.
Credential misuse or altered software
Workload identity and software appraisal answer different questions. Review key protection, approved reference values and update policy. Approved code may still contain defects.
Replayed evidence or disrupted connectivity
Bind evidence to the intended session and define freshness. Cached results and disconnected operation need explicit expiry and withdrawal rules; attestation cannot deliver packets over a missing link.
Misleading observations
A measured workload can process inaccurate inputs. Source provenance and independent checks support assessment; software evidence does not prove what happened in the world.
Proposed integration
Require accepted evidence before issuing a credential.
- Create the workload key inside the protected boundary.
- Bind fresh evidence to the key, policy and issuer challenge.
- Have a verifier appraise that evidence against the agreed policy.
- Issue a workload credential only when the checks pass.
- Enforce expiry, withdrawal and session policy throughout its use.
This issuer integration and its end-to-end refusal case remain proposed. The recorded Cerberus protected call uses direct client appraisal. Refusing renewal does not cancel an existing credential or terminate an established session.