OASIS PKCS 11 TC

Attachment: smime.p7m Description: S/MIME encrypted message

Resending proposal without signature enabled for proper archival in the public domain.  Apologies about the delay, as I was on vacation.   Hi,   A concern was raised on the wiki around extraction attacks (more specifically a padded oracle/Bleichenbaucher style attack).  In general the protection lies in selection of the correct scheme to protect against it.  There have also been subsequent papers with improvements to the attack, hence the recommendation below.   I propose a suggested best practice/recommendation of:   "To protect against chosen ciphertext attacks, like the Bleichenbacher attack, use PKCS #1 Version 2, with OAEP, and disable support for PKCS #1, Version 1.5."   Furthermore, more specifically to smart card implementations, the requirement of the PIN and a long open connection to the device is required to execute the attack.  If there is a need to address this, then I propose the suggested best practice/recommendation of: “For smartcard implementations, execution of these attacks require private key operations and a sufficiently long open connection. It is strongly recommended that any applets exposing private key operations are protected using an encrypted PIN (a PIN not submitted in the clear), and the session is closed when not in use.“   Thanks, Chris Duane     From: pkcs11@lists.oasis-open.org [ mailto:pkcs11@lists.oasis-open.org ] On Behalf Of Duane, Chris Sent: Friday, May 31, 2013 11:40 AM To: pkcs11@lists.oasis-open.org Subject: [pkcs11] Proposal for recommendation/best practice on protection against Padded Oracle attacks   Hi,   A concern was raised on the wiki around extraction attacks (more specifically a padded oracle/Bleichenbaucher style attack).  In general the protection lies in selection the correct scheme to protect against it.  There have also been subsequent papers with improvements to the attack, hence the recommendation below.   I propose a suggested best practice/recommendation of:   "To protect against chosen ciphertext attacks, like the Bleichenbacher attack, use PKCS #1 Version 2, with OAEP, and disable support for PKCS #1, Version 1.5."   More specifically to smart card implementations, the requirement of the PIN and a long open connection to the device is required to execute the attack.  I would be interested if people feel we should provide recommendations around protection of the PIN, and management of the connection to the device or if this is out of scope for this conversation.  In these kind of attacks, where the PIN is required, I often point out that if you have the PIN you don’t need to extract the private key, as you can simply make use the private key (agreed extraction is more useful in offline/disconnected attacks).   Comments?   Thanks, -chris

Chris, Regarding disable support for PKCS #1, Version 1.5 , does it include disabling support for PKCS #1 v1.5 Signature Scheme ? Or, it is just referring to PKCS #1 v1.5 Encryption Scheme ? Thanks, Oscar On 06/24/13 07:12 AM, Duane, Chris wrote: Resending proposal without signature enabled for proper archival in the public domain.  Apologies about the delay, as I was on vacation.   Hi,   A concern was raised on the wiki around extraction attacks (more specifically a padded oracle/Bleichenbaucher style attack).  In general the protection lies in selection of the correct scheme to protect against it.  There have also been subsequent papers with improvements to the attack, hence the recommendation below.   I propose a suggested best practice/recommendation of:   To protect against chosen ciphertext attacks, like the Bleichenbacher attack, use PKCS #1 Version 2, with OAEP, and disable support for PKCS #1, Version 1.5.   Furthermore, more specifically to smart card implementations, the requirement of the PIN and a long open connection to the device is required to execute the attack.  If there is a need to address this, then I propose the suggested best practice/recommendation of: “For smartcard implementations, execution of these attacks require private key operations and a sufficiently long open connection. It is strongly recommended that any applets exposing private key operations are protected using an encrypted PIN (a PIN not submitted in the clear), and the session is closed when not in use.“   Thanks, Chris Duane     From: pkcs11@lists.oasis-open.org [ mailto:pkcs11@lists.oasis-open.org ] On Behalf Of Duane, Chris Sent: Friday, May 31, 2013 11:40 AM To: pkcs11@lists.oasis-open.org Subject: [pkcs11] Proposal for recommendation/best practice on protection against Padded Oracle attacks   Hi,   A concern was raised on the wiki around extraction attacks (more specifically a padded oracle/Bleichenbaucher style attack).  In general the protection lies in selection the correct scheme to protect against it.  There have also been subsequent papers with improvements to the attack, hence the recommendation below.   I propose a suggested best practice/recommendation of:   To protect against chosen ciphertext attacks, like the Bleichenbacher attack, use PKCS #1 Version 2, with OAEP, and disable support for PKCS #1, Version 1.5.   More specifically to smart card implementations, the requirement of the PIN and a long open connection to the device is required to execute the attack.  I would be interested if people feel we should provide recommendations around protection of the PIN, and management of the connection to the device or if this is out of scope for this conversation.  In these kind of attacks, where the PIN is required, I often point out that if you have the PIN you don’t need to extract the private key, as you can simply make use the private key (agreed extraction is more useful in offline/disconnected attacks).   Comments?   Thanks, -chris -- Best, Oscar

Hi Oscar,   The recommendation to use OAEP (optimal asymmetric encryption padding), as the name implies, is referring to a padding scheme for encryption.  Essentially the attack in question is a side channel attack against the padding, and moving to v2 with OAEP itself is not sufficient unless you also disable support for 1.5.   Thanks, -chris   From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Oscar K So Jr. Sent: Wednesday, June 26, 2013 5:12 AM To: pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] Proposal for recommendation/best practice on protection against Padded Oracle attacks   Chris, Regarding " disable support for PKCS #1, Version 1.5" , does it include disabling support for PKCS #1 v1.5 Signature Scheme ? Or, it is just referring to PKCS #1 v1.5 Encryption Scheme ? Thanks, Oscar On 06/24/13 07:12 AM, Duane, Chris wrote: Resending proposal without signature enabled for proper archival in the public domain.  Apologies about the delay, as I was on vacation.   Hi,   A concern was raised on the wiki around extraction attacks (more specifically a padded oracle/Bleichenbaucher style attack).  In general the protection lies in selection of the correct scheme to protect against it.  There have also been subsequent papers with improvements to the attack, hence the recommendation below.   I propose a suggested best practice/recommendation of:   "To protect against chosen ciphertext attacks, like the Bleichenbacher attack, use PKCS #1 Version 2, with OAEP, and disable support for PKCS #1, Version 1.5."   Furthermore, more specifically to smart card implementations, the requirement of the PIN and a long open connection to the device is required to execute the attack.  If there is a need to address this, then I propose the suggested best practice/recommendation of: “For smartcard implementations, execution of these attacks require private key operations and a sufficiently long open connection. It is strongly recommended that any applets exposing private key operations are protected using an encrypted PIN (a PIN not submitted in the clear), and the session is closed when not in use.“   Thanks, Chris Duane     From: pkcs11@lists.oasis-open.org [ mailto:pkcs11@lists.oasis-open.org ] On Behalf Of Duane, Chris Sent: Friday, May 31, 2013 11:40 AM To: pkcs11@lists.oasis-open.org Subject: [pkcs11] Proposal for recommendation/best practice on protection against Padded Oracle attacks   Hi,   A concern was raised on the wiki around extraction attacks (more specifically a padded oracle/Bleichenbaucher style attack).  In general the protection lies in selection the correct scheme to protect against it.  There have also been subsequent papers with improvements to the attack, hence the recommendation below.   I propose a suggested best practice/recommendation of:   "To protect against chosen ciphertext attacks, like the Bleichenbacher attack, use PKCS #1 Version 2, with OAEP, and disable support for PKCS #1, Version 1.5."   More specifically to smart card implementations, the requirement of the PIN and a long open connection to the device is required to execute the attack.  I would be interested if people feel we should provide recommendations around protection of the PIN, and management of the connection to the device or if this is out of scope for this conversation.  In these kind of attacks, where the PIN is required, I often point out that if you have the PIN you don’t need to extract the private key, as you can simply make use the private key (agreed extraction is more useful in offline/disconnected attacks).   Comments?   Thanks, -chris --   Best, Oscar

On 6/26/2013 10:48 AM, Duane, Chris wrote: Hi Oscar,   The recommendation to use OAEP (optimal asymmetric encryption padding), as the name implies, is referring to a padding scheme for encryption.  Essentially the attack in question is a side channel attack against the padding, and moving to v2 with OAEP itself is not sufficient unless you also disable support for 1.5.   Thanks, -chris Hi Chris - So to answer Oscar's question - this is for encryption only. I found an article that suggests that even OAEP is susceptible to side channel attacks against padding. The more general guidance - and this is in line with NIST's FIPS 140-2 stuff - is that a given RSA key pair should only be used for either signature/verify or encrypt/decrypt and not both; and that it should be used with one and only one padding scheme. That sounds like a usage guide thing to me rather than putting it into the mandatory enforcement by token category. Later, Mike

Hi Mike,   The article you are (I think) referring to is an improvement to the attack, and the mitigation against the improvement is to disallow support for v1.5.  If we recommended only to use v2 with OAEP, it would not be enough.  That is why the recommendation is to both move to v2 and to disallow v1.5.  While you may intend to follow the “should be used with one padding scheme” if the PKCS11 implementation allows for both padding schemes to be used, you are still vulnerable (the attacker won’t be as nice).   I have no preference in where it should go, so the usage guide is fine with me.   Thanks, -chris     From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Michael StJohns Sent: Wednesday, June 26, 2013 3:24 PM To: pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] Proposal for recommendation/best practice on protection against Padded Oracle attacks   On 6/26/2013 10:48 AM, Duane, Chris wrote: Hi Oscar,   The recommendation to use OAEP (optimal asymmetric encryption padding), as the name implies, is referring to a padding scheme for encryption.  Essentially the attack in question is a side channel attack against the padding, and moving to v2 with OAEP itself is not sufficient unless you also disable support for 1.5.   Thanks, -chris   Hi Chris - So to answer Oscar's question - this is for encryption only. I found an article that suggests that even OAEP is susceptible to side channel attacks against padding. The more general guidance - and this is in line with NIST's FIPS 140-2 stuff - is that a given RSA key pair should only be used for either signature/verify or encrypt/decrypt and not both; and that it should be used with one and only one padding scheme. That sounds like a usage guide thing to me rather than putting it into the mandatory enforcement by token category. Later, Mike

On Mon, Jun 24, 2013 at 7:12 AM, Duane, Chris <chris.duane@rsa.com> wrote: > > A concern was raised on the wiki around extraction attacks (more > specifically a padded oracle/Bleichenbaucher style attack). Nit: this attack is usually called a "padding oracle" as opposed to a "padded oracle". > I propose a suggested best practice/recommendation of: > > "To protect against chosen ciphertext attacks, like the Bleichenbacher > attack, use PKCS #1 Version 2, with OAEP, and disable support for PKCS #1, > Version 1.5." This is a good recommendation in general. You may want to point out that TLS (versions 1.0 - 1.2) still uses PKCS #1 v1.5 encryption for the cipher suites that use the RSA key exchange method. Wan-Teh Chang