A very interesting Debian security advisory was released yesterday.
Genkin, Shamir and Tromer discovered that RSA key material could be extracted by using the sound generated by the computer during the decryption of some chosen ciphertexts.
How does this attack work? What are some possible mitigations?
This attack is a form of side-channel attack against RSA. The full details can be found in a paper published by Adi Shamir (one of three authors) of RSA fame.
The attack essentially works because a computer emits different sounds when performing different tasks. Using this information, it is possible to recover information about the RSA key during the process of encryption or decryption. When the same plaintext is encrypted with different RSA keys, the researchers were able to discern which key was used in the encryption process. This is a form of key distinguishing attack.
The interesting part about this is that the researchers were able to pull off the attack using mobile phones. This is troubling because this attack does not require specialized equipment to pull off.
While this attack is strictly theoretical at the moment, it is still interesting as side-channel attacks have been responsible for many of the attacks against RSA in the past.
Mitigation
Like the Debian advisory mentions, this attack is fixed in the newer versions of GPG.
For the oldstable distribution (squeeze), this problem has been fixed in version 1.4.10-4+squeeze4.
For the stable distribution (wheezy), this problem has been fixed in version 1.4.12-7+deb7u3.
For the unstable distribution (sid), this problem has been fixed in version 1.4.15-2.
Better yet, use the GPG 2.x branch which already employs RSA blinding that should protect against side-channel attacks.
The practical impact is nil... for now. The attack is of a type known as side channel in that it exploits an information leak, here sound emission which depends on the processed data, including the private key. Under certain conditions, the leak might be leveraged into a full key recovery, but the conditions are not easily achieved in practice. As the authors say:
To apply the attack to GnuPG, we found a way to cause GnuPG to automatically decrypt ciphertexts chosen by the attacker. The idea is to use encrypted e-mail messages following the OpenPGP and PGP/MIME protocols. For example, Enigmail (a popular plugin to the Thunderbird e-mail client) automatically decrypts incoming e-mail (for notification purposes) using GnuPG. An attacker can e-mail suitably-crafted messages to the victims, wait until they reach the target computer, and observe the acoustic signature of their decryption (as shown above), thereby closing the adaptive attack loop.
In other words it takes a rather specific context for the attack to do real damage, and it won't be discreet.
Protection against leaks is done by altering the software so that leakage no longer occurs, or, more accurately, no longer yields usable information. In the case of RSA, for modulus n, public exponent e and private exponent d, blinding is effective:
Why blinding is effective against most side-channel leaks in RSA is a matter of subtlety; but, in a hand-waving way, let's say that the added randomness of the r value (called the "mask") hides the data by preventing the attacker from modelling it: the attacker no longer knows what enters the exponentiation. It is important that a new mask r is generated for each exponentiation (to some extent, there can be shortcuts to produce sequences of masks at a lower cost, but that's tricky and usually not worth the effort). The overhead implied by blinding remains small, because the public exponent e is small.
Blinding is not the only counter-measure; to avoid leaks, one should also take care to keep the sequence of operations as fixed as possible, regardless of the data (e.g. in a classical square-and-multiply exponentiation algorithm, don't multiply conditionally; instead, always multiply, but conditionally keep the result or discard it).
