Hardware Security Modules can be complicated so we have asked Lukáš Geyer from Geyer Consultancy to explain more about the subject.
What is a Hardware Security Module (HSM)?
In the context of cybersecurity, the HSM is a hardware device that is used as a dedicated storage for cryptographic keys and a dedicated execution environment for cryptographic operations. These hardware devices should then be stored in a secure facility and mounted in a dedicated rack.
The typical examples of HSM devices are a network-based HSM appliance, PCI HSM, cryptocurrency wallet, TEE (Trusted Execution Environment), TPM (Trusted Platform Module) and a smartcard and while not all of these devices provide the same level of assurance, meet the same regulatory/compliance requirements and provide the same security properties, they all are share the same defining characteristics of an HSM,
- Dedicated secure storage for cryptographic keys
- Dedicated execution environment for cryptographic operations.
Where and why are HSMs used?
Although the more cautious approach to applied cryptography is open-source and reviewed by many as opposed to closed-source and proprietary, in the contemporary technical literature (as of May 2022) the HSMs are defined as the most secure way to store a cryptographic key and a root of trust.
The term root of trust means that the HSM appliance as a product provides the highest possible level of assurance, in other words the HSM guarantees that either what you put inside the HSM or what you execute inside the HSM will remain secure or in case of tampering, it will either provide a detailed audit log of the attempt (tamper-evident) or it will destroy the cryptographic keys stored inside the HSM before they could be misused/exfiltrated instead of disclosing it (tamper-resistant).
The HSM also contributes to several security architecture & cryptography principles, either directly or indirectly,
- Secure by default
- Fail securely
- Defense in depth
- Least privilege
- Separation of duties
- Secure data sanitization
- Isolation
- Kerckhoff’s principle
The HSM is also protecting sensitive data in all three states,
- Data-in-transit (predominantly TLS)
- Data-at-rest (predominantly storage encryption)
- Data-in-use (predominantly TEE; either within CPU as an physical enclave or as a separate TEE appliance)
As a few examples, you will find HSM integrated into the following cybersecurity solutions:
- Digital signing solutions e.g. document signing (PDF, XML), signing SAML assertions
- Card issuance systems e.g. issuing digital certificates that are enrolled onto smartcards
- DNSSEC, DNS over TLS
- PKI (Public Key Infrastructure) e.g. either as a separate HSM appliance that integrates with the CA (Certification Authority) or as a PKI platform where the CA software and the HSM constitute a single physical appliance
- CKM (Cryptographic Key Management) or EKM (Enterprise Key Management)
- MPC (Multi-Party Computation)
- DLT (Distributed Ledger Technology)
- Cloud e.g. HSM as a Service or CKM as a Service
Best practice when operating HSMs
The following list is not an exhaustive list of good practices when integrating or operating HSMs, but merely more critical practices to take to heart,
- Configure a secure source of time and the correct timezone.
- Configure audit logging BEFORE initializing the HSM and not after.
- Maintain an up-to-date inventory of HSM configuration and partition policy for each HSM integration within your organization.
- Review each HSM configuration setting with the HSM vendor until you have a clear understanding of what each HSM setting does.
- When performing any activity with the HSM, read every prompt 2–3 times before typing ‘yes’ or pressing a button.
- When performing any HSM activity that requires a user-supplied password, make sure you know exactly what you have in your clipboard.
- When making any changes to HSM, make sure that all accountable stakeholders understand the impact of the change (Remember: Not everyone is a cryptography expert) and get their approval in writing.
- Perform periodical and automated review of the HSM configuration.
- The HSM backups must be stored as securely or more securely than the HSM appliances and tested regularly.
- The HSM testing environment has to be the exact replica of the producation HSM environment i.e. firmware, software, high-availability.
- Conduct HSM testing with synthetic/non-production data.
- Do not use MofN unless you can guarantee geographic, legislative or at the very least logical separation of the individual holders of the key’s shares.
- Keep in mind that the value of a cryptographic key stored inside the HSM is the total value of all the assets the cryptographic key protects.
The future of HSMs
There are currently several areas of interest in the area of applied cryptography where the HSM will continue to play a critical role.
- Confidential computing
- Blockchain
- Multi-Party Computation (privacy preserving encryption between disparate parties)
- Homomorphic encryption (privacy preserving encryption)
- Post-Quantum Cryptography (PQC)
There are currently a lot of unknowns surrounding some of these areas or practical issues and only time and a continuous research will tell the outcome. Probably the biggest concern to the current applied cryptography (e.g. PKI, document signing, TLS, storage encryption) is the PQC (Post-Quantum Cryptography).