The benefits of HSM (Hardware Security Module) and other details
In my previous article,
https://medium.com/@pkiluke/the-importance-of-hsm-hardware-security-module-937130f873d9
I have described a very general introduction to HSM, outlined the risks associated with HSM, defined the existing HSM and HSM-like devices and described a few good practices when integrating and operating HSM.
In this article I would like to describe the benefits the HSMs bring and explain the difference between GP and payment HSMs.
In the following article I differentiate between,
- Service organization — these organizations buy HSM and integrate them into their cybersecurity infrastructure to enable and protect their business
- Vendor organization-these organizations manufacture HSM and sell them
What are the benefits of HSM?
It is important to remember that the core responsibility of HSM is to protect cryptographic keys and not the application data. The protection of the application data is merely a consequence of applying encryption key to an encryption algorithm within the boundary of the HSM (inside the HSM).
The benefits that I discuss here focus on service organizations that are deploying HSM on premise as opposed to cloud services such as HSM as a Service.
There are several benefits to using HSM, some benefits are more technical and some are less technical. It is important to choose the right argument when talking to different stakeholders.
Sovereignty means that the organization that controls the physical access to the complete HSM infrastructure has absolute control over the cryptographic keys stored therein and therefore absolute control over the confidentiality of the data protected by those keys. There are no SLAs or dependencies on any third parties.
Compliance means that the HSMs are manufactured and validated according to globally accepted standards such as ISO, ANSI, FIPS 140–2, CC, PCI, HIPAA, GDPR and others. Keep in mind there are different names for HSM in different contexts, for example SCD (Secure Cryptographic Device) under PCI and QSCD (Qualified Signature Creation Device), SSCD (Secure Signature Creation Device) under eIDAS. Just because the word HSM does not appear in the list of initial project requirements, does not mean you are not required to have it.
Isolation & separation means that the cryptographic keys and the cryptographic operations are physically separated from the rest of the organization’s infrastructure (server infrastructure, virtualization infrastructure) and furthermore, the cryptographic keys can be logically isolated from each other (per application, per tenant) within the HSM. This isolation & separation also applies to the organizational hierarchy, which means that by using HSM, you can separate the responsibilities and the burden of risk (to those accountable) between disparate teams.
Performance means that the HSM is optimized for the execution of computationally intensive cryptographic operations (symmetric, asymmetric; depending on the HSM type). Keep in mind that integrating HSM into the infrastructure degrades performance no matter how fast the encryption or decryption is.
Attack surface reduction means that HSM is manufactured and developed with the aim to protect the lifecycle of cryptographic keys and to reduce the exploitable methods of access to those cryptographic keys, nothing more and nothing less. It might seem counter-intuitive that buying extra hardware reduces overall attack surface, but because the data confidentiality of petabytes of sensitive data relies on a handful of cryptographic keys and because general-purpose computers are not made to enforce secure lifecycle of cryptographic keys, it does provide a significant improvment to the overall security to the organization.
Tamper-resistant means that HSM is manufactured to detect the attempts to cause disclosure of sensitive data (data breach) and to resist it (tamper-resistant) by protecting the confidentiality at the expense of availability. In other words, the HSM will delete the cryptographic keys inside the HSM when it detects an attempt at data breach.
Audit trail means that HSM keeps a detailed and secure log of any activity performed with the HSM. In the real world that means that when the service organizational comes under the scrutiny of audit or legal proceeding accompanying a data breach investigation, the accountable stakeholders have a proof of due care and due dilligence.
What is the difference between GP HSM and payment HSM?
In the real world, there are many HSM models and criteria how to categorize them,
- By server connectivity — network-based, PCI and USB
- By performance — vendor-specific
- By programmability — some HSMs allow the service organization to upload and execute their own code or firmware while some HSMs don’t
- By authentication method — password and multi-factor (typically USB tokens or smartcards)
- By usage — GP HSM (general purpose) and payment HSM
The general purpose HSM are,
- Optimized for asymmetric cryptography
- Do not compact multi-key operations
- Dual control is not enforced (optional)
- Cryptographic commands are more straightforward — encrypt, decrypt, sign, verify
- Unencrypted sensitive data can be returned to the application
The payment HSM (also called transaction HSM) are,
- Optimized for symmetric cryptography
- Compact multi-key operations
- Cryptographic commands are more complex and strict as mandated by the payment industry standards — decrypt and re-encrypt inside HSM in one operation
- Dual control is enforced (mandatory)
- Unencrypted sensitive data is not allowed to be returned to the application
- Understands input and output format (format-preserving encryption)
To explain the difference between general purpose HSM and a payment HSM, here is a simple example of how symmetric cryptography with multiple keys works.
Scenario: You go shopping after work to your local supermarket and you pay by swiping your card and entering a PIN.
Now, payment transactions consist of many participants end-to-end (shopper, merchant, payment providers, card providers, banks etc…) and they depend on symmetric cryptography to secure the transaction. Because there are many participants and because the payment industry is regulated so that not only the cryptographic keys but also the payment data are protected (PIN, CID and others), specific HSM are manufactured to ensure compliance with these regulations.
In the example below, participant 1 = local supermarket, participant 2 = payment provider (Apple Pay, Paypal), participant n (other participants — banks, Visa/Mastercard/AmEx, etc…)
- participant n shares a symmetric key with participant n+1
Therefore, starting with the participant 2, there are always 2 different symmetric keys, one key is used to decrypt the data received from the previous participant in the payment trasaction chain and the other key is used to encrypt data sent to the next participant in the payment chain.
With a general purpose HSM, this multi-key (2 key) operation would expose unencrypted data to the participant who holds the two keys, because the general purpose HSM use very straightforward cryptographic operations
- decrypt data in the HSM using red key
- send me back the unenrypted data (application sees the unencrypted payment data =BAD THING)
- encrypt data in the HSM using blue key
- send me back the encrypted data
The payment HSM uses more compact and stricter cryptographic operations and concerns itself not only with the security of the cryptographic keys but also the payment data.
- decrypt data using red key, re-encrypt it with the blue key, do it all in the HSM and then send me the encrypted result
Because the payment HSM is capable of format-preserving encryption, the intermediary participant (payment service provider, bank) can use these intermediary values in tokenization and other solutions without disclosing any sensitive data.
