A lot of people are concerned that their encryption keys stored in cloud services such as AWS KMS, Azure Keyvault, or GCP KMS, are not really secure. This can be a particular concern for people working in highly regulated industries. So how can you know if your keys are secure? In this video Dr Graham Steel explains the issues that our customers often ask us about.
This question is the subject of a podcast interview with Cryptosense founder, Graham Steel, in which he talks to Karen Webster, CEO of PYMTS.com.
Cryptosense software can be described as an ‘automated hacker’, capable of systematically searching hardware configurations, software and APIs to find security flaws.
Automated hacking is a subject of particular interest to banks, whose security critical data is worth a huge amount of money to malicious hackers. Many banks are now realizing that the cost of hiring a friendly automated hacker is a great way to reduce the risk of data loss and make it easier to pass security audits.
Growth in cloud computing, smartphone use and interconnected devices means that even more of our private data is now at risk from hackers. Cryptography is being used more and more to secure this data, however it is notoriously hard to implement correctly.
Developers and hardware manufacturers are now looking for automated ways to test that their cryptography is as secure as they need it to be. Software packages such as Cryptosense’s Analyzer are at the forefront of automated crypto analysis.
As an expert in the field of automated crypto analysis, Cryptosense founder Graham Steel has been invited by IEEE to write an article in their journal Security & Privacy about this growing area of formal analysis.
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?
The filter that Caml Crush provides means that you can add restrictions and regulations to the commands or mechanisms that the device uses. For example, the filter can be configured to prevent the use of single-DES encryption and other insecure mechanisms. Other possibilities include segregating certain mechanisms or commands between the Security Officer and the User. To test the security of their filter configurations, the ANSSI team used Cryptosense Analyzer. A full description of their results appeared in a recent paper at the CARDIS conference. Upcoming packaged versions of Caml Crush for Fedora and Debian will ship with a “secure by default” configuration.
If the underlying PKCS#11 implementation has compliance errors, the filter won’t necessarily patch them. Our tests using our compliance checker with the filter and Opencryptoki bear this out. However, Caml Crush has an embedded plugin system which could be leveraged to address this.
The producers of Caml Crush advise anyone implementing a PKCS#11 interface to “pay attention to all the footnotes – especially table 15.” as this can make the difference between a secure and a non-secure implementation. There are more than 200 footnotes in the standard.
Other ANSSI PKCS#11 Projects
Recently released on github, the opkcs11-tool provides handy low-level tools for working with PKCS#11 devices. It offers some functionality unavailable in other similar open source tools, like elliptic curve key generation, fine-grained management of object attributes, PSS and OAEP schemes.
The Caml Crush filter does a great job of adding an extra level of security to a device. To configure it to suit your application and key-management, the Cryptosense toolsuite is ideal.
If you would like your PKCS#11 project included in our series, get in touch.
Update March 2018
Since we wrote this post our compliance criteria have been extended to over 100 covering PKCS#11 v2.40 and used to find a host of issues with live HSMs.
Recently we’ve been trying out our PKCS#11 compliance tester on a number of open-source PKCS#11 implementations. We’ll be publishing the results here over the next few weeks, as well as sending the reports from our tools to the project developers. First up: Opencryptoki and its PKCS#11 software token.
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.
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.