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?
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.
A video of my recent talk at QCon London on crypto API security, How I Learned to Stop Worrying and Trust Crypto Again, is now online. Questions and feedback welcome.
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 →
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?
One problem with PKCS#11 is it hasn’t been updated since 2004 (though this is about to change, we’ll look at the proposed changes in a future post). The state of the art in cryptanalysis, however, has certainly advanced, to the extent that many of the cryptographic algorithms, or mechanisms proposed in PKCS#11 are now considered broken. Continue reading →
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.
Key Derivation in PKCS#11
The PKCS#11 API furnishes a whole suite of derivation functions, from those specific to TLS through elliptic curve functions, those based on various symmetric ciphers like AES and DES as well as some simpler functions. Unfortunately, a lot of these have pitfalls. In this post we’ll take a look at three attacks.
Continue reading →
RSA Encryption with padding as described in PKCS#1v1.5 has been known to be insecure since Bleichenbacher’s CRYPTO 98 paper revealed a chosen ciphertext attack. PKCS#1 version 2.0, published September 1998, proposed a new padding scheme based on OAEP and recommended the old scheme not be used in any new implementations.
This hasn’t stopped PKCS#1v1.5 padding from being used just about everywhere. Take a look at this table of Smart Card support for example.
One reason might be that Bleichenbacher’s attack was though to be impractical: the worst-case analysis of the attack in the paper tells us that 2^20 chosen ciphertexts are needed, which gave rise to the name “the million message attack”.
In fact the median case is much easier than that. And like all attacks, the attack algorithm has only got better. Building on advances by Klima, Pokorny and Rosa in 2003, our work published at CRYPTO 2012 showed that the median case for the standard oracle requires less than 15 000 messages.
Still, there seems to be widespread belief that PKCS#1v1.5 is somehow ok if you use it carefully. For example, in this debate on the W3C crypto API bugzilla, one comment suggests that because TLS still uses RSA PKCS#1v1.5 then it must be possible to make secure protocols with it.
Let’s look more carefully at how TLS “fixes” the attack. Continue reading →
Cryptosense CEO Graham Steel will be demystifying cryptographic hardware this Friday 25th April in a talk at Hackito Ergo Sum entitled Hardware Security Modules: attacks and secure configuration. The conference is in Paris at La Villette – register here to come and see this and a dozen other high quality security and hacking talks.
Find out more about attacks on HSMs and other cryptographic hardware.