Skip to content
HSMAttestHardware-rooted trust. Attested access. Chris Cracknell / Work

HSMAttest / HSM Attest Technical Background

HSM Attest Technical Background

This page is still under development.

HSM Attest Technical Background

Back to Documentation Map

This page describes some of the technical background to the problem domain that HSM Attest is addressing. It includes:

Perimeter Security vs Zero Trust

Zero Trust (ZETA) is a security model promoted by NIST which addresses the obvious weaknesses of the perimeter security model used in many older systems.

Perimeter Security

In this case, a system is protected at its network points of contact with external actors which gateway access to the network on which the system is accessible. For example, a company intranet with a single sign on.

Once an actor has gained access to the network, then it is assumed to be a valid actor and granted rights on the various system endpoints reachable on the network.

This is vulnerable to exploitation of simple security breaches, for example one compromised employee logon can grant access to the every system on the whole network. This violates the fundamental security principle of Least Privilege.

Zero Trust

Also known as "ZETA" for "Zero Trust Architecture". This is a misnomer, the architecture is actually a redefinition of boundaries within which elements of trust exist. It would be better called "Zero Implicit Trust".

In this model, systems are separated into trusted enclaves (Which may or may not be confidential computing enclaves as well...):

  • Within these enclaves communications and identity is assumed to be trusted, e.g. the internals of one system element. A system element can be large or small, depending on the design decisions made.
  • This trust in communications requires protection from modification or exposure outside the enclave and against manipulation of known origin. (Confidentiality, Integrity and Authenticity)
  • Between system elements running in trusted enclave, all communications and identity of actors is assumed to be untrusted and of unknown origin until basic protection of the communications protocol is in place and an identity check (Authentication) has been carried out together with a decision as to what rights that identity may have on the system (Authorisation).
  • The establishment of a trusted incoming connection must be dynamic, i.e Renewed on every fresh connection attempt as well as periodically according to some expiry period defined by the system.

Confidential Computing

What is Confidential Computing? What can it achieve?

Confidential computing involves processing of data and communications only inside or between software/hardware modules whose behaviour is known and trusted.

  • Trust can mean different things in different situations – the core of confidential computing is that we know what trust we can assign to what entity.
  • The software/hardware which we trust is known as the trusted computing base. It has boundaries and we need to be aware of what is inside and what is outside of the TCB.
  • The process of verifying that a component is what it claims to be is known as attestation and is based on information about what the component IS (checksums, etc.), not just on what it knows (e.g. passwords, certain keys,...)
  • There are various technologies to do this. Some examples are Intel SGX, TPM, AMD/SEV.

Confidential computing does NOT tell us if an attested component is trustworthy. It only tells us that the component is that which it claims to be.

  • The assignation of trust to that component is a result of Governance. i.e. at some point we have examined this component (software image, hardware platform, …) and made a decision that it is trustworthy.
  • The assignment, tracking and enforcement of these governance decisions is the core behaviour of a confidential computing framework

For more background on confidential computing, visit the Confidential Computing Consortium

Hardware Security Modules

What are hardware security modules? What protection can they provide? What can they not do?

Hardware security modules are dedicated hardware designed for secure storage of sensitive and critical data.

  • They come in a variety of hardware formats, ranging from networked data centre HSMs in 19” format, through specialised devices, e.g. payment PINPADs down to smart cards and modules embedded in other chips (e.g. TPM).
  • They can be certified to a number of standards of varying strictness, e.g. FIPS-level 3… or Common Criteria, or purpose specific standards such as PCI.
  • HSM hardware has tamper detection built into its hardware and is designed to destroy its contents rather than allow them to be released.
  • HSMs have very strict and well-defined Authentication and authorisation models to control who can configure, control and use the HSM.

The main benefit of an HSM is that it greatly reduces the attack surface available for accessing the secrets that it protects.

  • Physical Access is restricted by tough tamper resistance.
  • Software Side channels are excluded by limiting the digital interfaces available to outside clients.
  • The limited size of the available interfaces to the HSM makes strong black and white box validation of the HSM practicable.

HSMs have some limitations:

  • HSM Hardware is usually of very limited raw processing power, limiting the amount of processing that can be done inside the device.
  • Authenticated access to the working interface of the HSM will allow use and, in the wrong hands, abuse of the sensitive data.
  • HSM Operations can add a new layer of complexity (cost and risk) to the operation of a system, though there are options to purchase managed HSM capacity from most cloud providers.