VALUE_LEN throws exception when creating ObjectClass.SECRET_KEY and KeyType.AES (softhsm2) about python-pkcs11 HOT 4 CLOSED

We would be reporting the error returned from SoftHSM2. You could test VALUE is correct by doing an encrypt operation both locally and in the HSM. Or set the key as extractable and then pull it back out.

However, be mindful of what you're using the HSM for. HSMs are rarely, if ever, encryption accelerators. Your computer is almost always faster than any (hard) HSM. HSMs are a secure domain in which to hold keys and do crypto with secrets that mustn't touch real hardware. Importing externally created secret/private keys into your HSM defeats this goal. Instead create keys in your HSM that you can never read.

from python-pkcs11.

My use case is that I only need to encrypt few MB of data. Speed is not my main concern. I import the key into HSM because decryption will happen somewhere else.

I understand keys should be generated in HSM for security. However, anyone with physical access to the computer the HSM is attached to can just request the key from HSM. In most cases for a dedicated attacker it is not that hard to find user pin in binaries, and etc.

In issue 48 you said

If you were looking to do symmetric crypto you could generate a symmetric session key using diffie-hellman against a private key on the device and then do the AES on the computer. There's an example of this in the tests.

but as I said the decryption will be made somewhere else. I might be missing something as I'm new to this field. If you have any suggestions I'm happy to listen.

from python-pkcs11.

I question then why you want to use a HSM at all for this setup. Why not just do the crypto on your much faster real CPU? Be aware that a number of HSMs won't even let you import key material.

I understand keys should be generated in HSM for security. However, anyone with physical access to the computer the HSM is attached to can just request the key from HSM. In most cases for a dedicated attacker it is not that hard to find user pin in binaries, and etc.

HSM setups are about limiting the damage. The key material can never be extracted. This means that while if someone acquires the pin, they can only carry out operations while they have the pin and the token. If the pin is changed or the token is removed from the HSM they can no longer use the key. In a compromise scenario this means you can limit the amount of damage caused by unauthorised access to the HSM.

Many commercial HSMs also have a number of features for protecting especially valuable keys, e.g. split tokens (2 or 3 tokens are required to access the key) or out-of-computer PIN interfaces.

In #48 I was suggesting using hybrid crypto to achieve symmetric crypto on devices that only support asymmetric crypto, while protecting the key material. TLS and PGP both have standardised protocols/formats and encapsulations for this. Avoid reinventing the cryptographic wheel where possible.

from python-pkcs11.

Closing due to lack of activity.

from python-pkcs11.