This summer we’ve updated our guide to crypto security in Java from beginning to end, with new sections on crypto library bugs, frameworks, JDK and Bouncy Castle keystores, and more.
Cryptographic Vulnerabilities, News & Research
Password-based key derivation functions (PBKDFs) are used in crypto for two reasons: to store passwords in a secure way, and to derive keys for use in other bits of crypto. We’ve written before about how they work and what parameters to use.
In our Analyzer tool for auditing application crypto, we have to solve the problem the other way round – how good are the parameters selected by a particular application? Just saying they are “not best practice” is not satisfactory for our users – they want to know if this is a critical issue needing an immediate fix or something that can wait until the next release.
The recent edition (no. 15) of hacker magazine POC||GTFO features a nice article on cracking JKS Java keystores. JKS is the default keystore in all current versions of Java and still the only kind available in several widely-used application frameworks, despite issues with its security.
The keystore works by password-based encryption (PBE): you supply a password and the private keys are encrypted under a key derived from that password. There are just two problems: the encryption is not real encryption and the key derivation is extremely weak. The PBE works by applying the hash function SHA-1 to the password (and a salt) to generate a keystream, and XORing the resulting stream against the key.
The US National Institute of Standards and Technology (NIST) has just announced withdrawal of approval for triple DES (also known as 3DES, TDEA and sometimes DES EDE) in common protocols such as TLS and IPSec. In other applications, they propose a restriction to just 8MB of data before changing keys. Why are they doing this and what are the consequences?
An interesting article at the recent IEEE Security & Privacy symposium carried out a usability study on Python crypto APIs. Participants with varying degrees of Python experience were given crypto programming tasks for which they had to use a given API (cryptography.io, Keyczar, PyNaCl, M2crypto or PyCrypto). The researchers evaluated the security of the participants’ solutions to try to see what kind of API is most likely to result in secure code.
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,..), and changing the treatment of a number of crypto operations (for example, JARs signed with less-than-1024-bit RSA keys are now considered unsigned).
However, these changes would be considered overdue my most standards agencies: both the 2016 NIST and ECRYPT standards consider 1024 bits RSA suitable only for legacy use. This highlights a problem with Java: every upgrade must take into account the vast amount of deployed code that might break when these parameters are changed.
A recent wikileaks dump of CIA material included a file called “Network Operations Division Cryptographic Requirements“. Assuming it’s genuine, this 17-page PDF describes crypto policy that must be followed by developers of “tools used to advance the CIA’s intelligence collection activities”.
Since a government security agency has insight into the state of the art in non-public cryptanalysis, it’s interesting to see what government spies recommend as a secure policy for crypto usage. Here I’ve picked out a few of the highlights that were interesting to me, in particular in the ways they’re different from other public crypto standards like PCI or ECRYPT.
Today Google announced the first public full SHA-1 collision, i.e. the first pair of distinct values that when hashed with the SHA-1 function produce the same digest. This should not come as a surprise – it follows the free-start collisions announced at the end of 2015, and many cryptographers had been anticipating full SHA-1 collisions imminently.
To understand what this means, it helps to look at what happened after collisions were found in the MD5 hash function.
At our crypto service discovery site discovery.cryptosense.com you don’t have to enter the qualified domain name of a server to test (like
www.mydomain.com) – you can just enter a partial name like
mydomain.com and the tool will query DNS records to look for machines.
Previously, we used to do this by looking for common machines like
vpn.mydomain.com. Recently, we added a feature to query the certificate transparency log to look for certificates registered to this domain. This results in much better coverage of machines. The example screenshot below shows part of the results when querying for
It’s been almost a year since we released our 2016 Crypto Recommendations to coincide with the launch of our crypto service discovery and analysis tool. These rules also form part of the analysis set for our application crypto Analyzer.
Since then, there have been a number of interesting results in cryptanalysis as well as new implementation bugs found in common crypto software. It’s time to update our recommendations to take this into account. Here are the main changes we’ve made to our ruleset: