Cryptographic Vulnerabilities, News & Research
I was excited to read Matt Might’s recent post “An introduction to QuickCheck by example”. QuickCheck is a library that lets you define random generators for arbitrary data-types, and then use these generators to produce test cases for functions.
Matt’s post is a perfect occasion to describe the testing methodology we use a Cryptosense, and how it’s different from QuickCheck. I am going to present the ideas behind it at the next ICFP ML Workshop, so think of this as a sneak preview.
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.
Recently we’ve been involved reviewing the draft W3C Web Crypto API. As a result of this and as part of our ongoing work on web crypto, our intern Gregoire put together a Chrome extension that traces calls to the WebCrypto API.
As you can see in the screenshots, a simple dropdown gives a list of all key objects in the session and their attributes.
As part of what some are describing as a fantastic programme, Thomas will present his work on well-typed smart fuzzing at the ICFP ML Workshop in Gothenburg in September. The smart fuzzing algorithm is a key part of the first phase of the Cryptosense test methodology. Read more about it here, or if you’re attending the ICFP workshops, why not ask for a demo – both Thomas and Romain will be there.
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.
The 13th Smart Card Research and Advanced Application Conference (CARDIS) will be held in Paris November 5-7 this year, and Cryptosense is proud to be among the sponsors.
We’ll have a booth at the conference with some live demos of our cryptographic security audit tools. We promise to enliven your coffee break.
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 →