search

aws-samples / aws-cloudhsm-jce-examples

Sample applications demonstrating how to use the CloudHSM JCE
MIT No Attribution
37 stars 57 forks source link

No way to specify algorithm for generic secret key #88

Open mnylen opened 5 months ago

mnylen commented 5 months ago

Some libraries like the popular jjwt for JSON web tokens assume that, when signing/verifying with HS256 algorithm, that the SecretKey#getAlgorithm() returns HmacSHA256

However, loading a generic secret key from CloudHSM KeyStore returns a SecretKey where getAlgorithm() returns GenericSecret. Is there a way to supply the "intended use" algorithm for the key somehow?

TheEmpty commented 5 months ago

The javadoc for getEncoded specifies that keys that do not support encoding should return null. Throwing an exception may cause issues for other libraries that expect this behavior. JJWT should have additional logic around keys that return null in getEncoded or getFormat to be spec compliant.

We don't provide a way to override the response from getAlgorithim today.

mnylen commented 5 months ago

Hey! Yes, that makes sense (I think you answered the AesKey question here) - I also agree that getEncoded() returning null should be handled in the library. I actually read the javadoc only after asking the question, so that can be closed.

As for the getAlgorithm() returning GenericSecret, it's a bit kludge to support that in libraries, as there's no "standard" for this, and I'm wondering if there was to be support for the CloudHSM variety of generic secret in JJWT, would they need to also support some other providers generic secrets in the future, which might not have GenericSecret algorithm, but something else. For example, they have a special case for Sun PKCS#11 secret keys already, and for those the algorithm is Generic Secret with space in between.

Would be thus nice to have some way of overriding the algorithm.