As well as treating applications in Java and .NET, Cryptosense Analyzer can also check the cryptographic security of PKCS#11 implementations in HSMs and elsewhere. We recently added a few of improvements requested by our users.
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.
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.
The latest firmware update (v11.72) for the Thales eSecurity-nCipher net HSM includes a fix for a security issue found by the Cryptosense PKCS#11 compliance tester.
While using our software to test one of our clients’ HSMs, we discovered a bug that allowed an innocent-looking PKCS#11 command to set all the permission attributes on a private key to FALSE. Since these attributes include CKA_MODIFIABLE, this is a permanent change, and since CKA_EXTRACTABLE is set to false, the key can’t be exported and copied. All the cryptographic usage flags such as CKA_SIGN and CKA_DECRYPT are also set to FALSE, rendering the key unusable for any operation.
Since these devices are often used, for example, by Certification Authorities or in other similar signing applications where availability is critical, our clients considered this a serious issue, so we signalled it to Thales who included a fix in their most recent update. We’d recommend all Thales-nCipher HSM users to install the fix as soon as possible.
Over the next few weeks and months, we’ll be featuring more highlights of the results from our compliance tester on the blog . In the meantime, if you’d like to try a demo of the Analyzer, get in touch.
Update March 2018
Since we wrote this post our compliance criteria have been extended to over 100 covering PKCS#11 v2.40 and used to find a host of issues with live HSMs.
Recently we’ve been trying out our PKCS#11 compliance tester on a number of open-source PKCS#11 implementations. We’ll be publishing the results here over the next few weeks, as well as sending the reports from our tools to the project developers. First up: Opencryptoki and its PKCS#11 software token.
Hardware Security Modules (HSMs) are tamper-resistant special-purpose computers that protect the most sensitive cryptographic key material in an organisation. They are used for security-critical applications such as electronic payment, PKI, inter-bank transfers, and PIN management in the cash machine network. At Cryptosense we produce software to audit the application programme interfaces (APIs) of these devices and find security flaws. A natural question is: do these systems really ever suffer breaches? Don’t attacks happen elsewhere?
In this article, we’ll look at two major breaches of critical applications secured by HSMs for which the details have become more or less public, the Dutch Certification Authority (CA) DigiNotar, and the payment processor RBS Worldpay.
Continue reading →
Some standards come with compliance criteria built in – you can’t say you’ve implemented the standard until your code can pass the tests. With PKCS#11, a 407-page standard specifying the most widely used API in cryptographic hardware, there are no such tests. So how can a would-be PKCS#11 user discriminate between a good implementation of the API and a bad one? And how can a manufacturer find compliance bugs and then demonstrate the quality of their product?
Since I joined Cryptosense in March, I’ve been working on a new implementation of the testing framework that we use to reverse-engineer cryptographic APIs. Last Friday, I gave a talk at the 7th Analysis of Security APIs workshop in Vienna where I explained some of the main ideas of this work. Here’s a high-level summary of my presentation.
When I arrived at Cryptosense I could see there had already been a huge investment in advancing the state of the art in automatic analysis of an API such as PKCS#11. The challenge was to generalise this tool to be able to test other crypto APIs in a scalable way, without reproducing all the effort.
This post follows on from the previous one describing the range of RSA mechanisms supported in PKCS#11, and their security properties (or lack of). One big change to the standard in the upcoming version 2.40 is a separation of the mechanisms in to “Historic” and “Current” mechanisms.
The standard doesn’t say anything specific about the security of the mechanisms in each, but one might conclude that the Historic category will include all the broken mechanisms and the Current list those still believed to be secure.
This is not the case.
Continue reading →