node-webcrypto-p11
node-webcrypto-p11 copied to clipboard
CKR_GENERAL_ERROR:5 at C_GetAttributeValue
Hi Everyone,
I hope you are well. Recently came across an error while retrieving a key from softHSM. Its actually a CKR_GENERAL_ERROR:5 for the function C_GetAttributeValue. I have searched for this error and didn't find any references for it. Please let me know the cause if you have any idea regarding this or how can I avoid it.
The logs can be found on the below link. I'm running it in a docker container on ubuntu:16.04
https://pasteboard.co/IA6gNx8.png
Thank you
On further investigation I found out that it corrupts the SLOT. When I initialised a new slot and changed the slot number in the code it started working fine. Now I'm trying to find out if I can move the keys in slot 0 to slot 1 or not.
You can extract a key from one slot and copy it to another (key must be extractable)
do we have to set a property for that while generating the key? And is this a bug that is currently being worked on or any reference on why it occurs?
You can set extractable on the key generation and key importing
I did a softhsm2-util --help and I see an import option but don't see any commands for exporting or extracting the keys. Any reference on that?
I'm talking about WebCrypto API generateKey and importKey functions. They allow to make keys extractable.
What I understand is this.
So while generating keys using the
key = await crypto.subtle.generateKey(
{
name: 'ECDSA',
namedCurve: 'P-256',
extractable: 'true',
},
false,
['sign', 'verify']
);
we set the extractable property to true.
Then if (like in my instance) a slot gets corrupted use the importKey function to import the keys back into a new slot. BUT before I can do this I must have the keys(in some SPKI or PEM format) that needs to be imported into the new slot.
My Question is how can I extract those keys that were already in that corrupted slot into a format(SPKI/PEM) so that they can be imported into a new slot?
OR is there any way where we can point the library to extract keys from 1 slot and then import to another?
I hope you understand the question now.
is there any way where we can point the library to extract keys from 1 slot and then import to another
You are using PKCS#11 library. PKCS#11 interface doesn't allow to copy objects from one slot to another. You can do it by getting attributes from the target object and creating a new object on another slot.
how can I extract those keys
node-webcrypto-p11 implements WebCrypto API. An you can use exportKey function for getting different formats of keys (I'm suggesting to use JWK format). It also supports extended mechanisms for tokens using. See CryptoStorage and KeyStorage.
Steps to copy keys from one slot to another
-
Initialize Crypto for the slot 1
-
Get keys from slot1 using KeyStorage API (
cryptoSlot1.keyStorage.getItem) -
Export each key to JWK using WebCrypto API (
cryptoSlot1.subtle.exportKey) -
Initialize Crypto for slot 2
-
Import key using WebCrypto API (
cryptoSlot2.subtle.importKey) -
Add keys to token using LeyStorage API (
cryptoSlot2.keyStorage.setItem)
Thank you for the explanation.
The problem is that the error mentioned in the issue occurs on the 2nd step that you have mentioned above, when a slot gets corrupted I'm unable to access any of the keys from softHSM, therefore the cryptoSlot1.keyStorage.getItem method doesn't work and throws up the above error. If I'm able to access these keys from the slot then for me there is no need to export and import keys into a new slot. The sole purpose of a new slot is that I can't access keys in the old corrupted slot and to get my application up and running I need to create a new slot.
I am looking for a solution where I can extract keys form a slot that is not allowing me to access keys in it cause its corrupted.
or the cause which corrupts the slot in the first place so that it can be avoided with best practices.
I'm using SoftHSM for developing and testing my Crypto projects. I've never seen corrupted slot in it. Do you know steps to do it?
We saw this issue in dev environment and we used to restart our containers and it would go away. But in production we can't do that cause on container restart all our old keys would be gone. I'm not sure on how to reproduce this issue. We have multiple containers running in production and we got this problem in only one of the container.
Have you tried to enable SoftHSM logging to understand the real reson of CKR_GENERAL_ERROR exception?
No, I haven't.
SoftHSM really isn't a production solution it sounds like your issue lies there.