[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Proposal for recommendation/best practice on protection against Padded Oracle attacks
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 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]