Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt)

["Juraj Somorovsky" <[e-mail]>]

On 03/26/2013 02:30 AM, Manger, James H wrote:
>>>> 	SecretKey randomCMK = AES.generateAESCMK(keyLength);
>>>>
>>>> 	try {
>>>> 		cmk = RSA1_5.decryptCMK(privateKey, encryptedKey.decode(),
>>>> keyLength);
>>>> 	} catch (Exception e) {
>>>> 		// Protect against MMA attack by generating random CMK on
>> failure,
>>>> 		// see http://www.ietf.org/mail-
>>>> archive/web/jose/current/msg01832.html
>>>> 		cmk = randomCMK;
>>>> 	}
>>>> }
>>>>
> For a start the fixes need to be much lower down where the PKCS#1 padding is first handled, not way up the stack were you see an exception vs a normal return.
> 
> The Go language appears to have code with decent protections to avoid leaking crucial timing details: http://golang.org/src/pkg/crypto/rsa/pkcs1v15.go.
> 
> The Java code I found in a quick search (sun.security.rsa.RSAPadding#unpadV15) makes no effort to be constant time. I doubt there is anything (reasonable) that can be done at a higher layer (such as com.nimbusds.jose.crypto.RSA1_5) to make RSAES-PKCS1-V1_5 safe with that foundation.
> [http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/security/rsa/RSAPadding.java#RSAPadding.unpadV15%28byte%5B%5D%29]
Such countermeasures are very precise, but are also very difficult to
implement. I do not think they are necessary to implement against the
state-of-the art timing attacks. I would say the countermeasure that I
presented is enough and would thwart practical Bleichenbacher timing
attacks.

Regards
Juraj