There seems to be a bit of uncertainty about this attack. I'm hearing a lot of misunderstanding from customers. Here is my summary. I'll first give a concrete example explaining key wrap and unwrap. Skip this post if you know all this stuff. Then I'll generalize a bit, and finally comment on RSA's response.
Suppose that you have a symmetric key (eg a KEK) in one HSM that you want to transport to another HSM. The target HSM generates an RSA private key, and you send the cert off to the first HSM, where you wrap (encrypt) the symmetric key under that cert. You take this wrapped key across to the target HSM. There, you "unwrap" it, which means that you send the encrypted blob into the target HSM, which internally decrypts the symmetric key and stores it, but does not give you back the plain symmetric key. If the target HSM notices that the encrypted blob is corrupted, then it will give you an error message. This is a leak of information, but that's life. Normally such a covert channel would at most help you to mount a brute force attack, which is impractical owing to the size of the key space and other things. However, if the target HSM allows you to ask it to unwrap (decrypt) the key under the assumption that pkcs v1.5 padding has been used, then by careful manipulation of the encrypted blob, you can use the failed decryptions to deduce the plain key, after only a few thousand submissions. It does not matter whether the symmetric key was encrypted using the pkcs1 v1.5 padding. (Matthew Green mentioned this in his post.) The flaw in the HSM is that it will attempt to use the deprecated padding during the decryption. Loosely, it looks for certain bytes and tells you whether it found them. It also does not matter whether you are using pkcs11 APIs, and whether you are doing key wrap/unwrap, and whether the data is a key. Any secret piece of data encrypted under an RSA cert can be potentially extracted, via any kind of crypto module, as long as the module will use the deprecated padding mechanism. It also does not matter whether the device is actually a device. An SSL server that will decrypt things assuming pkcs1 v1.5 padding, and give failure messages, is potentially vulnerable (this has been known for a decade). Various USB tokens have played the role of the HSM in the recent research. How have RSA Corp. personned up? The RSA blog said: "The vulnerability outlined by the researchers makes it possible (however unlikely) that an attacker with access to the user’s smartcard device and the user’s smartcard PIN could gain access to a symmetric key or other encrypted data sent to the smartcard." This is a fairish statement. Though I think "unlikely" needs clarifying. It's not that common for end users to do the importation onto such a device that leads to the attack, so in that sense it's unlikely. However, if you do do such an import, the attack is likely. I can certainly imagine provisioning scenarios that are vulnerable, though I can't say if people are actually doing them. So I'd say that anyone using the tokens for this sort of thing should be warned immediately. Also, the RSA blogger should have been a little more candid and conceded that they have been remiss, and said what they will do to fix it. Later, they quote the token team: "This is not a useful attack. The researchers engaged in an academic exercise to point out a specific vulnerability in the protocol, but an attack requires access to the RSA SecurID 800 smartcard (for example, inserted into a compromised machine) and the user’s smartcard PIN. If the attacker has the smart card and PIN, there is no need to perform any attack, so this research adds little additional value as a security finding." This is quite false. The legitimate owner of the token, or a security officer provisioning the token, can get information (marked unextractable) he is not supposed to get, PIN or no PIN. There are definite real world scenarios in which this attack is a serious break. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
