listen to this article:
Ever wondered how it’s possible to hack a hardware security module (HSM)? We recently had the opportunity to chat with Dr. Fotis Louko￼s, researcher at the Aristotle University of Thessaloniki and Director of Security Architecture at SSL Corp. We also spoke to him about standardization testing for HSMs, and how all of us in the security community could benefit from independent testing of HSMs.
In our conversation, Dr. Louko￼s walked us through how he was able to hack an Utimaco (FIPS 140-2 Level 3 Validated) Hardware Security Module (HSM). I won’t get into the nitty gritty details (for that you can watch his presentation) but in a nutshell:
- He succeeded to exfiltrate information from internal databases including the MBK (Master Backup Keys) database, which should be unexportable based on the security model of the HSM.
- The MBK is used to encrypt keys that are extremely backed, meaning that if you can your hands on the MBK table, ￼you can decipher all the keys of the HSM, given that you can access a backup copy of the keys.
- He responsibly disclosed this vulnerability to Utimaco, and it took them a mere 7 months to fix it.
We’ll quickly dive into the takeaways from our discussion with Dr. Loukos further in this post, More information about HSMs, how they work and what makes them trustworthy can be found here.
Are HSMs Foolproof?
The answer is an astounding no.
Our interview with Dr. Louko￼s was actually very timely, since it was just reported how two researchers from were able to take full control of a HSM that is used in major banks and large cloud service providers. Gabriel Campana and Jean-Baptiste Bédrune from wallet maker Ledger discovered vulnerabilities which allow a remote unauthenticated attacker to take full control of an HSM and gain access to keys and secrets stored on it. You can read the analysis of this specific incident by our CEO and co-founder, Prof. Yehuda Lindell here. What is most concerning about this discovery is the acute problem of having critical security infrastructure components reliant on dedicated hardware that is often very difficult or sometimes even impossible to patch in a timely manner, leaving critical vulnerabilities open for very long time, in equipment that is supposed to protect high value assets.
There have been other HSM breaches along the years including:
- In July 2015, a vulnerability was found in hardware security modules (HSMs) manufactured by SafeNet. The vulnerability, a software design flaw in SafeNet’s Luna G5 devices which was discovered by the Chief Security Officer of Gemini, Cem Paya while testing it. The software design flaw could disclose both public and private keys.
- In July 2011, Certificate Authority DigiNotar was compromised by an attacker who gained access to its systems and created fake certificates for sites such as www.google.com, mail.yahoo.com, login.live.com, etc. giving hacker(s) the capability of sniffing into traffic of thousands of users through man-in-the-middle attacks. The hacker used advanced attack methods to penetrate the HSM (Hardware Security Module) with only one single open port, showing that even proprietary software/hardware such as HSM are not out of reach of determined hackers. DigiNotar eventually went bankrupt as a result of the attack.
- In November 2008, attackers got a hold of more than 40 pairs of PIN codes and debit card account numbers of RBS Worldpay customers. It’s possible that the attackers were able to access the keys that protect the PIN blocks due to poor configuration of the HSM in which they were stored, or vulnerabilities created from having bloated functions. ￼
What Can We Learn from Compromised HSMs
Our interview with Dr. Louko￼s can help us glean some interesting insights about HSMs, and raise questions about how we may need to reframe our thinking regarding HSMs for the future.
- HSMs have been trusted to protect cryptographic material since their introduction to the market, but they do pose security concerns that we need to be aware of moving forward.￼
- Security Risks: There will always be bugs, and that is just the nature of the game, however we tend to have a flawed perception that HSMs provide “bulletproof” security. Security risks associated with HSM hardware and software include software vulnerabilities written during code development–buffer overflows, stack smashing attacks, etc—all of these are attack vectors for code injection attacks. A sophisticated enough attacker, who takes into account all the possible sequences of commands and parameters of communications with an HSM, can break into it.
- Physical Protection: HSMs are known for their ability to protect cryptographic material physically. However, most attacks occur on networks, or in the cloud—not in a physical setting, and thus the hardware component of the HSM may or may not be relevant in actually preventing modern attacks.
- Transparency: While standardization testing by NIST (or other organizations) is important, independent security researchers need to be able to “poke and prod” HSMs for vulnerabilities with HSM vendors offering a vulnerability disclosure program with monetary compensation. This is not the case now, and thus it takes a very long time to find and fix vulnerabilities because the system does not allow for it.
- Ability to Update Firmware: Updating software vulnerabilities in and of itself can be a painful and time-consuming process. In the case of Ledger, the HSM that was compromised is actually unpatchable.
*Thanks to Dr. Loukos on his contribution to this blog post.