PKCS11 - Generate key for SHA256_HMAC

Question

I use Botan2 library to access SoftHSM2. I managed to generatesome AES/DES keys, yet I would like to generate a secret for SHA256 HMAC.

My code (after creating session, logging in and detecting my token):

namespace p11 = Botan::PKCS11;
p11::SecretKeyProperties propsOtpGen(p11::KeyType::Sha256Hmac);
propsOtpGen.set_label("OTPGEN");
propsOtpGen.set_modifiable(false);
propsOtpGen.set_private(true);
propsOtpGen.set_token(true);
propsOtpGen.set_sensitive(true);
propsOtpGen.set_sign(true);
propsOtpGen.set_verify(true);
propsOtpGen.add_numeric(p11::AttributeType::ValueLen, 16UL);

p11::Mechanism m {static_cast<CK_MECHANISM_TYPE >::MechanismType::GenericSecretKeyGen), NULL_PTR, 0};
11::ObjectHandle keyHandle;
const std::vector<p11::Attribute> vec = propsOtpGen.attributes();

module->C_GenerateKey(session.handle(), &m, const_cast<CK_ATTRIBUTE*>(&vec[0]), vec.size(), &keyHandle);

throws 0xd1 CKR_TEMPLATE_INCONSISTENT .

I checked SofthHSM2 logs, yet there is no further information.

EDIT

I had some other sample implementation that used nCipher, and similar attitude worked with vendor mechanism CKM_NC_SHA256_HMAC_KEY_GEN . This one, however, is not in the pkcs11 standard, thus I cannot use it.

Answer 1

After trying all calls imaginable, i still haven't made it work with SHA256HMAC key type. Seems like there is no generator for it.

The onlu workaround I found is using the GenericSecret key type.

namespace p11 = Botan::PKCS11;
p11::SecretKeyProperties propsOtpGen(p11::KeyType::GenericSecret);
//...

This generates the key, later the object handle can be passed to sign/verify with proper mechanism

CK_MECHANISM mechanism{CKM_SHA256_HMAC, NULL_PTR, 0};
module->C_SignInit(session.handle(), &mechanism, keyHandle);
module->C_Sign(session.handle(), data, signature);

However, the abovementioned operation will still fail under SoftHSM2 that I am using, since it doesn't support the supplied key size (this can be read from slot's get_mechanism_info ) - supported range is <32,512>. Final touch therefore will be patching

propsOtpGen.add_numeric(p11::AttributeType::ValueLen, 32UL);

I have tried to apply the different key size back to Sha256Hmac key type, yet it doesn't seem to solve the problem. (I assumed that the template inconsistence may be caused by this attribute).