JWE IV remains in JWE header

[James Holland]

Seems IV remains encoded in JWE Header in for version 4.2

The JWE format is: - BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag)

However, if using direct encryption I set a random IV (in the header), it is not removed when serializing the payload. When serializing it should be stripped from the headers

Example Code

    String key = "1234567812345678123456781234567812345678123456781234567812345678";    
    byte iv[] = getRandomIV();

    JWEHeader header = new JWEHeader.Builder(JWEAlgorithm.DIR, EncryptionMethod.A256CBC_HS512)
                                    .keyID("HID.4T.CREDS.1")
                                    .iv(Base64URL.encode(iv))
                                    .build();

    JWEObject jweObj = new JWEObject(header, new Payload((String)"Hello World!"));          
    JWEEncrypter encrypter = new DirectEncrypter(key.getBytes("UTF-8"));        
    jweObj.encrypt(encrypter);

    System.out.println("Out JWE Header ="+header);
    System.out.println("Out JWE = "+jweObj.serialize()+"\n\n\n");

    JWEObject in = JWEObject.parse(jweObj.serialize());
    System.out.println("In JWE Header= "+in.getHeader());
    System.out.println("In Enc Key= "+in.getEncryptedKey());
    System.out.println("In IV= "+in.getIV());
    System.out.println("In CT= "+in.getCipherText());
    System.out.println("In AT= "+in.getAuthTag());

Example Output

Out JWE Header ={"alg":"dir","iv":"HhAE1Hm5IqHXeawT5POUaA","enc":"A256CBC-HS512","kid":"HID.4T.CREDS.1"} Out JWE = eyJhbGciOiJkaXIiLCJpdiI6IkhoQUUxSG01SXFIWGVhd1Q1UE9VYUEiLCJlbmMiOiJBMjU2Q0JDLUhTNTEyIiwia2lkIjoiSElELjRULkNSRURTLjEifQ..VMBAcLi32IZVVSAUjJCkNQ.YqimqUdaEYr39t95nXvFGg.Jkxlw8InQioGyDU-0zVjuuUo3ITG1so6bw2zOOIQZk0

(Note if I decode the bold area I can see the IV as well as in the IV portion which comes after)

In JWE Header= {"alg":"dir","iv":"HhAE1Hm5IqHXeawT5POUaA","enc":"A256CBC-HS512","kid":"HID.4T.CREDS.1"} In Enc Key= null In IV= VMBAcLi32IZVVSAUjJCkNQ In CT= YqimqUdaEYr39t95nXvFGg In AT= Jkxlw8InQioGyDU-0zVjuuUo3ITG1so6bw2zOOIQZk0

[James Holland]

So checking the code it seems you cannot set the IV directly, as it is always generated in ContentCryptoProvider.encrypt method delegating to AESCBC/AESGCM.generateIV(random).

If the IV is set in the headers, then it should be used and then removed from the header

[Vladimir Dzhuvinov]

Hi James,

This is a somewhat unusual use of the IV header :)

The IV header is defined specifically for use in the AES/GCM key wrap, as the top-level JWE IV segment is reserved for the nonce required at the content encryption step. This allows the JWE to carry two IV values for key encryption / content encryption combos that require that. Indeed if you look at the standard list of JWE headers you will see that the IV header is not among them.

If your intent is to plug in your own random generator, you may do that via the JCAContext object of your chosen JWE encryptor.

Having said that I'll double check with the JOSE WG whether such use of the IV header is permitted and if there are any issues about that.

Vladimir

[Vladimir Dzhuvinov]

You can follow the JOSE mailing list thread here:

https://mailarchive.ietf.org/arch/msg/jose/PwgjHv-ZreStZS7Kxc4EuRuxJTc

[James Holland]

Yes agreed it is not standard, but you have shown me another way around in issue #151, so can we close this request.

FYI the scenario is that when trying to create a signature (Hmac etc) via a HSM, the round trip on one vendor for each piece of data overloads the IO bus. To get around this issue we do the hashing (SHA-256) locally in software (NSS) and then send the resultant hash to the HSM to be encrypted. We don't sign because again the RSA implementation in the HSM is too slow. All we are after is a proof of integrity of the data (the hash) and the proof the hash has not been tampered with (the encryption). So for the encryption piece the IV should be constant on a signature generation. For anything else it would be a random IV.

Basically I'm trying to work around HSM bus IO issues as best we can.

[Vladimir Dzhuvinov]

Thanks for sharing this. It's a fascinating solution :) Do you mind if I add this to the library FAQ page?

[James Holland]

Yes of course this can go on FAQ page :-)