[DISCUSS] Documenting `HSM` as an equivalent alternative to in-place key generation

[TheBankster]

Note

[EDIT 6/17/2025] Reworded to reflect the current state of discussion. The original comment is captured below the ---.

Problem statement

Should TWI-WIMSE I-D (and, by extension, the TWI arch.) document use of HSMs (credential sharing concept) as a level option for achieving Trustworthy Workload Identity ❓

Considerations

1. For the smallest Trusted Computing Base (hence: strongest security guarantees), a Workload needs to be the sole entity capable of completing a proof of possession of a Credential.

   • In practical terms, it would mean the Workload (WL) generates its own keys🔑 in-place and has an Identity Provider issue a Credential🏅 bound to them, without ever exposing the secret part outside of the Workload (i.e. CSR Attestation).

2. Method (1) is not attainable for all existing workloads (looking to migrate their current credentials into TWI-compatible systems) or when credential secret sharing is explicitly required.
   TWI wants to address these usages as well.

   • Solutions for this case (2) require the secret to be generated🔢 and stored🔐 externally to a Workload and provided to it upon request (i.e., WL instantiation), if (and only if) the secret release policy🔎 matches.
   • Since the key is now cold-stored outside of the WL instance, the storage medium becomes part of the TCB as it can impersonate any workload.
   • Contemporarily, such centralized secret generation & storage functions are typically served by KMS systems backed by physical Hardware Security Module boxes (often PKCS#11 and FIPS-compliant).
     • Most HSMs excel at secret protection and performant crypto operations, but are not general-purpose TEEs, hence lack the ability to run policy authorization code, instead relying on classic access authorization (i.e. password, pins). Effectively, while the master secret may be well secured inside an HSM (incl. non-exportable), access to it is effectively controlled by a construct analogous to a bearer token, making everyone in its possession capable of turning the HSM a "signing oracle".
     • Specifically, the general-purpose HSM units don't allow to perform a runtime attestation before accessing the secret. This includes a "wrapped" key export to another location - a HSM can ensure the key never leaves in a plaintext form, but cannot attest whether the owner of a wrapping key is a properly attested TEE or a simulator.
       There are notable exceptions here, as there are HSM offerings capable of running code, hence theoretically capable of attesting the target. For example, see Thales's Functionality Modules or Fortanix's Secure Business Logic.

3. Security drawbacks of secret sharing ((2), above):

   1. Expands the TCB to include the storage medium (i.e. HSM) and its policies. Circumvention of the master store's (i.e. "HSM") policies is a BORE attack, allowing to impersonate any Workload using such store.
      Note this seems unavoidable (just a property of secret sharing).
   2. Unless the KMS/HSM is able to attest the workload on key release, this crosses from a HW-based TEE-land, to a (weaker) policy-based one, changing the typical CC trust model to include an operator inside the TCB (an entity injecting the HSM access credential into the Workload can impersonate it).

What needs discussion by CCC TWI

1. Moving the this discussion into TWI Architecture.
   My claim: WIMSE draft doesn't need the level of detail such as explicit mentions of a concrete solutions (here: HSM), so we can side-step the controversy by keeping it vague and deferring the conversation till later.
   

Tip

If we agree, the action item is to prune all HSM mentions from twi-wimse I-D and replace with a more high-level statement to the effect of TWI means to also support secret sharing concept.

2. Define security guarantee levels TWI can offer and grade the solutions by them. For example:
   1. 🥇 Level1 (best) [recommended for greenfield deployments]: Have workloads self-generate their secrets - no key sharing.
      • If cold storage of credentials is required (cannot be derived ad hoc), it's the Workload who decides how to pass their secrets on to the storage (likely encrypted, i.e. using a HW sealing mechanism, if available platform-side).
   2. 🥈 Level2 have the KMS system (sharing keys) capable of remotely attesting a Workload before sharing a key with them
      • Note that while this is n/a for a regular PKCS#11-only HSM, it can be done in one of the units capable of running policy code (some examples listed above), or the KMS may itself be a TEE (a TWI Workload), possibly even using Threshold Cryptography and running Byzantine Fault-Tolerant state machine replication.
   3. 🥉 Level3 (worst): have the KMS use bearer credentials (i.e. a client TLS certificate + HSM partition password) to authorize key use/export. Such credentials are injected into the Workload by a hosting platform (or its user operator).
      • The HSM credentials would should only be disbursed upon a successful Workload attestation by the platform, yet it still requires to include this mechanism inside the TCB (which now spans: Workload, HSM, Platform), as the Platform can impersonate the Workload when talking to a HSM.

---

Original wording of this issue (👆click to expand)

The HSM piece is a little fuzzy, esp. as I'm not aware of any HSM offering capable of runtime attestation of a TEE/enclave (which would be required for it to issue any kind of key).

On the other hand, if the attestation was to be unidirectional only (TWI attests 'its' crypto provider before asking for key), then:

• If the HSM is 'just' a stateless key generator, it feels like we can just wrap it under "TEE generates the key umbrella", w/o over defining.
• If the HSM has state (and this is a key sharing concept), we have introduced new attack surface (non-CC, it suffices to break the HSM auth token).

Originally posted by @mbronk-intc in confidential-computing/twi-wimse#12 (comment)

[mbronk-intc]

Transferred from twi-wimse as the discussion is relevant for reference architecture, not the WIMSE-facing internet draft.

Previous location: https://github.com/confidential-computing/twi-wimse/issues/15