HSMAttest / HSM Attest Proposed Solution
HSM Attest Proposed Solution
This page is still under development.
HSM Attest Proposed Solution
This page gives an overview of how HSM Attest proposes to meet the Challenges facing a modern IT System especially considering these Threats.
The tools at our disposal are described in Technical Background.
How does this fit together?
In a perfect world where performance was unlimited, we would:
- Write our entire system to run inside HSMs and
- Be perfect in the first and only release.
- Test enough to be sure of the previous point before creating any sensitive data.
- Cryptographically lock the door and throw away the key on go live.
(Interestingly this is very close to the way in which dedicated payment terminals work.) Sadly, in the world of big cloud applications this is not practical.
How does this fit together Realistically?
Requirements
In the world of big cloud applications:
- Raw performance matters! Scaling and availability requirements place constraints on the architecture. Transaction State must be persisted beyond individual hardware nodes.
- Updates to the running software are necessary. Rollovers must be planned. Old versions must be reliably disabled. Sometimes rollbacks are necessary too. Correct Governance must be assured during all of this.
- Data being processed in clear must exist only inside trusted components with no access to the data from the outside except over precisely defined and trusted interfaces.
- The most sensitive data in the system must be protected by HSMs against exfiltration and misuse and only made accessible to trusted workloads that have been authorised for this access following properly defined rules of Governance.
Architectural Considerations - What is important when designing this?
HSM Attest is intended to be part of a complete application architecture but will not place restrictions beyond the absolute minimum on the rest of the system.
- Processor level enclave technology will be used as the technological basis for attestation and process isolation. HSM Attest is neutral to
- Attestation Technologies, e.g. SGX, TPM, TDX, AMD/SEV, nVidia. This is achieved by the Quote Verification architecture and interface allowing switchable Attestation verification as a deployable option.
- What frameworks are used inside the confidential computing enclaves and does not restrict the operation of any Confidential Computing Configuration manager ("CAS") (Kata, Scontain, Fortanix, Graphene, …).
- There must be a Secure Software Supply Chain with all that that implies. Out of this chain must come:
- A Manifest containing information showing where this build came from in a format that allows a Governor to make an informed judgement.
- The images and any configuration information constituting the Build Products.
- Cryptographic Authentication out of the build server that the manifest and the build products belong together (CC Reference Value, Hashes of other files,…)
Core to the system will be a custom HSM firmware which enforces Governance trust rules as applied to attestable clients.
- Clients will be confidential computing enclaves containing workloads and identified by a Reference Value.
- The format and contents of the reference value will depend on the Confidential Computing technology stack in use.
- Attestation will be delegated by the HSM to an Attestation Request Verifier ("ARV") which may be external to the HSM or internal. In both cases, the relationship between an ARV and the sensitive artefacts that it protects is setup by appropriate Governance.
- Successful attestation and authorisation will result in the issuance of an access token to the client workload which will allow access to the cryptographic interface for the relevant sensitive data for a configurable time period – default 30 Minutes.
- To support scalability, the only actual data stored directly in the HSM will be a set of Scalable External HSM Storage Master keys. All other data, including access tokens and transient data such as NONCEs) will be stored in Scalable External HSM Storage Objects (ESOs) which are encrypted using an ESO Storage Key. and can be passed as input arguments to any HSM containing the same ESO Storage Key.
- Deletion of an ESO Storage Key in an HSM will effectively revoke all ESOs protected by that key for that HSM. This is the main path for provable revocation of HSM Artefacts.
- ESOs may or may not be time-limited in validity, depending on what they contain.
- Possession of the appropriate set of ESO Storage Keys is the determining factor in allowing a particular HSM to service a particular application.
Governance must be flexible and easy. (Difficult security gets bypassed…)
- Quorum rule definitions must be flexible enough to cover all foreseeable M of N of O and other real world scenarios.
- HSM access rights must be flexible to define and assignable to different quorum rules as wished.
- Quorum rules must also be definable for the management of governors and other quorum rules including themselves
- Onboarding, management and authentication of governors and the exercising of Governance decisions must be supported by appropriate tools.
- Tools for the exercising of governance decisions at the appropriate place in the product deployment cycle must be flexible enough to allow integration into 3rd party toolchains and the asynchronous assembling of a quorum.