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.
Cryptographic Vulnerabilities, News & Research
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 →
The 7th workshop on Analysis of Security APIs will be held in Vienna University of Technology, Austria on 18th July 2014 as part of the Vienna Summer of Logic. The programme includes talks on low-cost HSMs made from smartcard chips, secure device enrollment, smart API fuzzing and a banking security wishlist.
We’d be delighted to see you there, register here via the VSL registration page – select “FloC and Associated Workshops Week 2“.
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 →
Cryptography is a small but important part of security, and choosing the right cryptographic algorithm is a small but important part of deploying cryptography. As part of some recent work I’ve been reviewing the cryptographic algorithms slated for inclusion in the W3C Crypto API, currently in last call.
Fortunately, there are already a number of papers surveying the state of the art in cryptoanalysis of deployed algorithms, including the ENISA annual report on algorithms and key lengths (taking over form the old ECRYPT survey). There is also Rogaway’s comprehensive block cipher mode survey from 2011. Unfortunately, some methods proposed by the W3C TC don’t appear in either document, but tracking down the state of the art results for these was an interesting task. For the TL/DR, here’s a table summarizing the findings:
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.
For our main demonstration, we’ll be showing how you can use our Cryptosense Analyzer to audit, configure and secure an HSM interface. To simulate the variety of PKCS#11 HSMs on the market, we built our own HSM from a Raspberry Pi, which we call the PiHSM. Designing and building the PiHSM was kind of fun and this blog post shows how we did it.