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

C_DestroyObject fails with CKR_ACTION_PROHIBITED when trying to delete key pair #381

Open
tougantium opened this issue Jun 19, 2024 · 2 comments

Comments

@tougantium
Copy link

After generating a key pair with C_GenerateKeyPair a call to C_DestroyObject fails with CKR_ACTION_PROHIBITED. The reason seems to be the check if PKCS11_OBJECT_FLAG_DESTROYABLE is set in the pkcs11_object_destroy function (which obviously is not the case). The flag is set when the key pair is created in the pkcs11_config_key function, but seems to be overridden later with pObject->flags = PKCS11_OBJECT_FLAG_KEY_CACHE; in the pkcs11_config_init_private function - this change was introduced with v3.7.3 of cryptoauthlib.

Changing the above line to pObject->flags |= PKCS11_OBJECT_FLAG_KEY_CACHE; only partially fixes the problem. The 0.2.conf file is deleted from the filesystem, but in an internal cache of cryptoauthlib the key pair still seems to be there - at least I can still load the key after deleting it (if still in the same running process) and don't get an error.

@Srinivas-E
Copy link
Collaborator

Hi @tougantium ,
Thank you for reporting this issue.
We shall work on this in our upcoming releases and keep the thread updated with progress.

@AriyaKrishnanAK
Copy link

Hi @tougantium , We tried to reproduce the issue that you stated. Observed that C_DestroyObject fails with CKR_ACTION_PROHIBITED. Thank you for your observations. The fix for it will be incorporated in the next release.
About the second part of the issue where you have mentioned that in an internal cache of cryptoauthlib the key pair still seems to be there, can you give some clarity on this. After deleting the object it cannot be used any usage will lead to CKR_OBJECT_HANDLE_INVALID(82), which is the expected behavior

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

No branches or pull requests

3 participants