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.
This is a very bad idea for a number of reasons as we explained in a post on this blog last year. One is that it makes dictionary attacks extremely straightforward. In particular, private keys are encoded with a lot of redundancy which means you don’t need to check the whole keystream for each guess at the password: the first block is enough.
Fast forward to 2017 and Tobias “Floyd” Ospelt has gone further. In his POC||GTFO piece he describes an implementation of this technique in the popular open-source password cracking tool Hashcat. As of version 3.6.0, you can take advantage of the fast implementation and GPU integration in Hashcat to achieve some pretty incredible speeds – close to 8 billion hashes/sec with an NVIDIA GTX 1080 is reported (since there is only a trivial comparison to execute after each calculation of a block of keystream to verify a guess, this is equivalent to being able to test 8 billion passwords per second).
The upshot of this is that anyone who can download Hashcat can crack JKS keystores extremely fast. It should be removed from production systems. Once Java 9 finally arrives, the default keystore type will be changed.
Thanks Tobias for mentioning Cryptosense and our blog post in the POC||GTFO article – we’re secretly very pleased to be in there 🙂