October 23, 2020
In this short demo, Graham explains how to use a Hardware Security Module (HSM) securely.
Read Article ->June 8, 2019
The announcement yesterday of this talk about HSM hacking on the BlackHat 2019 program has caused a stir, and for good reason: the authors claim to have discovered remote unauthenticated attacks giving full control of an HSM and complete access to keys and secrets stored on it...
Read Article ->December 21, 2016
Google recently announced a project to produce tests for cryptographic libraries to detect common weaknesses. Piloted by star cryptographers Daniel Bleichenbacher and Thai Duong, this is an exciting development for us at Cryptosense, and not just because they cite our CRYPTO '12 paper in their RSA tests.
Read Article ->August 8, 2016
In 2014 I wrote a piece for this blog on RSA PKCS#1v1.5 encryption and why we need to get rid of it. At the time, the list of algorithms and padding modes to be included in the W3C WebCrypto API was under discussion, and I wanted to argue for the exclusion of this mode from the API. In the end it was indeed left out.
Read Article ->June 22, 2016
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.
Read Article ->November 3, 2015
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".
Read Article ->July 16, 2015
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:
Read Article ->June 17, 2015
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.
Read Article ->March 30, 2015
For the next instalment in our compliance testing series, we interviewed the creators of Caml Crush, an open source PKCS#11 project. Caml Crush is a filtering proxy that inserts itself between a PKCS#11 device and the calling application. As well as its inherent client/server architecture be it local or remote, Caml Crush can also apply filters which deal with some of the major security issues that affect PKCS#11 interfaces. We will take a look at how it works and how it affects the Compliance Checker results on a device. The developers of Caml Crush (Ryad Benadjila, Thomas Calderon, and Marion Daubignard at the ANSSI) agree that “The PKCS#11 standard is not easy to use“, so how does Caml Crush help?
Read Article ->January 5, 2015
Since we wrote this post three years ago, several HSMs have added support for modern elliptic curves like curve25519. The yet-to-be-finalised PKCS#11v3.0 will likely have a number of new algorithms using this curve and variationsOriginal post:If you read the last post about choice of key lengths in PKCS#11, you may have been struck by the fact that the recommended key lengths for RSA, if you want to be secure in the future, are rather long. This is one of several reasons for moving to elliptic curve cryptography. But which curve to choose?
Read Article ->December 29, 2014
In a series of articles on the blog this year we've covered cryptographic algorithm choice in PKCS#11, taking into account recent cryptanalytic results. This post will complete the picture by discussing the choice of key-length and other parameters for these algorithms. As usual, our main source is the ENISA Algorithm and Key Length Report, recently updated for 2014.
Read Article ->November 24, 2014
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.
Read Article ->November 5, 2014
We originally published our compliance criteria for PKCS#11v2.20 back in 2014. We recently completed an update for v2.40, which contains new criteria for the extra attributes added in the new version, as well as revised references that take you directly to the right section of the HTML document of PKCS#11v2.40. Since we started applying these criteria to commercially available PKCS#11 devices using our Analyzer, we have found multiple vulnerabilities and non-compliances in several major manufacturer's products, all of which had FIPS/CC certifications.
Read Article ->October 24, 2014
In previous posts we covered the state of the art cryptanalysis results on the RSAmechanisms, hash functions, block ciphers and block cipher modes available in PKCS#11. In this post we look at the message authentication code (MAC) mechanisms available.
Read Article ->October 2, 2014
This is the latest in our series analysing the state of the art cryptanalysis results on the RSAmechanisms, hash functions and block ciphers available in PKCS#11.We've seen that PKCS#11 makes available a range of block ciphers ranging from dubious to recommended options. Additionally, for most block ciphers, several modes are available. What are the security consequences of the mode choice?Here we survey the block cipher modes available, giving a brief summary of their security.
Read Article ->September 18, 2014
Following on from our popular review of RSAmechanisms and hash functions, this post reviews the block ciphers and modes available in PKCS#11 v2.20 and the state of the art in their cryptanalysis. We'll also look at what's changing in version 2.40.The first version of PKCS#11 came out in 1995, and since then no mechanisms have been removed, though this will change when version 2.40 comes out. Reading the mechanism list for block ciphers is therefore something of an exercise in cryptographic archaeology.
Read Article ->October 8, 2014
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?
Read Article ->August 7, 2014
A tracer is a simple but important tool for auditing crypto security that allows the analyst to see the calls made by an application to a crypto interface. This is especially useful if the application and/or the crypto provider are only available in binary or black-box form (e.g. an HSM), but the crypto API is known. Even if source code is available, a simple tracer can save a lot of time compared to instrumenting code or manually setting trace points.
Read Article ->June 30, 2014
A hash function is a basic building block of many cryptographic protocols. Cryptanalysis of hash functions has made great progress in the last decade, so how do the hash functions provided by PKCS#11 measure up?
Read Article ->June 16, 2014
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.
Read Article ->June 12, 2014
Following my post on the security of the algorithms in the W3C Crypto API (our most viewed blog post by far), I thought I'd repeat the exercise for other cryptographic APIs. Here at Cryptosense we do a lot of work with PKCS#11, widely used in applications that use devices like HSMs and smartcards to provide cryptography. How do the algorithms in PKCS#11 measure up?
Read Article ->May 27, 2014
Key derivation is a common operation in cryptographic protocols. It's used, for example, to generate a session key on the basis of contributions from a client and server, or to generate a series of unique keys for devices from a master key. While there are some security results for key derivation functions, it's an area that hasn't received a lot of attention from researchers. And like most crypto, it's surprisingly easy to get wrong.
Read Article ->