One of the key security devices in a lot of organizations is an HSM – Hardware Security Module. All banks use it to store your debit card and credit card PINs. An HSM can be used to store any super-secret piece of information. Administration of the HSM is done via a custom client or CLI or directly on the physical panel of the HSM.
This article outlines an audit methodology for an HSM that extends the PCI Council’s HSM Security Requirements.
Besides the checks outlined in the PCI Council’s requirements, additional tests that can be carried out on the HSM are:
- Does the HSM expose any web-based GUI? If so, run standard battery of web server and web application attacks
- Does the HSM allow for API-driven custom encryption modules to be written and executed? If so, obtain copy of the documentation and write custom code that is capable of fuzzing the APIs provided in order to crash the HSM or destroy part of its functionality
- What physical or environmental situations are designed to trigger the tamper-detection and data-destruction actions in the HSM? If feasible, run such situation (increase in temperature, significant physical movement of the device, increase in humidity levels, etc.) to check if the HSM acts as it is supposed to
- How does the HSM obtain a firmware upgrade? Determine this mechanism via the documentation? Attempt to inject malicious or unauthorized firmware as an upgrade to the HSM and determine its response
- How is the HSM physically located – check the entire security setup around the HSM location
- How is the HSM logically isolated – check the network ACLs that prevent unauthorized access to the HSM over the network
- How is maintenance or servicing of the HSM done – determine this through the HSM documentation. Attempt to access the maintenance port or service and bruteforce the authentication mechanism. Does the HSM detect this attempt and trigger data destruction?
- Read the documentation to understand the physical tampering protection mechanisms in the HSM. If scope allows, then attempt to physically tamper with the device with the aim of triggering the protection mechanisms and then conclude whether the HSM triggered the necessary actions or not.
- Determine how sensitive functions are executed within the HSM – is there a mechanism to dump the running memory of the HSM (say by exploiting the Heartbleed vulnerability over an SSL channel to the HSM) and determine what data is exposed in the memory of the HSM?
- During power-up is there a key sequence that can put the HSM into maintenance of user mode? If so, attempt to trigger this by powering down and then powering up the device and feeding in the required key sequence. How does the HSM detect and resist tampering during this stage?
- Obtain a listing of all commands accepted by the HSM along with the parameters of these commands. Prepare a custom script to fuzz these commands and determine the HSM’s response to the illegal commands or illegal command parameters
- Sniff the network segment on which the HSM is connected and determine that no sensitive keys, PINs, or any other sensitive data is being sent over the network
- For all administrative activities, two-operator mechanisms or dual authentication mechanisms should be in place. From the HSM documentation obtain a listing of all such administrative actions, and attempt to execute these in an unauthorized fashion
- Testing of the cryptographic strength:
a. Determine the Random Number Generation algorithm. Test its strength by generating a sufficient quantity of random numbers, plotting them on a graph and ensuring there is sufficient entropy in the distribution of the numbers
b. Determine the public key algorithms used to encrypt the data as well as the protocols used to exchange keys with applications that interface with the HSM
c. Determine the symmetric key encryption algorithms used to encrypt data
d. Determine the hashing algorithms used to encrypt PINs or PIN blocks
e. Determine the minimum key sizes that are enforced by the HSM for all supported algorithms. Ensure they satisfy the Strong Cryptography requirements of the PCI DSS standard
f. HSM response to expired or retired keys
g. HSM response to keys that need to be destroyed
h. HSM mechanism to safeguard one key or keystore from others
i. HSM mechanism to secure key-encrypting-keys (KEKs)
- How is the outputting of any plain-text keys or PINs or PIN blocks prevented? Attempt to obtain such plain-text data and determine that the HSM prevents it
- How does the HSM implement application-level isolation – i.e. one application cannot access encrypted data or encryption keys belonging to another application?
- Determine that the HSM logging mechanisms are adequate and also tamper-proof
- If the HSM is a software device, then determine that the underlying operating system on which it is running has been fully hardened. Run standard battery of system vulnerability assessment and penetration testing scans and tests.
Further, upon reading the vendor’s product documentation you can build a number of additional tests as well.
K. K. Mookhey (CISA, CISSP) is the Founder & CEO of Network Intelligence (www.niiconsulting.com) as well as the Founder of The Institute of Information Security (www.iisecurity.in). He is an internationally well-regarded expert in the field of cybersecurity and privacy. He has published numerous articles, co-authored two books, and presented at Blackhat USA, OWASP Asia, ISACA, Interop, Nullcon and others.