Hi Vladimir,
you are right, the random number generation *must not* be done in the
catch block, it could be measured and leak an information about
ciphertext validity.
I would propose this code:
if (alg.equals(JWEAlgorithm.RSA1_5)) {
int keyLength = cmkBitLength(readOnlyJWEHeader.getEncryptionMethod());
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;
}
}
This would be perfect and also secure against timing attacks.
Regards
Juraj
On 03/25/2013 03:02 PM, Vladimir Dzhuvinov / NimbusDS wrote:
> Hi guys,
>
> Just checked in a simple counter measure as suggested below, should
> become part of the new release, probably sometime later this week.
>
> https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/da13ee89febda936b234a76da3f330e39970c240/src/main/java/com/nimbusds/jose/crypto/RSADecrypter.java?at=master#cl-138
>
> The actual random CMK generation also does take time to do, I suppose
> that also has to be measured and taken into account?
>
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov : www.NimbusDS.com : [email protected]
>
>
> -------- Original Message --------
> Subject: Re: [jose] backwards compatibility attack on JWT impls (was:
> I-D Action: draft-ietf-jose-json-web-algorithms-02.txt)
> From: Brian Campbell <[email protected]>
> Date: Fri, March 15, 2013 8:03 pm
> To: Juraj Somorovsky <[email protected]>
> Cc: Tibor Jager <[email protected]>, Mike Jones
> <[email protected]>, =JeffH <[email protected]>,
> IETF JOSE WG <[email protected]>
>
> +1
>
>
> Thanks Juraj.
>
>
> On Thu, Mar 14, 2013 at 5:52 PM, Juraj Somorovsky
> <[email protected]> wrote:
>
> Generally, such an attack could be of course *mitigated* by generating
> random CMKs, when the RSA1_5 is invalid. Thus, I would propose to
> reference Eric's
> https://tools.ietf.org/rfc/rfc3218.txt
> in your security considerations. Maybe, it would be even better to
> explicitly sketch these countermeasures as done in TLS1.2
> (http://www.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.)
>
> Regards
> Juraj
>
>
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
