NullPointerException in DirectKeyManagementAlgorithm class

[Breur, Peter]

Dear Brian,

We intend to use JWE direct encryption with HSM-protected keys, but when attempting to do so with the jose4j library, the HSM’s refusal to extract actual key values from it, causes NullPointerExceptions.

For instance, the DirectKeyManagementAlgorithm.manageForEncrypt method throws a NullPointerException at this point:

byte[] cekBytes = managementKey.getEncoded();

I have seen Issue #39 and your answer+solution in commit 5271d54 and I understand your reasoning for being unable to prevent reading the key value when it is needed for the “AES/CBC with HMAC” authenticated encryption scheme.

However, for the AES/GCM content encryption algorithm you would not require to read and split key bytes, so for that algorithm there is an opportunity to leave everything to the HSM (which in our case has built-in support for the AES/GCM/NoPadding algorithm of course).

Would you therefore consider revising the DirectKeyManagementAlgorithm class, so that it honors the doKeyValidation switch and (at least for the AES/GCM algorithm) can work without the need for a copy of the actual key value?

Note: if you won’t find the time to fulfill this request in the near future, please say so. We will then change our application design to use AES(GCM)KW encryption instead.

Kind regards,

Peter

[Brian Campbell]

Would you mind sharing the full stack trace? I’m guessing the NPE is coming from inside the HSM’s key implementation. But would like to see it.

I think this isn’t so much about doKeyValidation but rather that some of the internal interfaces around content encryption use a byte array rather than a Key object.

[Brian Campbell]

I’d also like to see the full stack trace because the text in the issue description suggests that calling .getEncoded() on a non-exportable HSM backed symmetric key results in an NPE. But the work that was done for Issue #39 assumes that .getEncoded() on such a key returns null.

‌