When we started testing the cryptography in Java applications using our Analyzer software, one of the first results we found was the use of a 512-bit RSA key for signature verification.
At first this looks rather alarming since 512-bit RSA keys are easily breakable by brute force factorisation now.
Yesterday’s Oracle Critical Patch Update contains a credit to Cryptosense for CVE-2018-3210, a flaw found by one of our users while they were testing a Java application with our Analyzer software.
The bug involves a repeating IV in AES-CTR mode, a crypto mistake that can be hard to spot in code review. Our run-time testing approach detects it more easily. It’s also rather easy to exploit (see e.g. the Many-time Pad tool).
In a 2014 article “Why does cryptographic software fail?”, Lazar et al. took the most recent 269 CVEs marked as “cryptographic issues” and classified the site of the failure. While 17% of the failures were in crypto libraries, 83% were in the way the applications use the libraries. Up until now, Cryptosense Analyzer for Java applications only treated the 83%. Today that’s changing as we’ve added provider vulnerability testing.
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.
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.
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.
PrimeKey Solutions develops and supports the most downloaded open source enterprise public-key infrastructure (PKI) software available, EJBCA. You can find out why they use Cryptosense Analyzer for Java in a case study we’re releasing today.
We already use a variety of tools to ensure software quality, but we see security as an area of continuous improvement, and Cryptosense tools give us a cryptography-focused view that other tools can’t provide. A strong statement in itself, given the fact that PrimeKey’s teams of engineers work day in and day out with cryptography.
Tomas Gustavsson, CTO PrimeKey
Over the past few months, we’ve been taking a look at the security of applications using the Java crypto API or Java Cryptographic Architecture (JCA), and examining the most commonly-used providers, Oracle JCE and BouncyCastle. Some of the results have been published in previous blog posts. We’ve decided to summarise all our findings in a free whitepaper.
From the intro:
This whitepaper is intended for developers who use, or are considering using, the Java crypto API, and for application security testers who review crypto security. It is not intended to be an introduction to cryptography, but rather a concise guide for readers familiar with crypto basics. We will tour the Java crypto API and explain common mistakes that cause security problems and crop up frequently in real applications.
We hope you find it useful – feedback is welcome. We’ll be updating the document in the future to cover some single sign-on protocol implementations and Java application framework crypto that we’ve been looking at recently, but suggestions for other topics are welcome.
In previous posts we looked at the security of the JKS and JCEKS Java Keystores implemented in the default (Oracle) JCE/JCA crypto provider. Here we’ll take a look at what’s offered by BouncyCastle, a widely-used open-source alternative.
Like the Oracle provider, keystores in BC rely on password-based encryption for confidentiality, i.e. deriving an encryption key from a password and then using that to encrypt the keys for writing to a file. BC offers three keystore types: BKS (bouncy castle keystore), UBER (nothing to do with taxis), and a PKCS#12 compatible keystore for interoperability.
Here we summarize the encryption used in each keystore to protect private key values. Behaviour on certificates can be different, and some keystores also allow symmetric keys to be stored – more on this later. In addition to private key value encryption, UBER has an extra layer of encryption for the whole keystore, which means that all metadata around the keys and certificates will also be encrypted. Below the table, we’ll step through the analysis.
| Store | Cipher | Iterations | Salt | Effective Keylength |
|---|---|---|---|---|
| BKS | PBEWithSHAAnd3-KeyTripleDES-CBC | Random(1024, 2047) | 160b | 168b |
| UBER (keys) | PBEWithSHAAnd3-KeyTripleDES-CBC | Random(1024, 2047) | 160b | 168b |
| UBER (store) | PBEWithSHAAndTwofish-CBC | Random(1024, 2047) | 160b | 256b |
| BCPKCS12 | PBEWithSHAAnd3-KeyTripleDES-CBC | 1024 | 160b | 168b |
BKS uses triple-DES encryption, which is deprecated for most applications but not considered desperately insecure (it can still be used, for example, in PCI DSS environments). One reason for deprecation is that it has a 64-bit blocksize, which is not enough for high-volume applications. Here we’re only encrypting a private key so this shouldn’t matter. The key is derived following the method from PKCS#12v1.0, which is also deprecated (PKCS#12v1.1, from July 2014 recommends using only PBKDF2, which is defined in PKCS#5v2.1). The PBKDFs use a random salt, as we would expect. Note that the number of iterations of the PBKDF is a random value between 1024 and 2047. This is an unusual construct, and it’s hard to say how this offers extra security since the number of iterations also is recorded in clear in the file, along with the salt. In any case, 2047 is considered quite a low number of iterations for modern applications.
UBER uses encryption similar to BKS for the private key values. It uses the same PBKDF and iteration count, but a different cipher (Twofish), for encrypting the whole keystore. Twofish was an unchosen finalist for the AES competition and so received a fair amount of cryptanalytic attention in the late 90’s. No significant weaknesses have been found.
BCPKCS12 also uses the old PBKDF (from PKCS#12v1.0), and a fixed 1024 iterations, which is a low value by modern standards. This choice probably comes from the fact that PKCS#12v1.0 gives 1024 iterations as the value in its example of the ASN.1 syntax (the recently revised PKCS#12v1.1 says only that it should be “1024 or more”).
Apart from protecting the confidentiality of the value of private keys, keystores can also protect integrity, i.e. you can make a password-based MAC of the whole keystore and then check it hasn’t been tampered with.
To do this, BKS and the PKCS#12 keystore create an HMAC using a key derived using the same PKCS#5v1.0 PBKDF as used for encryption. However UBER does something a little strange. Since it has already used the second keystore-wide password to encrypt the whole keystore, it simply calculates a SHA-1 hash of the keystore before encryption and uses this to check integrity after decryption has happened. This MAC-then-encrypt approach is generally considered a bad idea, since it can lead to attacks if, for example, there is a perceptible difference in behaviour (an error message, or execution time) between a decryption that fails because the padding is invalid, or a decryption that fails because the SHA-1 hash is invalid (a so-called padding oracle attack).
Note that early versions of BouncyCastle BKS (before v1.47) had a 20 bit HMAC key meaning that a functioning integrity password could be easily guessed. This issue only affects the integrity MAC, and would not help in obtaining the keys use to protect private keys.
Currently in beta, the FIPS version of Bouncy Castle will include a new keystore, BCFKS, which uses PBKDF2 with HMAC SHA512 for password based key derivation and AES CCM for encryption. This sounds promising.
There are few more messy details around BC and Oracle Java keystores, in particular around their encryption of public-key certificates and their behaviour when given null or empty string passwords. We cover that and more in our Java Crypto Whitepaper
When strong cryptography was introduced into Java, the legacy JKS keystore with its “SHA-1 and XOR” encryption method was replaced by JCEKS, which uses Triple-DES (3DES) encryption to protect serialized keys when they are written to disk.
There is a lot of JCEKS still around. So how exactly does the encryption work?
Like JKS, JECKS uses password-based encryption. Before creating a key, the JCEKS key derivation routine creates a random 64-bit salt. If the first and second half of the salt are the same, the first half is inverted.
This is already pretty odd, but will be explained (to an extent) when we look at how the two halves of the salt are used. For now let’s just look at the code that does the inversion of the halves:
// if the 2 salt halves are the same, invert one of them
int i;
for (i=0; i<4; i++) {
if (salt[i] != salt[i+4])
break;
}
if (i==4) { // same, invert 1st half
for (i=0; i<2; i++) {
byte tmp = salt[i];
salt[i] = salt[3-i];
salt[3-1] = tmp;
}
}
See anything strange? Yes 3-1, not 3-i. What's the effect of this typo? It means that halves aren't really inverted. The salt 12341234 becomes 41241234 instead of 43211234. This bug is present in Oracle Java and OpenJDK.
Weird bug, but it doesn't matter: the purpose is to make the two halves different. This is because of what comes next: the first half is attached to the password and hashed (using MD5) c times to produce the first 128 bits of the 3DES key. The second half is then attached to the same password and hashed c times to produce the last 64 bits of the 3DES key and the 64 bit IV to be used to encrypt the key using 3DES in CBC mode.
Why did the designers want to prevent the two salt halves from being the same? Remember that the salt will be stored in plaintext, so a would-be attacker can easily access it. Suppose he realises that the salt has two identical halves. Then he knows that the first and third 64-bits of the 3DES key are equal, and the IV is equal to the second 64-bits of the key.
Knowing these things are the same reduces the search space, but in practice it is very unlikely that this will make brute-forcing the key easier than a dictionary attack on the password.
What is more interesting is that in the Oracle Java JCEKS, that constant c for the number of iterations is just 20.
Note also that in the JCEKS scheme, the two calculations for the two key halves can be carried out in parallel, since the result of one does not depend on the result of the other.
While the "right" number of iterations is highly application-dependent, as a guide, most recommendations propose about 10000 iterations. Additionally, to counteract parallelized and specialist hardware-based attacks, it is considered prudent to use a hash function that requires considerable memory for each derivation. MD5 is certainly not such a function. Better alternatives are either PBKDF2-HMAC-SHA512, if you are restricted to NIST-approved schemes, or something like scrypt if not.
JCEKS is an improvement over the original JKS, but it cannot be considered secure: 20 iterations of MD5 is not considered a secure password-based key derivation method against today's attackers. Find out more about alternatives in our Java crypto security whitepaper.