Considering blacklist of PKCS 1.5 in SP 2.5

Cantor, Scott cantor.2 at osu.edu
Fri Jul 27 13:48:59 EDT 2012


We've had some discussion of this privately on the committers list, and
with the consensus leaning towards doing this, I'm bringing the discussion
to the dev list.

The normal encryption technique in SAML is that you generate a data
encryption key to use for a message, and then you encrypt the key with the
public key of the peer, normally the SP. That step gets done with one of
two RSA key transport algorithms, PKCS 1.5 or PKCS 2.0 (also called
RSA-OAEP).

A couple of years ago, a paper was published demonstrating practical
attacks on PKCS 1.5 that have some mitigations, which we implemented. Now
another paper[1] has been published that manages to attack OAEP by using a
downgrade attack that substitutes PKCS 1.5 in the message.

The only mitigations to this are things that are going to take a lot of
time to pull off, either getting every IdP to start signing its Response
messages *and* every SP to require it, or deploying a new symmetric
encryption mode that is very rarely supported on most platforms.

OTOH, turning off PKCS 1.5 can be done very easily using a blacklist, and
easily undone if its necessary for some site. It should also be relatively
easy to see in a log file as an error.

The implications of this for interoperability are impossible to say for
certain, but we believe that *most* implementations out there use PKCS 1.5
only when using 3DES keys, which are not a common default. Most AES keys
are wrapped using the OAEP method. Shibboleth IdPs have never used
anything but AES and OAEP by default and don't currently even support
algorithm manipulation using configuration.

There is one apparent exception: simpleSAML.php uses PKCS 1.5 with AES
keys. It's apparently a simple change to make it use OAEP, but it's not
doing that at the moment. Our feeling is that this latest attack
demonstrates a need for them to make that change, and that we need to do
the responsible thing and turn this off by default going forward.

There would be additional communication highlighting this change if we do
it, obviously.

-- Scott

[1] 
http://www.nds.rub.de/research/publications/breaking-xml-encryption-pkcs15/



More information about the dev mailing list