On June 5 2019, security researchers Gabriel Campana and Jean-Baptiste Bédrune first presented a paper entitled ‘Everybody be cool, this is a robbery!’ In their paper, the researchers described attacking and extracting keys from a well-known vendor’s Hardware Security Module (HSM).
Blackhat 2019 sees the paper presented to a much larger international audience. This will no doubt renew interest in the subject area and raise further eyebrows.
The eye-catching title was adopted from the iconic opening scene in the movie Pulp Fiction. A frenzied Tim Roth (Pumpkin), utters the colorful phrase when robbing a diner. The situation does not end well for the Pumpkin and his partner largely due to the cool head of protagonist Samuel L. Jackson (Jules) who manages to gun the robbers down after a very tense dialogue that opens with the phrase ‘Yolanda be Cool!’ indicating that Jules is indeed an adversary to be reckoned with (the urban dictionary has a slightly more glorified view of the use of the phrase and describes him as ‘badass’).
Now what has all this got to do with HSMs and who is robbing whom and is this a ‘Yolanda be Cool!’ moment?
The research presented was significant and exciting in that it demonstrates an attack on a Hardware Security Module. HSM devices secure storage of secrets and keys and are used widely in the industry as ‘the’ ultimate root of trust for a wide variety of applications and systems that need assurance and accreditation that their cryptographic keys are secure.
The fallout from the well-received presentation was that industry was left with a lot of questions and suspicions around the use and development of HSMs. Scanning comments from customers and social media, including blogs, tweets and expert reports on the subject we found that the prevalent mood of HSM users and security experts was one of alarm, concern, suspicion, and more strongly, mistrust.
This is not quite a ‘Yolanda be Cool!’ moment as it does not end in such a dramatic fashion, but it does raise some important questions. We attempt to answer some of these from an Entrust Security perspective, specifically discussing the nShield HSM product set.
What is a HSM?
- A HSM is a specialized hardware system that performs cryptographic operations including key generation, key management, signing and encryption.
- HSMs allow for the separation of security as a concern from other application and business logic and provides a tightly controlled interface to the underlying functionality. This enables customers to concentrate on activities that are core to their business without having to run the gauntlet of building and assuring their own cryptographic modules.
- HSMs are focused on getting the implementation of cryptographic primitives right including the generation of high entropy random numbers and algorithm correctness. They are also focused on actively protecting cryptographic material and are designed to defend against a variety of attacks including attacks to the algorithms themselves, attacks to the physical system and the Operating System itself.
What is the value of having a HSM?
- HSMs are specialized systems that are created by experienced engineers in the field. Entrust Security engineers have over 700 man years of experience in developing such systems where security is of utmost importance. Customers benefit directly from this extensive experience when they use Entrust HSMs.
- HSMs meet with compliance requirements where the system implementations and their development environments are required to undergo extensive independent review and rigorous security testing. nShield HSMs are FIPS and Common Criteria certified.
Can still I trust a HSM?
- HSMs vendors’ best interests are served by making their systems secure and compliant with the standards that are required of them otherwise they would soon be out of business.
- However, there is a definite need to evolve into the 21st Century with regards to their design and implementation practices. Attackers are becoming more capable and there are more resources readily available for both casual and dedicated hackers. Entrust Security actively pursues improvement of security and capability of its products. The goal is to ultimately reduce risk to customers by making secure products with compliance being a byproduct.
How do we know that the nShield product is not vulnerable?
- We outlined this in detail in an earlier publication, ‘Entrust response to SSTIC HSM security vulnerability’, which is also available in hard copy form at Black Hat.
If the researchers fuzzed their code, they would have found the issues themselves.
What is fuzzing?
- Fuzzing is an automated way to send large amounts of data (possibly malformed mutated random data, hence the name 'fuzzing') to test if a program crashes because it mishandled malformed or malicious data. There are various types of fuzzers, some are smart enough to prioritize code coverage rather than simple random input, in order to test more of the program functionality. The idea is to monitor the program as it processes the input and watch for exceptions. These exceptions can potentially identify vulnerabilities in a program.
Do you fuzz test your code?
- Yes, this is a growing capability within Entrust Security. Fuzzing is currently carried out in an ad-hoc manner on new interfaces. Entrust Security first started fuzzing nShield interfaces in June 2015. The priority has been to test externally accessible interfaces such as the serial interface, file parsers, and unmarshalling structures, ASN decoders and cryptographic primitives such as multiplication of Elliptical Curve points using fuzzed keys. We are increasing coverage and are driving to incorporate fuzzing as standard continuous testing in the near future.
What other development practices do you follow that are important for making secure products?
- Common Criteria compliance requires review of the development lifecycle for the system. The entire product lifecycle is put under review, including the provenance of hardware and software components, the security of the development and manufacturing environments and specifically whether any of the product inventory can be maliciously tainted en route to release.
- All Entrust products are subjected to routine security analysis, penetration testing and security code reviews as part of their Secure Development Lifecycle.
- In addition to following best practices, Entrust places great emphasis on developing security-aware development teams and has a dedicated Security Office that puts product security first and foremost.
Will these kinds of attacks evolve and what does the future hold?
- The research carried out by Campana and Bédrune involved dedicated work and meticulous analysis to identify issues and flaws within a specific hardware system. The vulnerabilities they identified are applicable to any system especially those that are susceptible to memory safety issues and code integrity problems.
- In all likelihood more dedicated systematic testing will uncover further issues on HSMs (or any software system for that matter) agnostic of vendor. Attackers are becoming more sophisticated, capable and resourceful; toolkits and exploits are more readily available to explore and attack systems.
- We must accept the position that systems will be broken but the important questions are whether we can fail safely and are resilient enough to recover and how we continue to operate. Reducing the attack surface through careful design, secure architecture and following best secure development practices also helps significantly on the security journey.
- Demand for performance and scalability is pushing us to a service-oriented world and as such requires deployment environments to change. It gets more difficult to manage security in virtual environments and the cloud. Architectures must change and traditional security practices need to evolve.
- And what of compliance? Delays due to compliance will be even less tolerated in a world where Continuous Delivery may become the norm.
Attending Black Hat? Please visit Entrust at booth 1316. You can also follow us on Twitter, LinkedIn, and Facebook.