As well as supplying Cryptosense Analyzer to our customers so they can test their applications, we frequently apply the tool ourselves to widely-used open source software including the Java JDK. The Oracle Critical Patch Update (CPU) of 17th October contained patches for two CVEs discovered at Cryptosense in collaboration with our partners at University of Venice Ca’ Foscari.
Cryptographic Vulnerabilities, News & Research
After several vendor announcements last week, the details of Infineon’s RSA key generation vulnerability finally became available today. The attack calculates the value of the private key and requires only knowledge of the public key.
The vulnerable chips are pervasive and not necessarily sold directly by Infineon Technologies AG, as the chips can be embedded inside devices of other manufacturers.
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.
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.