Implement RSA-CRT hardening

[fweimer]

As far as I can tell, Openswan implements the RSA-CRT optimization without post-signing verification. This is risky, as explained here:

• https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/
• https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf

Please implement RSA-CRT hardening to mitigate this risk (or use the RSA implementation in OpenSSL, NSS, or libgcrypt).

[mcr]

Hi, I read your paper. I will look into adding this check; I found the paper interesting. As I understand it, in order for the attack to succeed, something has to "go wrong" in the process. I'm unclear if this is a statistical attack: does the attacker get some number of bits of the private key per attempt or not. If so, in IKE, an attacker would have to be willing to a DH operation for each attempt. (TLS does authentication first, privacy second, while IKE does privacy first, authentication second)

[fweimer]

@mcr, it's all or nothing, at least as long as you use RSA with two primes. Either the attack succeeds, and you have the complete private key, or it does not, and then you are none the wiser. It's probabilistic in the sense that for this remote attack scenario, there isn't a general tactic how to provoke such failures with increased probability. All you can do is perform more handshakes.

It is true that the DH phase in IKE prevents a passive observer just capturing network traffic from observing the leak. But an active attacker might still see the leak.

[mcr]

It seems a very odd attack; in that it depends upon something rather unusual occuring. A gamma ray could equally well cause memcpy() of the private keys... My instinct is that someone has a way to either provoke such failures on demand, or some specific implementation was prone to it. But, I understand the relatively low cost of the check, and so I anticipate that we will do something by the end of September.

[fweimer]

Thanks in advance for fixing this. You don't need a cosmic ray if you have a bug in your bignum implementation (and such things have happened in the past).