This is part two of our series looking at the cloud crypto services offered by the big three hosting companies: Amazon, Google and Microsoft. In part 1, we looked at what kinds of keys and secrets the providers will let you store, and what crypto operations you can do with them. Here, we’re going to look at the way access to keys is controlled for users and services.
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).
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?