Support for EC crypto?

[Stefan Santesson]

On 14/09/15 15:41, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>>Well I do fault them. Correct me if I’m wrong, but the main reason for using GCM over CBC is the added data integrity protection.
>
>Well, yes, but it's the added "this algorithm isn't broken" protection more than anything.

That is a good point.

>
>> But they also required signed responses, to the cipher text is already authenticated before you attempt to decrypt it.
>
>Only if the SP actually enforces that requirement. Most don't. 

Understood. I see this entirely from the context of the EU specifications, and they do require this to be enforced.

>
>> Also. The attacks I have seen on CBC requires that you successfully can submit altered variants of the same cipher text repeatedly and track if the decryption resulted in valid datablocks. This is all good in theory, but can be prevented on so many levels in a complex protocol like SAML, where signing the response is just one of them.
>
>I'm not aware of any such mitigations in SAML. CBC is considered broken in that context, and signed responses are the only mitigation I know of.

I did an analysis on this after a security review we had.
The analysis was based on out SAML profile, which influences the result.

We do require either signed response or signed assertion or both.
If response is signed the attack fails.

If the assertion is signed, then bit-flipping will cause a failed assertion signature.
So the attack will not be able to hand the SP faulty data.

So the final threat analysed was whether it would be possible to decrypt the assertion by repeatedly sending the encrypted assertion to the SP and monitoring whether the decryption process failed or not, based on timing or data returned from the SP.

One way to make this a lot harder is if SP:s are required to deny unsolicited responses, always matches ID:s of requests to InResponseTo and checks for duplicates.
Adding to this is the fact that if the bad guy gets their hand on an IdP response before it has been used, then we have already lost as it is a bearer token.


But I give you right that this is not the ideal way to mitigate crypto weaknesses. I would also like to see the use of good AEAD crypto modes, making the design more robust.
I just think it is too soon to require this in an interop profile, given the current state of support.

/Stefan



>