Lessons Learned from Recently-Discovered Major Vulnerabilities in Hardware Security Modules
Hardware Security Modules (HSMs) are physical boxes that carry out cryptographic operations, and never reveal the keys inside. They are designed to have very high security, and as such, are used to protect an organization’s most valuable cryptographic keys. Due to their long history, HSMs are also widely trusted by the most security conscious in industry. Despite the above, security researchers from Ledger will show how they completely broke a popular HSM at the upcoming BlackHat USA 2019 conference. This news is making waves, since this is the first time we have heard a public announcement of such a powerful attack. How Ledger Hacked an HSM A technical summary of what will be presented, as well as a very blatant hint as to who the vendor is (currently not published), appears in the description here by the Cryptosense team. The bottom line is that the attackers were able to upload arbitrary (unsigned) firmware of their liking, and then use this to remotely extract all keys and secrets from the HSM. A lot of hard (and top notch) work went into finding the vulnerability, but utilizing it is very easy. It is also important to note that although the vendor has released a patch for the vulnerability, any HSM that was already compromised is actually unpatchable. This is because the malicious firmware installed by the attackers can ignore all updates; even worse, it can accept the update and behave as expected, while keeping a backdoor open to attackers. Thus, existing HSMs may actually be vulnerable, even if patched. The Software-Security Problems with Hardware Due to the severity of the above incident, it is important to understand its ramifications going forward, and how it could have happened. Before I start, I want to stress that bugs and software vulnerability exist everywhere, even when vendors follow all of the best practices. As such, I don’t think that there’s any value or justice in “trashing” the vendor. Rather, I believe that the problem lies with the entire HSM model, as we have it today. In particular, HSM software is among the least transparent (for example, vendors do not allow any independent review), and the effort involved in carrying out independent testing on it is huge. This is bad for security. Furthermore, since software vulnerabilities appear everywhere, one needs to factor in the cost and pain of updating when such vulnerabilities are discovered. In software, this is typically easy. However, in hardware, updating firmware is a painful process no matter what. In this specific example, it is even worse. As stated above – any compromised HSM is not patchable at all. This is a problem with hardware that does not exist in software solutions. Physical Protections Provided by Hardware are Irrelevant A second point that is of importance to note here is that HSMs were borne of the need for physical protection, and this is where vendors have invested the most effort. This makes sense for machines that are in locations that are not physically secured. However, in today’s modern computing environments (public and private clouds, data centers with high physical security), this is solving the wrong problem. FIPS 140-2, which is the primary certification for cryptographic modules including HSMs, has different levels of security. Levels 1 and 2 can be met by software solutions only, but levels 3 and 4 require physical security. The industry standard in many cases is level 3 and above. However, the only difference between level 2 and above is the addition of physical security, which says nothing about the security of the software itself. In the recent attack by Ledger researchers on HSMs, the vulnerability was in the software and the HSM being a high FIPS 140-2 level says nothing about this. Whenever the module can be placed in an environment that is already physically secure (like a cloud or protected data center), the physical protections provided by HSMs are actually irrelevant. Combined with what we discussed above, the physical hardware protections become an obstacle to security, rather than a security feature. (We stress that this is not the case when the HSM is situated somewhere that can be accessed physically by an attacker.) Key Takeaways: Transparency & The Ability to Update Vulnerabilities In summary, this recent news should be a catalyst for industry to review its security and threat models. If hardware security is not the problem, then legacy HSMs may not be the best solution (unless there’s an external regulatory requirement for them). In any case, two properties that should not be underestimated in any security solution are transparency (and independent auditing) and the ability and cost to update and fix discovered vulnerabilities.