With more and more sensitive applications being migrated to the public cloud, we’ve received several requests from our users to help them evaluate how the major cloud providers support crypto and key-management. In a series of posts, we’ll be taking a look at the cloud crypto APIs of AWS, Google, and Microsoft (Azure).
Cryptographic Vulnerabilities, News & Research
Today Hanno Böck, Juraj Somorovsky and Craig Young announced details of new work testing TLS implementations in the wild for Bleichenbacher’s attack on RSA PKCS#1v1.5 encryption. The short summary is the attack, first made public at CRYPTO ’98, still works on almost 3% of the Alexa top million most visited websites thanks to minor details in the way they implement countermeasures.
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.
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.