May 12, 2021
Shadow certificates are more likely than you think. It is as if the nails and screws used to build a house end up being what makes the house fall down. Briefly, shadow certificates refer to digital certificates that have been introduced by employees that the DevOps or SecOps teams are unaware of.
Read Article ->January 11, 2021
The new 3rd revision of the FIPS 140 standards for Cryptographic Modules is an effort to align the NIST-managed standard with its ISO counterpart ISO 19790(2012).
Read Article ->October 27, 2020
If you want to supply cloud-based services to the US Federal Government, you have to get FedRAMP approval. This certification process covers a whole host of security issues, but is very specific about its requirements on cryptography: you have to use FIPS 140-2 validated modules wherever cryptography is needed...
Read Article ->May 7, 2020
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.
Read Article ->April 3, 2020
We have had a number of queries recently from people trying to figure out what FIPS 140-3 is, and how they can supply a FIPS 140-3 compliant solution to their customers. To make sense of this question we first need to understand a little background...
Read Article ->November 8, 2019
Cryptosense Discovery is our free tool to test a host’s usage of cryptography for common configuration mistakes and vulnerabilities. Discovery's new version discovers more hosts and more vulnerabilities, and improves the visual representation of attacks. We achieve this by using a well-known visualization method called attack trees.
Read Article ->August 1, 2019
What's the difference between cryptography in .NET Framework and .NET Core? A large part of the .NET APIs are common to both .NET Core and .NET Framework. Microsoft even released the .NET Standard, a subset of .NET APIs provided by all .NET implementations, to simplify things for cross-implementation developers. However, there are still significant differences between Core and Framework, and cryptography is one of them.
Read Article ->June 20, 2019
A recent success story for Cryptosense is our roll-out with a large global player in the ATM (cash machine) network. Since this firm is considered a Service Provider in the PCI regulations, they have regular audits to pass which contain a lot of requirements on cryptography: full cartography of applications, compliance with NIST standards etc.
Read Article ->January 8, 2019
Modern versions of IAST (like ours) can detect flaws even when the application is executing standard functional tests - there is no need to simulate attacks. This enables these tools to be deployed early in the development lifecycle and integrated into CI toolchains. However, there's one key feature that doesn't figure on most IAST checklists: coverage checking...
Read Article ->April 7, 2017
In January 2017 Oracle released a Java update with a number of improvements to its crypto security. These included increasing minimum parameters (1024 bits for RSA XML signatures and DSA certificates, 256 bits for Elliptic curve keys used in TLS,..),
Read Article ->May 31, 2016
The new version (3.2) of the PCI DSS compliance requirements for the payment card industry was released a few weeks ago. While the PCI definition of strong cryptography remains unchanged, the new version contains some other interesting new measures around secure use of cryptography
Read Article ->February 14, 2016
National and international standards bodies like NIST, ENISA and PCI already make recommendations about key-lengths and algorithms, so why write another set? At Cryptosense we've been working on a simple web-based tool to discover external-facing crypto services, and we needed a pragmatic set of best-practice standards for evaluating the results. If we used the ENISA "future application" standards, for example, pretty much the whole Internet would get an F.
Read Article ->December 15, 2015
Cryptography is sufficiently complex to make writing a single compliance document that ensures security impossible. There are nonetheless various industry compliance guidelines that try to ensure the biggest mistakes are avoided. The PCI-DSS standard, now in version v3.1, describes security requirements for processing electronic payments and includes some interesting crypto advice.
Read Article ->July 16, 2015
In April 2015, following its transfer to OASIS, the PKCS#11 standard for device crypto APIs got its first official update in ten years. There is always some lag time between a new standard and vendor adoption. Here are five good reasons you should be nagging your crypto hardware vendor to upgrade:
Read Article ->March 30, 2015
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?
Read Article ->January 5, 2015
Since we wrote this post three years ago, several HSMs have added support for modern elliptic curves like curve25519. The yet-to-be-finalised PKCS#11v3.0 will likely have a number of new algorithms using this curve and variationsOriginal post:If you read the last post about choice of key lengths in PKCS#11, you may have been struck by the fact that the recommended key lengths for RSA, if you want to be secure in the future, are rather long. This is one of several reasons for moving to elliptic curve cryptography. But which curve to choose?
Read Article ->December 29, 2014
In a series of articles on the blog this year we've covered cryptographic algorithm choice in PKCS#11, taking into account recent cryptanalytic results. This post will complete the picture by discussing the choice of key-length and other parameters for these algorithms. As usual, our main source is the ENISA Algorithm and Key Length Report, recently updated for 2014.
Read Article ->November 5, 2014
We originally published our compliance criteria for PKCS#11v2.20 back in 2014. We recently completed an update for v2.40, which contains new criteria for the extra attributes added in the new version, as well as revised references that take you directly to the right section of the HTML document of PKCS#11v2.40. Since we started applying these criteria to commercially available PKCS#11 devices using our Analyzer, we have found multiple vulnerabilities and non-compliances in several major manufacturer's products, all of which had FIPS/CC certifications.
Read Article ->October 24, 2014
In previous posts we covered the state of the art cryptanalysis results on the RSAmechanisms, hash functions, block ciphers and block cipher modes available in PKCS#11. In this post we look at the message authentication code (MAC) mechanisms available.
Read Article ->June 12, 2014
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?
Read Article ->