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.
Hardware Security Modules (HSMs) are generally viewed as expensive and painful to maintain. It’s not surprising that a lot of HSM users are looking for a cloud-based solution that would allow them to hand over maintenance to a third party and move to an opex instead of capex model (i.e. rent the HSM instead of buying it).
At the same time, companies looking to migrate their more complex business-critical applications are finding that Cloud Service Provider (CSP) key management APIs (e.g. AWS KMS, GCP KMS, and Azure keyvault as covered in an earlier post) often don’t offer the cryptographic flexibility they need to migrate securely and in compliance.
Responding to these market forces, a new wave of cloud-hosted HSMs is arriving. Equipped with standard APIs like PKCS#11, they offer the promise of flexible crypto services while keeping keys secure from cloud application compromise.
In collaboration with the University of Venice Ca’ Foscari, we’ve been researching the protocols smartcards and authentication tokens use to communicate underneath the PKCS#11 API that’s exposed to applications. These protocols tend to be quite different for each device.
Results include sensitive cryptographic keys in the clear, PINs in the clear or easily reversible, stateless protocols that allow easy injection of commands and restrictions on key use enforced at the PKCS#11 (driver) level that are trivially bypassed at the APDU level.
Our findings will be presented in September at the 19th International Symposium on Research in Attacks, Intrusions and Defences – RAID 2016.
The research was carried out some time ago, and manufacturers concerned were all informed well in advance of disclosure. We’ll continue to investigate more of the devices our customers use.
In the standard API for HSMs and other cryptographic hardware, PKCS#11, key-wrapping refers to the process of encrypting one key stored in hardware with another in order to send the first key somewhere else in a secure way. This operation has been the source of a whole series of security vulnerabilities, in particular because the encryption modes are often vulnerable to padding oracle attacks.
In PKCS#11 v2.40, new authenticated encryption modes were introduced. Properly implemented, these modes are secure against padding oracle attacks. This is good news, but unfortunately AES-GCM and AES-CCM, the two new modes, introduce a new security problem.
The two-time pad
Both AES-GCM and AES-CCM are what is known as counter modes. That means the encryption part of their operation works by using the AES block cipher to calculate a keystream that will be XORed against the plaintext. Roughly speaking, the first block of the keystream is obtained by encrypting an initialisation vector (IV). The second block of the stream is obtained by increasing the IV by 1 and encrypting again. This is repeated until the keystream is as long as the plaintext.
Such modes have several advantages: the security proof for the confidentiality part is quite direct, and encryption and decryption can be parallelized easily. However, in PKCS#11, the IV is supplied as a parameter by the calling application. That means there is nothing to stop a compromised application controlled by an attacker from using the same IV twice.
This opens up a whole series of attacks. For example, suppose the attacker wants to obtain the value of a wrapped secret key s. Suppose the ciphertext c containing the encryption of s was obtained at a certain HSM by calling the PKCS#11 command C_WrapKey using either CCM or GCM mode, and suppose the attacker obtains access to the HSM. The attack works even if we assume k is safely stored inside the HSM and properly protected by its permission attributes, i.e. not extractable, and the key s is no longer even present on this HSM.
To obtain s, the attacker can first store a known key in the HSM, using the C_CreateObject command that imports a cleartext value as a key. For simplicity, suppose he imports a string of 0s as the key. Then he asks the HSM to encrypt the string of 0s with the key k using C_WrapKey, and gives the same IV as was used in the ciphertext c, obtaining c’. Finally he XORs c and c’ to obtain the plaintext value of s.
Why does this work? Because if ks is the keystream generated by the IV and the key k, then c XOR c’ is equal to ks XOR s XOR ks XOR 0. If you XOR any x with 0 you get x, and if you XOR any x with itself you get 0. So ks XOR s XOR ks XOR 0 = s XOR ks XOR ks = s.
This isn’t the first time we’ve seen this problem: the YubiHSM has exactly the same issue.
Even if the attacker can’t use C_CreateObject (for example if it is disabled on this HSM), there are many other ways to import a known key onto an HSM, including taking advantage of padding oracle attacks on insecure unwrap modes, or incorrectly set permissions that allow encryption as well as unwrapping.
The solution is to force the HSM itself to generate the IVs for wrapping keys under CCM or GCM, and to make sure the wrapping keys can’t be used for any other functions using the existing permission attributes.
Here at Cryptosense we’re working in a proposal for key wrapping for PKCS#11 v3.0 that will include this and other features to allows keys to be wrapped along with their attributes, to avoid another family of attacks where keys are unwrapped with different permissions from when they were wrapped. We’ll keep you updated with news of that here, though you can also follow discussions on the PKCS#11 TC site (and the mailing list is public).
Meanwhile, to find out more about PKCS#11 security, start with our free whitepaper.
Cryptosense will be at the RSA Conference in San Francisco February 29-March 4. We’ll have a stand on the PKCS#11 booth (South Expo #821) where we’ll be running demos of our Security Tools. Find out how we detect vulnerabilities in PKCS#11 HSM configurations with our smart fuzzing tools and then apply them to the keys your application uses to check their security in the event of a breach.
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.
When choosing an HSM or Smartcard to act as crypto provider for a PKCS#11 application, it’s important that the provider actually supports the specific cryptographic algorithms (or “mechanisms” in PKCS#11 terminology) required for the commands that the application will use. What’s more, if the device offers insecure mechanisms, an attacker might make use of them to compromise data. There are 224 mechanisms and 54 commands in v2.20 of the standard. How can I find out which ones a specific device implements?
To help with this problem we’ve added a functionality summary to the PKCS#11 compliance reports produced by our software. The output is designed to look like the “Mechanisms vs Functions” table (table 34 in v2.20) of the standard which shows which mechanisms are considered valid for each command. In our table, a cross indicates that we were able to use the mechanism in that row successfully for the command in that column.
Updated March 2018
Functionality reports now feature in the stats output of Cryptosense Analyzer for all APIs, including PKCS#11. Try it out on your device.
In April 2015, following its transfer to OASIS, the PKCS#11 standard for device crypto APIs got its first official update in ten years. There is always some lag time between a new standard and vendor adoption. Here are five good reasons you should be nagging your crypto hardware vendor to upgrade:
- Authenticated Encryption
- MACs that are secure for variable-length messages
- PBKDF2 with SHA-512
- Less legacy stuff
One thing we learned since the last version of PKCS#11 is that Authenticated Encryption (AE) is not just a fancy crypto nicety, it’s a security necessity for almost any serious application. While you can build your own authenticated encryption from old PKCS#11 modes (here is one interesting way to do it), it’s simpler and more error-resistant to use a dedicated AE mode. PKCS#11 v2.40 contains two of these, GCM (as used, for example, in TLS) and CCM (as used in many embedded devices).
The original PKCS#11 contained MAC modes that were used in the financial sector in applications where every message was a fixed-length block. Unfortunately, these modes give no guarantee of security if message length is variable. PKCS#11 v2.40 contains mechanisms like CMAC which are secure in the variable-length setting.
Password-based key derivation functions (PBKDFs) are often used to store passwords in a secure way by hashing and salting them. The idea of a good PBKDF is that it requires enough computational resource to calculate that a realistic adversary will not be able to brute-force guess your password if he obtains the hashed and salted version. PKCS#11 v2.20 only supported PBKDF2 with the SHA-1 hash, which is no longer a good choice for this application, since advances notably in hardware-based hash crackers have made brute-force guessing these passwords much more feasible. PKCS#11 v2.40 supports SHA-512 (and SHA-256) for PBKDF2, which makes these attacks much harder.
A large amount of ancient cryptographic mechanisms like
FASTHASH as well as broken functions like
MD5 have been removed from the “current mechanisms” list. This should mean less chance of an error by an unwary programmer. However, take care, there are still insecure mechanisms in the list, like RSA PKCS#1v1.5 Encryption (recently removed from both TLS and the W3C Web Crypto API).
Two new attributes in PKCS#11 give you more fine-tuned control over key-management by marking keys that may be duplicated or deleted. Careful how you use them, though. Our Analyzer tool can help understand the security consequences of attribute configuration.
PKCS#11 v2.40 is a big step forward. If you want your crypto infrastructure to be secure, you should ask your vendor about their upgrade plans.
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.