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.
Caught by the Fuzz
This is where “well-typed smart fuzzing” comes into play. As I explained during my talk, I have been developing a small domain specific language that makes it possible to describe arbitrary cryptographic APIs. We then use these descriptions to automatically exercise an API in a smart way, exploring corner cases of all the commands and learning the behaviour of the device under test.
To get the best possible model of a device, we need good test coverage, but to keep our busy users happy, we also need to reduce the footprint of our analysis as much as possible. We devoted a lot of effort to improving our testing algorithm, making it possible to get as many tests as possible done in a given amount of time.
In my talk I explained how even on fast devices we’ve reduced the test time overhead to as little as 3%. We’re testing the tool on PKCS#11, the Thales 8/9000 API, and we’re looking for more examples. So if you have device with security-critical cryptographic API like an HSM or even an homebrewed web API (e.g., a RESTful API), get in touch and we’ll see what we can do.