May 7, 2020

ANSSI TLS recommendations v1.2 in Cryptosense Discovery

Our cryptography service discovery site discovery.cryptosense.com detects servers under a given domain name and runs SSH and TLS scanners against each of them. The results are checked against best practices carefully defined by Cryptosense. You can also choose to check your results against other widely known standards: ECRYPT and NIST.

Cryptosense Discovery now provides a new standard, “ANSSI”, based on the recent new version of the security recommendations for TLS by ANSSI, the French government cybersecurity agency.

Why would I care about recommendations from ANSSI?

Broadly speaking, ANSSI is the French equivalent of NIST, and their recommendations are usually meant for French OIVs (Opérateur d’importance vitale – companies and agencies considered vital for the French economy and the security of the state), and anyone who wants to supply technology to the French government.

However, even if you are outside those categories, the ANSSI have real experience of state-level actor attack capabilities, so it’s interesting to see what they recommend.

Continue reading →

March 30, 2015

PKCS#11 Compliance Testing: Caml Crush

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

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.

Implementation advice

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.

Summary

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.

Get our PKCS#11 Security Whitepaper