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.
We’ve spent a lot of time working on crypto audit of Java applications recently at Cryptosense while developing our Java Crypto Analysis tool. To share our results, this spring we’ll be running a two-day training course on crypto security specifically looking at applications that use the Java crypto API (JCE/JCA).
As well as secure crypto programming practice and common mistakes that lead to vulnerable applications, we’ll look at the specifics of commonly used crypto libraries that offer a JCE/JCA interface. This includes their implementation of the Java keystore. In particular, the training will cover key-management flaws and how to avoid them.
As usual, the training will take place in our wonderful location overlooking the Grand Canal in Venice, and will include a networking dinner in our favourite nearby Osteria.
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.
After 2 days of intense competition, Cryptosense has been chosen as one of 3 Regional Finalists to go through to the UBS Future of Finance Global Finals to be held in Zurich in December 2015. Cryptosense are competing in the Secure Banking Challenge.
Whatever the future of finance is, it will be built on cryptography. Get in touch with Cryptosense to find out more.
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: