Factoring RSA Keys with TLS Perfect Forward Secrecy(securityblog.redhat.com)
securityblog.redhat.com
Factoring RSA Keys with TLS Perfect Forward Secrecy
https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/
2 comments
The author's paper has the technical details not present in the article:
https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf
and some interesting remarks:
"The OpenSSL case is slightly complicated because this library performs a verification and re-computes the signature without the CRT optimization if a fault has been detected. We believe that this poses no immediate danger—Lenstra’s attack on RSACRT certainly does not work even if a second fault occurs because of the unoptimized second computation. Depending on the nature of the faults, this could conceivably still reveal the key over time, but several thousand faulty signatures are needed for current key sizes [1, 8], each one preceded by an RSA-CRT fault. As shown in [8], it is possible to construct a faulty CPU which indeed leaks keys in this way, which is why there are some lingering concerns about the reliability of the OpenSSL hardening."
And from the conclusion:
"In the short term, implementing a checked RSACRT signing operation, like NSS or even OpenSSL already do (despite some theoretical concerns about the effectiveness in the case of OpenSSL), seems a very reasonable hardening measure. Longer term, TLS should perhaps switch to a non-deterministic signature scheme like RSASSA-PSS. However, none of these measures will help those operators who have been using unchecked RSA-CRT implementations for years, and are now wondering if their RSA private keys have already leaked."
https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf
and some interesting remarks:
"The OpenSSL case is slightly complicated because this library performs a verification and re-computes the signature without the CRT optimization if a fault has been detected. We believe that this poses no immediate danger—Lenstra’s attack on RSACRT certainly does not work even if a second fault occurs because of the unoptimized second computation. Depending on the nature of the faults, this could conceivably still reveal the key over time, but several thousand faulty signatures are needed for current key sizes [1, 8], each one preceded by an RSA-CRT fault. As shown in [8], it is possible to construct a faulty CPU which indeed leaks keys in this way, which is why there are some lingering concerns about the reliability of the OpenSSL hardening."
And from the conclusion:
"In the short term, implementing a checked RSACRT signing operation, like NSS or even OpenSSL already do (despite some theoretical concerns about the effectiveness in the case of OpenSSL), seems a very reasonable hardening measure. Longer term, TLS should perhaps switch to a non-deterministic signature scheme like RSASSA-PSS. However, none of these measures will help those operators who have been using unchecked RSA-CRT implementations for years, and are now wondering if their RSA private keys have already leaked."
The findings are very similar to the classic "Ron was wrong, Whit is right" paper - if you scan the entire Internet, you will find broken hardware. You will also find SSH servers with their root password being `12345678`.