The recent key-extraction attack on the SafeNet Luna HSM (CVE-2015-5464) led to a lot of discussion about HSM security. If an HSM has “one job”, it’s to make sure that keys that are marked “unextractable” really are “unextractable”.
However, the fact that this attack was first made public 12 years ago at the CHES 2003 conference (Reduced Key Space attack, slide 21) seems to have escaped attention. This is important not just because Jolyon Clulow deserves credit for the idea, but because there are many more attacks in his paper, and they apply to 100% compliant implementations of the PKCS#11 standard. That is to say, they don’t depend on bugs or errors in HSM firmware: if you follow the specification exactly, your device will have these vulnerabilities.
May have sharp edges
PKCS#11 is best thought of as a toolbox containing sharp tools. You can build secure protocols with it (more so now version 2.40 has updated the crypto), but you can also easily “cut yourself” by using the crypto in an insecure way. Moreover, if an attacker gets access to the PKCS#11 interface, he has a number of sharp tools available for extracting your keys.
Most modern HSMs allow you to disable certain functions and mechanisms to produce a safer, more “locked-down” interface. But working out whether you have turned off the right things is not easy. For example, the recent SafeNet HSM CVE concerns an attack where you extract a number of bits from a secret key to make a new key, and then subject the short key to a brute-force attack. By repeating this several times, you obtain the value of the original key. To prevent the attack, you could disable the
CKM_EXTRACT_KEY_FROM_KEY mechanism that is used in Clulow’s attack to make the short keys.
But at Cryptosense we’ve tested HSMs that admit several other ways to derive short keys. For example, with carefully-crafted parameters, the
CKM_CONCATENATE_BASE_AND_KEY mechanism can also be used to construct a series of derived keys that can be brute-forced to reveal the original key.
Cryptosense PKCS#11 Vulnerability Reports
To help HSM users navigate the maze of PKCS#11’s sharp tools and find a safe configuration for their application, we’ve added Vulnerability Reports to our PKCS#11 toolsuite. We cover all of the vulnerabilities in Clulow’s paper, as well as those in other academic work including Bortolozzo et al 2010, Bardou et al 2012, and several unpublished variants, all of which you can find in the latest Cryptosense PKCS#11 Security Whitepaper.
Here’s a sample vulnerability report for the Opencryptoki PKCS#11 software simulator. Vulnerabilities are divided up into categories that describe the keys that are affected. For example, some attacks affect only keys with the CKA_EXTRACTABLE attribute set to TRUE. On real HSMs, vulnerability 104 is where we often find problems, since a fully compliant implementation of the standard admits many variations of Clulow’s attack. Opencryptoki doesn’t support any unsafe key-derivation operations, so there are no attacks in this category.
In future posts we’ll describe some more of these vulnerabilities in more detail. We’ll talk about how to the testing works and how to use the report. In the meantime, if you’d like to get our tool running on your PKCS#11 interface, get in touch.
Keeping up with the CVEs
We’re currently in a golden age of applied cryptography research. As HSMs become more widely used in new environments, we’re seeing more attention being paid to the security of their PKCS#11 interfaces. There will be more vulnerabilities discovered and announced in the coming months. We’ll keep our Vulnerability Report engine updated to cover them all, giving you an easy way to make sure your HSM estate is providing you with the security it should.