Securing Keys with HSMs (Hardware Secure Module)
HSMs (Hardware Secure Modules) are specialized hardware devices that are tamper proof and used to store cryptographic keys. The rule is that all secret keys forever stay in the HSM device.
When we need to use them we do the operation in the secure execution environment of the HSM.
Major HSM Providers
HSM providers need to go through a certification process with the NIST. Some major providers that have been around for a while are Gemalto (owned by Thales, SafeNet (owned by Gemalto), Thales, nCipher (owned by EnTrust), FutureX, and Utimaco. These solutions have a costly overhead a Gemalto HSM can be ~$29,000, Thales can be ~$9,500, and Utimaco can be ~$15,000. In addition, you need to store these HSM devices in a secure location which can cost an arm and a leg or even more.
Someone doesn't need the high overhead to use an HSM, you can easily lease a cloud provider's HSM to get the job done. In recent years cloud providers have also become major contenders like AWS, Google, and Azure, providing cloud HSMs. There isn’t an overhead cost but a cloud cost to using cloud HSMs that’s dependent on how long and how you use them, for example, AWS costs ~$1,058 a month (1 HSM x 730 hours in a month x 1.45 USD = 1,058.50 USD). Another major difference with cloud HSM providers is that the physical devices sit at the cloud provider's sites, not yours. You would most likely use the services (Key Management Services — KMS) provided by the cloud provider to interact with the HSM devices on their site.
When finding an HSM provider, please validate the vendor's certificate issued by NIST using the site below:
HSM Use Cases
PKI
All Certification Authorities (CAs) are required to use HSMs. Certificate Authorities use HSM devices to sign certificates, so apps can trust that the certificate issued is legitimate and blessed by the CA.
We need HSMs to sign the certificates to prevent a bad actor from using a hijacked cert. If a hacker gets a hold of the client certificate, they won't be able to authenticate themselves with a signature because the private key in the HSM can only sign the certificate.
Below are the CA/B Forum Baseline requirements:
The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140 level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.
Debit Card Pins for ATMs
HSMs are used to secure debit card pins, banks can't have pins out in the open because someone will use that to rob customers, so they use HSM devices to verify the PIN.
Securing Cryptocurrencies
With the emergence of cryptocurrencies, HSMs have become increasingly popular. Cryptocurrencies are essentially public and private key pairs, and since HSMs are built to secure keys, they are ideal for the job.
In the crypto space, HSMs are the signers for transactions. Since the private key always sits inside the HSM, the transaction is sent to the HSM to be signed.
Below is how Kaleido uses either Azure, AWS, or HashiCorp cloud HSM to sign off on a transaction.
What's inside an HSM?
HSMs devices are usually available as PCIe cards and Network Attached Appliances. The PCIe card can be installed into a server, and a Network Attached Appliance is its hardware.
Below is an image of an HSM PCIe device hosted on a Linux box. Usually, this Linux server runs on an Intel E5500 server, has 4 GBs of RAM, and a hard drive of 500 GBs.
The below image is a PCIe HSM; this PCIe card sits on the server and is where all the magic happens. It has sensors that can detect changes in temperate, voltage, power supply, and the tampering of the protection foil. A physical protection layer and a battery helps erase the contents of the memory in case of a breach when the HSM is powered off.
What's in a PCIe HSM?
- A Texas Instruments TMS320C64x DSP that performs cryptographic operations.
- True Random Number Generator (TRNG) and a Deterministic Random Bit Generator (DRBG) to help it provide entropy
- A Key-RAM which contains the Device Key that encrypts all keys
What is a Device Key? The key to unlocking all keys.
The device key is created when the HSM is put into operation. Most importantly, it encrypts all the cryptographic keys and security parameters. Keys in the HSMs cannot be extracted, exported, imported, or manipulated.
Master Backup Keys (MBK)
Master backup keys, as the name says, back up the keys. They are 256-bit AES keys used to encrypt backups and can be split into many shares using an n out of m scheme.
Keys Supported
Most HSM devices support RSA, DSA, ECDSA (NIST and Brainpool
curves), DH, ECDH, AES, DES, 3DES, SHA1, SHA2, SHA3, RIPEMD, etc.
PKCS#11 — Crytoki
PKCS#11 is a Cryptographic Token Interface Standard, also known as Crytoki, and has a suite of cryptographic services for encryption, decryption, signature generation, signature verification, and key storage.
PKCS#11 is a standard for interoperability between cryptographic hardware devices by abstracting device differences with unified API functions. Not all devices have to use all the PKCS#11 functions, and they can have additional functions as long as they don't conflict with PKCS#11.
Based on this standard, companies have created their functions. Below is an example of AWS's function to generate an AES key:
Objects used in PKCS#11
There are three types of objects used with PKCS#11, keys (secret, public, and private), certificates, and data (DSA/ECDSA parameters, etc.). Cryptoki doesn't manipulate these objects directly. Instead, it uses the object's handles.
Below are the attributes of a signing key object in PKCS#11:
Every object gets access to a token, and inside a token, they get a slot ("plug-in position"). The slot contains cryptographic objects and protects against unauthorized access. If a user has access to a token, they only have access to the object associated with that token.
Storage
The persistent data is stored in a flash memory covered in epoxy resin on the PCIe card. It contains a Linux image, custom modules, logs, and the PKCS#11 objects. The flash memory is partitioned, and the PKCS#11 objects are stored separately. The encryption key is stored in external memory.
Strengths with HSMs
HSMs are resilient devices that can secure your keys in extreme weather conditions, fires, or from someone that wants to tamper with your device. Because they're hardware solutions and have the highest security grade, there are not many solutions with a NIST FIPS 130 level 2 (some have higher levels in specific areas, such as physical security). Below is a snapshot of the criteria that tells us what FIPS level an HSM qualifies as.
The other positive is that HSMs have been around for decades. So there is a wealth of knowledge on HSM best practices and several research studies around the securities of HSMs.
Vulnerabilities with HSMs
Despite all the strengths of HSMs, nothing is unbreakable.
SafeNet HSM key-extraction vulnerability
On January 30th, 2015, Gemini was evaluating the Luna G5 HSM used by AWS when they came across a vulnerability that allowed the extraction of secret keys. The problem was in Luna's PCIe card and network appliance used by AWS's cloud HSM.
Safenet's problem was that they used several PKCS#11 functions that were not reliable, especially the extract-key-from-key (key derivation) and XOR-base-and-data functions.
Extract Key from Key (Key Derivation)
Key derivation functions create a key as a function of another key. An example is BIP-32, where a Bitcoin HD wallet comprises a family of addresses derived from a single seed phrase.
This scheme generates a new key by taking a contiguous sequence of bits at an offset and the length from the existing key; it basically extracts a substring.
Attack!
We first start at the most-significant bit and extract 2 bytes. Now we can HMAC a chosen message using the derived key. Given this primitive, the attack can be made with brute force, we can uncover the short key by trying all possibilities against known message/HMAC pairs.
Now we can repeat, derive another short-key at a different offset, brute-force using a chosen message attack, then repeat until all key bytes are recovered. Fully automated, this requires a couple of seconds with Luna G5, much less time with the more powerful SA7000 used in CloudHSM.
Elliptic Curve Keys
This attack works against AES, generic HMAC secret, and elliptic-curve private keys but not RSA, plain DSA, and Diffie Hellman.
For elliptic-curve keys, the byte array truncated is the secret scalar part of the key. An example of the "secret" component for a Bitcoin ECDSA key is a discrete logarithm in secp256k1. Internally those discrete logarithms are just stored as a 32-byte scalar value, and the extract-key-from-key scheme can be used to successively reveal chunks of that scalar value.
More on the vulnerability can be found below:
Below is the announcement by Gemini on the vulnerability:
Ledger's Analysis of HSM Vulnerabilities
How does Ledger use HSMs?
Ledger, the hardware wallet, uses HSMs to ensure the ledger devices received by customers are legitimate. Ledger has to do this because there have been several hacks where false devices were sent out to customers to steal their cryptocurrencies.
The process of validating the devices is called attestation. Every time a Ledger device is set up or updated, a server connected to the HSM sends a challenge (from a randomly generated number from the HSM) to the customer's device to prove its legitimacy. If the server can verify the signature, it's valid.
Ledger's Research on HSM Vulnerabilities (Everybody be cool this is a robbery)
On August 8th, 2019, Ledger presented at the USA BlackHat conference on vulnerabilities with HSM devices. Through their research, they discovered 14 memory corruption bug vulnerabilities, the exploits allowed them to execute their code remotely that eventually reveal every secret key in the device.
The HSM device they used for this research allowed the developers to develop custom modules that could be executed on the HSM, so they created a module that installed a custom shell and a debugger. To automate their research, they used a fuzzer that sent mutated messages from the host to the HSM. The mutated messages caused kernel module crashes and out-of-memory issues that led to HSM DDoS, so they had to filter the messages.
One of the bugs they found was very close to Heartbleed.
What is Heartbleed?
Heartbleed is a buffer over-read issue where additional info was leaked in a heartbeat message, hence the name heartbleed.
A heartbeat requests requires the command below, where the bp is the place it’s copying to, pl is where it’s copied from, and the payload is the length of the data being copied. The payload represents a memory length of a payload and is usually a 16-bit integer.
memcpy(bp, pl, payload);Before providing the information, there should be a bounds check that validates the input request and returns the exact payload length requested. If the bound checks aren’t done the heart beat mechanism allocates a memory buffer without doing a validation check.
A memory buffer is a temporary storage for data in transit and can contain sensitive and financial information, credentials, cookies, etc. If it’s improperly allocated it can expose sensitive data in a heartbeat message.
Below is the HSM module code to set an attribute value. This is where they found a heartbleed-like bug. Notice below that the size passed to malloc and the size passed to memcpy is different. The different sizes would cause some part of the data that's copied to the value of the attribute not to get fully initialized.
With this vulnerability, they were able to expose the memory buffer of the HSM, the output below shows the leaked password of the administrator.
More vulnerabilities are discussed in the presentation, and I highly recommend you check Ledger's analysis of HSM vulnerabilities presented at BlackHat.
https://i.blackhat.com/USA-19/Thursday/us-19-Campana-Everybody-Be-Cool-This-Is-A-Robbery.pdf
The Moral of the Story
HSM devices are highly secure and are used worldwide by some of the biggest institutions today. But the world is evolving, hackers are getting smarter, and eventually, HSMs will no longer be unbreakable.
We need to stop seeing HSMs as the solution for key management and more like tools to manage keys. In the future, organizations will need to develop layered approaches and processes to better secure their HSM devices.
If you like the post, then you can buy me coffee, thank you in advance!
Obsessed? Dive Deeper
Cloud HSM Best Practices — Google
Open Project to Make HSMs Affordable — CrypTech Alpha
HSM Use Cases — Cryptomathic
Definitive Guide to Encryption Key Management Fundamentals — Townsend Security
Presentation on Reversing and Exploiting a FIPS 140–2 HSM Firmware — Recon BRX 2017 (Fotis Loukos)
Awesome PKI
New to trading? Try crypto trading bots or copy trading
