Quick summaries for use in argumentation:

Quick summaries for use in argumentation:

Why HSMs?

Plus:

HSMs place strong limits on side channel access - less attack surface.
APIs to HSM can be black box verified and limited, specifically, we can verify that extra access is NOT present.
Defined Governance Channels can be (a) strong, (b) strongly defined and (c) verified.

minus:

limited performance
perceived extra operating effort.

"Ideal"?

In the "ideal" world we would:

• implement everything in the HSM
• be perfect in the first release
• Test enough of the above to be certain before creating any sensitive data
• Cryptographically lock the door and throw away the key on go live.

Functional Demarcation

The discussion we had highlighted the importance of defining the split in responsibility between Confidential TEEs, especially the coordinator and the HSMs. There are a number of models:

• No HSMs. CC can do everything.
• CC does almost everything, standard HSM used to keep recovery keys for coordinator state.
• CC Coordinator gateways access to HSM and forwards keys from HSM to TEE workloads as required.
• CC protects integrity and identity of application code. HSM guards working keys and supplies them to TEEs as required following attestation.
• Combination of 3 and 4. Coordinator takes central role, but must attest itself to HSM to access keys which it then distributes to the TEEs.

Threats:

• External parties - already mostly covered by good OWASP and zero trust.
• Operator - Whoever is operating the target clusters,
• CC framework providers
• Internal vectors, developers, managers etc.

The only way to be sure we can mitigate 3 and 4 is by having provable and immutable chains of trust in our governance.

Proxy verification:

This approach is part of the IETF RATS reference architecture.

It is designed to keep the HSM firmware simpler and more stable as well as being technology neutral.

The QVP must be small, strictly defined and stable so that we can trust it, with a minimal API and no side channels.

The QVP has the following responsibilities ONLY:

• Cryptographically verify attestation reports from the supported hardware platform
• Extract that part of the report that is of interest to us in this context as well as the NONCE value.
• Build the above into a simple digest that the HSM can easily use to identify the attested TEE.
• Sign the digest so that the HSM knows to trust it.
• Manage the key used for the signature securely.
• Provide an attested path to supply the public key to the HSM.
• Specifically, the QVP has NO knowledge or logic about whether a given reference value indicates a trusted TEE or not.

Kata and CoCo:

These are far more complicated and extensive than we need - we should aim to minimise our trusted code base.

We ONLY need these to ensure the Integrity and identity of our TEE workloads. For this we need:

• Guarantee of correct startup content
• Process memory protection
• Attestation report generation
• Build processes from docker images
• NOTHING else.

We will add the following:

• HSM access
• A QVP/ARV implementation for AMD/SEV (not dependent on Kata really)
• Attestation based Secure mTLS Mesh (Envoy) secured by HSM.
• No knowledge of or enforcement of enrolled TEEs -> all done by HSM and QVP.
• Governance management and provisioning tooling

NOT included in this, but part of any application deployment built on top of it will be:

• Provisioning of ESO objects and other HSM-related config (IPs, credentials, etc.) securely
• Provisioning of other application config and relationship to stored HSM config. (Standard Kubernetes secrets?, hard coding, ...?) This is a potential attack vector, so some thought is needed here. We could encrypt these with an HSM curated key?