External HSM Storage in HSMAttest

External HSM Storage in HSMAttest

Hardware security modules (HSMs) store critical security artefacts for large backend systems. To support High Availability clustering of the HSMs it is necessary to store the actual artefacts outside the HSMs but protected by a storage key held inside the HSMs, thereby enabling the HSMs to behave as if they are stateless at transaction time (REST).

The storage objects (External Storage Objects (ESO) are created and returned by calls to the HSM by setup operations. These are then passed back to the HSM when required by runtime or further setup operations. This pattern is known as REST (REpresentative State Transfer) and is more commonly seen and well known in http applications. Note that the receiving HSM need not be the issuing HSM as long as they both possess the correct Storage Key. The REST architecture has proven to be an effective means scalability.

The importance of Revocation

A problem arises when wishing to revoke one or more of these objects since, once issued, there is no mechanism to guarantee that no copy remains outside the HSM.

To achieve hard revocation (an important requirement in real-world security) the related storage key must be deleted in all the HSMs of a cluster but this will thereby also invalidate any other artefacts protected by the same key (Collateral Damage)...

HSMAttest mitigates this damage by using multiple storage keys in an organised hierarchy. One storage object is always protected by one storage key though one storage key may protect multiple objects. With careful planning (an example of which is provided in the Best Practices for HSMAttest), runtime artefacts are grouped according to likely revocation events. For example, a whitelisting of a TEE Image is likely to be revoked in a different manner and for different reasons than a working application key (e.g. discovered vulnerability in TEE vs planned rollover of working key). Through this structure, we can reduce the scale of collateral damage to a much smaller set of related artefacts. However some ESOs will still be invalidated that we DO wish to continue using - for that we support:

Migration of ESOs

When a group of ESO sharing a storage key are invalidated as a group because one of them has been revoked (usually in response to some failure of continued trust in the artefact) then other ESOs sharing that storage key can be migrated to a new storage key under certain conditions:

1. The migration happens during a secure session with setup governance,
2. and access to an HSM which has both old and new storage keys present. Ideally separated from the running HSM cluster for the duration of the migration).
3. The setup Governor(s) explicitly migrate each single ESO whose contents are to be preserved.
4. Once all the required ESO migrations have been done, the old storage key is deleted across the HSMs in the cluster and the application starts to use the new, migrated, ESOs instead of the old.

(The design criteria applied here is to minimise the amount of HSM Operator effort required to restore a working state with all non-revoked objects available after a revocation scenario.)