Application security teams have limited resources for improving security. Deciding where to deploy them is not easy, and the right answer will vary for different organisations. However, one question we’re often asked by teams considering our Analyzer software is, how common are the kind of “rubber hits the road” deployment of crypto flaws that it detects?
When we started testing the cryptography in Java applications using our Analyzer software, one of the first results we found was the use of a 512-bit RSA key for signature verification.
At first this looks rather alarming since 512-bit RSA keys are easily breakable by brute force factorisation now.
The DROWN attack on SSL/TLS has by now been pretty comprehensively covered both here and elsewhere. But two weeks after its announcement, it’s clear that it’s not being fixed very fast, at least compared to other recent SSL vulnerabilities like Heartbleed. Why not?
One possible explanation, based on the observation that DROWN exploits the long-deprecated SSLv2.0 protocol, is that a lot of these “vulnerable” servers are in fact honeypots: servers deliberately left vulnerable without real data on them to divert or gather intelligence on attackers. We’ve seen a lot of servers vulnerable to DROWN detected on our webtool at discovery.cryptosense.com in the least two weeks, and decided to follow up on some of them.
Welcome to the Golden Age of Applied Crypto Research
The year 2015 saw the publication of an unprecedented number of practical attacks on real cryptographic systems. Attacks like FREAK and LOGJAM which combine model-based testing of crypto code with state-of-the-art numerical algorithms for cryptanalysis give a taste of the kinds of capabilities that are available to sophisticated adversaries.
It’s a good time to review a few highlights of last year’s results in applied crypto and take stock of what needs to be done to stay secure in 2016.
Cryptosense has been selected as a regional finalist in the UBS Future of Finance Challenge. Our entry was chosen from amongst 600 entries to take part in the regional final in London in November. The Challenge is a global competition to find entrepreneurs, start-ups or growing companies that could change the way finance works and how banks meet their client’s needs.
You can read more about the UBS Future of Finance Challenge here.
We were one of the three winners of the London final.
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.
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.
Cryptography is a small but important part of security, and choosing the right cryptographic algorithm is a small but important part of deploying cryptography. As part of some recent work I’ve been reviewing the cryptographic algorithms slated for inclusion in the W3C Crypto API, currently in last call.
Fortunately, there are already a number of papers surveying the state of the art in cryptoanalysis of deployed algorithms, including the ENISA annual report on algorithms and key lengths (taking over form the old ECRYPT survey). There is also Rogaway’s comprehensive block cipher mode survey from 2011. Unfortunately, some methods proposed by the W3C TC don’t appear in either document, but tracking down the state of the art results for these was an interesting task. For the TL/DR, here’s a table summarizing the findings:
Key derivation is a common operation in cryptographic protocols. It’s used, for example, to generate a session key on the basis of contributions from a client and server, or to generate a series of unique keys for devices from a master key. While there are some security results for key derivation functions, it’s an area that hasn’t received a lot of attention from researchers. And like most crypto, it’s surprisingly easy to get wrong.
Key Derivation in PKCS#11
The PKCS#11 API furnishes a whole suite of derivation functions, from those specific to TLS through elliptic curve functions, those based on various symmetric ciphers like AES and DES as well as some simpler functions. Unfortunately, a lot of these have pitfalls. In this post we’ll take a look at three attacks.
Continue reading →
RSA Encryption with padding as described in PKCS#1v1.5 has been known to be insecure since Bleichenbacher’s CRYPTO 98 paper revealed a chosen ciphertext attack. PKCS#1 version 2.0, published September 1998, proposed a new padding scheme based on OAEP and recommended the old scheme not be used in any new implementations.
This hasn’t stopped PKCS#1v1.5 padding from being used just about everywhere. Take a look at this table of Smart Card support for example.
One reason might be that Bleichenbacher’s attack was though to be impractical: the worst-case analysis of the attack in the paper tells us that 2^20 chosen ciphertexts are needed, which gave rise to the name “the million message attack”.
In fact the median case is much easier than that. And like all attacks, the attack algorithm has only got better. Building on advances by Klima, Pokorny and Rosa in 2003, our work published at CRYPTO 2012 showed that the median case for the standard oracle requires less than 15 000 messages.
Still, there seems to be widespread belief that PKCS#1v1.5 is somehow ok if you use it carefully. For example, in this debate on the W3C crypto API bugzilla, one comment suggests that because TLS still uses RSA PKCS#1v1.5 then it must be possible to make secure protocols with it.
Let’s look more carefully at how TLS “fixes” the attack. Continue reading →