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.
However, inspecting the stacktrace our Analyzer provides traces this back to a method called
We can look at an old version of this code online. It turns out the 512 bit-key is part of one of several hard-coded self-signed certificates in the JAR Verifier, a piece of code that checks the signatures on Java classes before they are loaded to ensure they haven’t been tampered with.
testSignatures method seems designed to check that the signature mechanism itself hasn’t been tampered with. It achieves this by sending a random sequence of the hard-coded self-signed certificates to the signature class and checking the results are as expected (i.e., the self-signed signatures verify when checked against their own public keys, but fail when checked against any other public key).
This piece of code is also the source of an MD5-related finding in the Analyzer, since the old and now broken hash function was used to make the digests of the hard-coded certificates.
It’s interesting to see this quirky piece of code, and good to know the Analyzer is working properly, but we soon realised that our users don’t want to rediscover these inconsequential uses of 512-bit RSA every time they launch an application. Indeed, there will likely be other exceptions they want to make the Analyzer’s rules. That’s why we implemented a filter mechanism that allows you to specify a method or even a whole package that you want to exclude from results.
You can still see the filtered results under our filtered tab, but you won’t see them in the main findings. We add the
javax.crypto.JarVerifier.testSignatures filter by default, which covers both the use of RSA-512 and the MD5 hash function.