Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
Hello, On Tue, Jul 3, 2012 at 1:56 AM, Michael Nelson nelson_mi...@yahoo.com wrote: 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. If you deal with HSM-s and transporting keys, you probably have decent procedures in addition to more carefully chosen cipher modes. I would consider walking away with the HSM(-s) in question instead, if possible and allowed. 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. If asked to. In addition it will give you the OAEP-wrapped imported symmetric key back, encrypted against a weak key pair generated yourself with OpenSSL, if *asked to*. 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. That's a very broad claim. I guess nobody has questioned the fact that the authors of the paper optimized a long-known weakness to become useful, *if the conditions are right*. Like uncontrolled access to C_UnwrapKey or C_Decrypt (in terms of PKCS#11, as this is what the authors are using). It all works, if the module functions as an oracle that can be exploited by the adversary. I don't know the SecureID token, but I do know some other tokens described in the paper. Any reasonable token would do owner PIN verification before trying to decrypt. 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. Common end users don't call C_UnwrapKey that often. Thinking of a common procedure that would call for C_Decrypt, could be S/MIME. And common people don't control the format of the sender either - if you get a PKCS#1 padded message, you need to decrypt that. Last time I checked, Thunderbird by default does PKCS#1 v1.5. 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. As the paper deals with PKCS#11, which is a software API, it can tell much more about host-side software errors than what is happening on device. PKCS#11 is like ISO7816: it describes a lot but leaves many things optional or outside the scope of the given document. Have a look at chapter 7 in PKCS#11 v2.20. PKCS#11 is a *software API* that is usually used to access a given device, implemented to support the capabilities of the device. Thinking that the flags set or queried through PKCS#11 (in fact, sensitive in this example, as not extractable should mean a key which you can't C_WrapKey in the beginning) would actually matter outside the scope of the single module it targets, is foolish. Think about it: for a non-repudiation key, generated with OpenSSL and imported into a device, that displays never extractable through PKCS#11, would it suffice? I hope not. Needless to say that there
Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
On Thu, Jul 5, 2012 at 9:17 AM, Martin Paljak mar...@martinpaljak.net wrote: On Tue, Jul 3, 2012 at 1:56 AM, Michael Nelson nelson_mi...@yahoo.com wrote: 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. That's a very broad claim. I guess nobody has questioned the fact that the authors of the paper optimized a long-known weakness to become useful, *if the conditions are right*. Like uncontrolled access to C_UnwrapKey or C_Decrypt (in terms of PKCS#11, as this is what the authors are using). It all works, if the module functions as an oracle that can be exploited by the adversary. I don't know the SecureID token, but I do know some other tokens described in the paper. Any reasonable token would do owner PIN verification before trying to decrypt. Access controls are a mitigation. There is no guarantee that the attacker doesn't have access. Note that if the attacker does have access they still have incentive to extract the actual keys: so they can continue to use them even if they lose access, and so they can avoid auditing facilities on the HSM/token. Mitigations do not detract from the cryptanalytic result. It's time to stop using weak padding signature algs. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
Noon Silk wrote: From: http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html Here's the postage stamp version: due to a perfect storm of (subtle, but not novel) cryptographic flaws, an attacker can extract sensitive keys from several popular cryptographic token devices. This is obviously not good, and it may have big implications for people who depend on tokens for their day-to-day security. [...] The more specific (and important) lesson for cryptographic implementers is: if you're using PKCS#1v1.5 padding for RSA encryption, cut it out. Really. This is the last warning you're going to get. Direct link to the paper: http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf - Efficient Padding Oracle Attacks on Cryptographic Hardware by Bardou, Focardi, Kawamoto, Simionato, Steel and Tsay Thanks for this link. The paper is self-explanatory, at least to someone who has followed the factoring-based public key cryptography resistance to CCA (chosen ciphertext attack) for a while. Here is the main theoretical contribution: At the heart of our techniques is a small but significant theorem that allows not just multiplication (as in the [Bleichenbacher’s well-known attack] attack) but also division to be used to manipulate a PKCS#1 v1.5 ciphertext and learn about the plaintext. The paper reports findings from extensive experiments with the attacks. The paper is thus a very significant contribution. Take care my friends, meaning that is you see yourself as an applied cryptographer, spot the oracle. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
On Mon, Jul 2, 2012 at 1:56 AM, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Jun 30, 2012 at 11:11 PM, Noon Silk noonsli...@gmail.com wrote: From: http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html [snip] Direct link to the paper: http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf - Efficient Padding Oracle Attacks on Cryptographic Hardware by Bardou, Focardi, Kawamoto, Simionato, Steel and Tsay RSA says that its tokens are secure, http://www.h-online.com/security/news/item/RSA-says-that-its-tokens-are-secure-1627326.html After a significantly improved attack on crypto hardware made the news, RSA's Sam Curry has said that the affected SecurID 800 token is secure. The token has not been cracked, and the attack is not useful, explained Curry, adding that the attack does not allow private RSA keys to be extracted from the token. Curry's actual blog post http://blogs.rsa.com/curry/dont-believe-everything-you-read-your-rsa-securid-token-is-not-cracked/ gives a bit more additional info that I didn't see mentioned in _The H Security_ article. In particular, it fails to mention this: *Utilize PKCS #1 v2.0 with OAEP in applications that require encryption.* It has been RSA’s position for some time that customers should utilize the higher PKCS #1 v2.0 standard with OAEP, which is not subject to this type of vulnerability. The RSA SecurID 800 technology supports this standard. So it would seem to me that those using the SecurID 800 with PKCS #1 v1.5 only have themselves to blame??? I suspect that PCSC#1 v1.5 is still supported by SecurID 800 tokens for backward compatibility mode, and so yes, there are likely lots of RSA customers who are still running things that way. But if it supports PKCS#1 v2.0 and OAEP padding schemes and their customers are not using it, then I fail to see how the vendor is to blame. (Unless they have it default to v1.5. Anyone know?) Also, this supposedly does not affect SecurID authentication tokens, but only the smartcard functionality. [Wasn't RSA caught lying about their breach also? Didn't they claim the phishing campaign was an APT?] Well, spin-doctoring, for sure. There was a phishing campaign that started it all, but according to sources inside of RSA, it was a spear phishing attack aimed at only 7 or so different RSA employees in HR. The email addresses were forged to appear as it it were coming from a trusted contracting company that they did business with and the attached Excel spreadsheet had a 0day Adobe Flash exploit. After listening to the complete inside story, where I found fault with RSA was: 1) They were escrowing the SecurID seeds, often without their customers explicit knowledge. (Presumably it was in the fine print of the contract that most customers probably did not read and there supposedly was an opt-out policy, but it really should have been an opt-in.) 2) RSA decided to eliminate their air gap where they previously had a manual swivel chair process where they burned CD-ROMs to recover lost seeds to send to their customers and replaced that with a web interface. RSA claims it was a business decision that was encouraged by their customers. (Note: The air gap has since been restored.) Of course the whole APT term itself is IMO somewhat misnamed. I think a better term would be Targeted Persistent Threat, but of course that would not allow as much spin doctoring, which is why we are probably stuck with the APT term. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
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
Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
On Sat, Jun 30, 2012 at 11:11 PM, Noon Silk noonsli...@gmail.com wrote: From: http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html Here's the postage stamp version: due to a perfect storm of (subtle, but not novel) cryptographic flaws, an attacker can extract sensitive keys from several popular cryptographic token devices. This is obviously not good, and it may have big implications for people who depend on tokens for their day-to-day security. [...] The more specific (and important) lesson for cryptographic implementers is: if you're using PKCS#1v1.5 padding for RSA encryption, cut it out. Really. This is the last warning you're going to get. Direct link to the paper: http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf - Efficient Padding Oracle Attacks on Cryptographic Hardware by Bardou, Focardi, Kawamoto, Simionato, Steel and Tsay Thanks for the link, Noon. So I'm clear here: this applies to RSA Encryption. Are RSA Signatures still safe when using PKCS v1.5 padding? Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
On Sun, Jul 1, 2012 at 6:31 PM, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Jun 30, 2012 at 11:11 PM, Noon Silk noonsli...@gmail.com wrote: From: http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html Here's the postage stamp version: due to a perfect storm of (subtle, but not novel) cryptographic flaws, an attacker can extract sensitive keys from several popular cryptographic token devices. This is obviously not good, and it may have big implications for people who depend on tokens for their day-to-day security. [...] The more specific (and important) lesson for cryptographic implementers is: if you're using PKCS#1v1.5 padding for RSA encryption, cut it out. Really. This is the last warning you're going to get. Direct link to the paper: http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf - Efficient Padding Oracle Attacks on Cryptographic Hardware by Bardou, Focardi, Kawamoto, Simionato, Steel and Tsay Thanks for the link, Noon. So I'm clear here: this applies to RSA Encryption. Are RSA Signatures still safe when using PKCS v1.5 padding? Cancel. I got to one of my text books to look up RSA Signatures. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html To avoid padding oracle attacks, always use authenticated encryption, such that a corrupted message always generates the same response in the same time. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5
On Sat, Jun 30, 2012 at 11:11 PM, Noon Silk noonsli...@gmail.com wrote: From: http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html Here's the postage stamp version: due to a perfect storm of (subtle, but not novel) cryptographic flaws, an attacker can extract sensitive keys from several popular cryptographic token devices. This is obviously not good, and it may have big implications for people who depend on tokens for their day-to-day security. [...] The more specific (and important) lesson for cryptographic implementers is: if you're using PKCS#1v1.5 padding for RSA encryption, cut it out. Really. This is the last warning you're going to get. Direct link to the paper: http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf - Efficient Padding Oracle Attacks on Cryptographic Hardware by Bardou, Focardi, Kawamoto, Simionato, Steel and Tsay RSA says that its tokens are secure, http://www.h-online.com/security/news/item/RSA-says-that-its-tokens-are-secure-1627326.html After a significantly improved attack on crypto hardware made the news, RSA's Sam Curry has said that the affected SecurID 800 token is secure. The token has not been cracked, and the attack is not useful, explained Curry, adding that the attack does not allow private RSA keys to be extracted from the token. ... [Wasn't RSA caught lying about their breach also? Didn't they claim the phishing campaign was an APT?] ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
