It was interesting to note in PCI DSS v3.0, when conducting one of our first v3.0 assessments, that section 3.5.2 refers to a host security module, with regards to protecting data encrypting keys:
| 3.5.2 Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:ï‚· Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key
ï‚· Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device) ï‚· As at least two full-length key components or key shares, in accordance with an industry-accepted method
|
I thought it must have been a typo, as the common industry interpretation of HSM is of course a Hardware Security Module. Â So what was all this new fangled technology about? Â What exactly is a Host Security Module and when should it be used instead of a Hardware Security Module?
The PCI SSC had gone to considerable effort to release guidance notes on Hardware Security Modules, find out more by clicking here, and the certification of such Hardware Security Modules for adherence against the PCI PTS standard. Â A search on the www.pcissc.org website shows plenty of references to Hardware Security Modules (HSMs), but zero hits on “host security module”.
The PCI SSC explained to me that it was not an error, and this description was intended, to follow with a more detailed explanation in the Glossary.
But in short, a Host Security Module is exactly the same as a Hardware Security Module. Â Quite why the PCI SSC decides to bring upon the world another name for the same thing is beyond me – the standard is complex enough without having to learn new acronyms.
In the past, there has been strong lobbying by HSM vendors to mandate the use of certified HSMs in a PCI DSS Compliant environment, but that never quite took off as in fairness, it shows a bit of a vendor bias and key management can be handled perfectly well in most environments without investing in a tamperproof banking-grade appliance.
Whilst I'm on subject, let's dissect 3.5.2 a bit more, as some other parts of it have confused the community in the past. Â The control in essence says:
* Data encryption keys (DEKs) MUST be encrypted with a key encryption key (KEK), unless they are Public Keys, if you intend to store them anywhere.
* The use of a HSM is OPTIONAL, but can be helpful.
* If you get stuck, then apply split knowledge, so that it takes at least two people to reconstruct the key, each person entering their key half in order to construct the DEK. Â Simple, effective, but relies on these two people being available 24/7.
At the end of the day, don't delve too much into this control and it's interpretation, after all, the application or database that uses the DEK will ultimately need to load said DEK into memory space in order to encrypt/decrypt. Â If the DEK's in a HSM, then it may well be 100% secure at rest, but think about what this DEK is and where it needs to go. Â Minimize locations where the DEK is used and where encryption/decryption happens. Â Consider worst case scenarios, such as memory parsing malware. Â If malware does end up on your encryption/decryption system, then make sure it cannot exfiltrate. Â Your encryption/decryption must NOT have internet access (even for anti-virus or software updates).
With any luck, the PCI SSC will back down and just put in hardware security module instead, so the phrase host security module just goes away, forever, and doesn't start lining QSA's pockets whom are having to answer this question and clarify on behalf of bemused merchants, banks and service providers.  🙂