Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unwrapped AES keys have VALUE_LEN set to 0 #628

Open
ceridwen opened this issue Apr 16, 2021 · 4 comments · May be fixed by #650
Open

Unwrapped AES keys have VALUE_LEN set to 0 #628

ceridwen opened this issue Apr 16, 2021 · 4 comments · May be fixed by #650

Comments

@ceridwen
Copy link

I'm using the Python PKCS (https://github.com/danni/python-pkcs11) library to unwrap some AES keys wrapped by another HSM. While the unwrapping process seems to work (no error from the library or in SoftHSM's debug logs), CKA_VALUE_LEN for these (256 bit) keys seems to be 0:

            example_unwrapping_test = example_wrapping_softhsm.unwrap_key(pkcs11.ObjectClass.SECRET_KEY, pkcs11.KeyType.AES, example_blob, mechanism=pkcs11.Mechanism.RSA_PKCS_OAEP, store=True, label='example-unwrapping-test', template={
            pkcs11.Attribute.SENSITIVE: False,
            pkcs11.Attribute.EXTRACTABLE: True,
        })
        except Exception as error:
            print(error)
            print(vars(error))
            raise
        print(example_unwrapping_test)
        print(len(example_unwrapping_test[pkcs11.Attribute.VALUE]))
        print(example_unwrapping_test[pkcs11.Attribute.VALUE_LEN])
<SecretKey label='example-unwrapping-test' id='' 0-bit AES>
32
0

The actual bytes of the test key are the right length (32) and do have the same value as the test key before it was wrapped.

The standard implies that, at least for RSA_OAEP, CKA_VALUE_LEN for these keys should come from the mechanism: "[T]he mechanism contributes only the CKA_CLASS and CKA_VALUE (and CKA_VALUE_LEN, if the key has it) attributes to the recovered key during unwrapping." I see this when unwrapping an AES key wrapped with CKM_AES_KEY_WRAP_PAD too.

@rijswijk
Copy link
Contributor

Have you explicitly included the CKA_VALUE_LEN attribute in the (optional) unwrapping template? If I look at the code, that should do the trick.

@ceridwen
Copy link
Author

It looks like when I try to set that field, SoftHSM is telling me that the attribute is read-only:

Traceback (most recent call last):
  File "offline_example.py", line 542, in <module>
    'example-wrapped',
  File "offline_example.py", line 307, in unwrap_key
    pkcs11.Attribute.VALUE_LEN: 256,
  File "pkcs11/_pkcs11.pyx", line 1276, in pkcs11._pkcs11.UnwrapMixin.unwrap_key
  File "pkcs11/_errors.pyx", line 88, in pkcs11._pkcs11.assertRV
pkcs11.exceptions.AttributeReadOnly

@rijswijk
Copy link
Contributor

OK, I had a better look at the code and it looks like you are right, CKA_VALUE_LEN is not set on C_Unwrap(..), let me check if this needs fixing or not (the attribute isn't used internally by the code, only the value of the key itself is used).

keldonin added a commit to keldonin/SoftHSMv2 that referenced this issue Sep 23, 2021
@keldonin keldonin linked a pull request Sep 23, 2021 that will close this issue
@dcoombs
Copy link
Contributor

dcoombs commented Jun 2, 2022

Fwiw, I ran into this issue myself yesterday, and confirm that PR #650 fixed it. Thanks!

@jschlyter jschlyter linked a pull request Nov 29, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants