A bad week for crypto: following KRACK, now there's ROCA
Blog post 2017-10-18 by Ralph Moonen, Technical Director at Secura
Following on the heels of KRACK (see previous post: How broken is WPA2 really and what to do) we now hear about ROCA. ROCA stands for Return Of Coppersmith Attack. Its discoverers are yet to disclose details on the attack, so we know little but can speculate and test nicely, because there is a test tool. It is relevant for Infineon chips using a specific firmware/software library.
It’s all about RSA public/private key pairs, and how some public keys can be analysed, to reveal the private key. The cornerstone of pub/priv encryption schemes is a trapdoor function: easy one way, difficult the other: multiplying two primes is easy; finding the two factors, given only the result is hard. I’ll leave the exact math to the reader. In theory, if your two primes are really random and sufficiently long, then this method holds. If one of those two requirements (long and very random) doesn’t hold, the system breaks down.
We have seen examples of one of these requirements breaking down in the past. Primes that are not really random, leading to moduli that share primes and are vulnerable to Euclid’s GCD algorithm (https://en.wikipedia.org/wiki/Euclidean_algorithm) are a beautiful example of that. In practice, you can break a very very small percentage of (sufficiently long) RSA keypairs from SSL/TLS certs worldwide using this method.
Now we have something new. It can’t be the length of the prime or the modulus. That’s an easy check and absence would be very obvious in any security review (which I assume they had since the chips are FIPS certified). It can’t be the randomness, since FIPS certification has pretty OK standards for PRNG’s. What’s left? Well, what’s left is the question, how do you know if some number is a prime at all?
A nice explanation of random prime generation can be found here: https://langui.sh/2009/03/07/generating-very-large-primes/. TL;DR: generate a candidate prime, do a test. If failed, repeat until test passed. So to me the most obvious candidate for a failure would be in this test. The most used test is the Miller-Rabin test: https://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test. If you don’t properly perform this test, your so-called ‘random’ primes will turn out pretty random, but not so prime. Assuming that this vulnerable implementation does not perform this test well, then an RSA modulus will not be a product of two primes, but three or more, leading to a much much easier factorisation process of the resulting prime! In fact, this is what the discoverers state: factorising the components of the modulus still takes time, but is very much easier. I therefore think that when the paper is published, it will have something to do with the implementation of the prime-test.
I was curious if any of the public keys that I could lay my hands on were vulnerable. My colleague Tom Tervoort checked all public SSL/TLS certificates in the Dutch IP space (port 443 only, approx.. 500.000 certs) and found no instance of this vulnerability (using the tools provided by the discoverers). But since this is a smart-card/library vulnerability we wouldn’t really expect any SSL/TLS certs to be found.
So I also checked my credit cards and bank cards. Fortunately no findings :-) FYI, you can see the public key in your credit card by using a standard reader and https://code.google.com/archive/p/javaemvreader/.
After running my pubkey through the online checker at https://keychest.net/roca I’m happy to report my VISA and Amex cards are not vulnerable.
For good measure, I also checked my ABN AMRO debit card, and my Dutch e-Passport. Both were fortunately non-vulnerable.
TL;DR: Some primes are probably not primes. Dutch VISA credit cards, ABN AMRO bank cards, SSL/TLS certificates and e-Passports likely not affected, YMMV.
Blog post 2017-10-17 by Ralph Moonen, Technical Director at Secura