808bits

CKR_MECHANISM_PARAM_INVALID

PKCS#11 return value · 0x00000071 · decimal 113
hex 0x00000071 decimal 113 name CKR_MECHANISM_PARAM_INVALID

Mechanisms that take a parameter check it before the operation starts, and this is the code for one the library or token will not accept. The three usual culprits are a pointer and length pair that does not match the structure the mechanism wants, an IV or tag length outside the token's range, and an OAEP or PSS structure whose hash and mask generation function disagree with each other or with what the hardware can do.

What the token is reporting

The pParameter and ulParameterLen fields of the mechanism structure are not what this mechanism expects. Either the length is not the size of the right structure, or a field inside it is out of range for this token.

Likely causes

Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.

The parameter length does not match the structure

CBC wants a bare IV of one block, not a structure. GCM wants a CK_GCM_PARAMS, and that structure gained a field between specification versions, so a binary built against one header passes a length the library built against the other refuses. Bindings that box the parameter in a generic buffer get this wrong silently.

Check it: Compare ulParameterLen with the size of the structure in the header the library was compiled against, not the header you compiled against.

Fix: Use the parameter structure from the same specification version as the library, and for GCM check which layout the library documents.

No parameter where the mechanism requires one

A null parameter on a CBC mechanism, on OAEP, or on an ECDH derive is refused before anything else. The specification’s mechanism table says which mechanisms take a parameter, and wrappers that default the field to null hide the omission.

Check it: Look the mechanism up in the mechanism table. If it lists a parameter type, one is required.

OAEP or PSS fields the token will not combine

The hash and the mask generation function are expected to pair, and a salt length beyond what the modulus allows is refused. Hardware often supports a narrower set of combinations than the specification permits, so a structure that works on a software token fails on the HSM.

Check it: Try the SHA-1 hash with the SHA-1 mask function, which every token accepts, to confirm the structure itself is fine, then step up.

A GCM or CCM tag or IV length outside the token's range

Tag lengths below 96 bits and IVs of any length but twelve bytes are refused on many HSMs, and some validated tokens will not accept an externally supplied IV for encryption at all.

Check it: Retry with a twelve-byte IV and a 128-bit tag. If that passes, the original values were outside the token’s range.

Which calls return it

C_EncryptInit, C_DecryptInit, C_SignInit, C_VerifyInit, C_DeriveKey, C_WrapKey

What it is not

It is not the mechanism being unknown, which is CKR_MECHANISM_INVALID and means the library never looked at the parameter. It is not the key either. A key that does not suit the mechanism is reported as a type inconsistency.

Often confused with

  • CKR_MECHANISM_INVALID: Unknown mechanism versus known mechanism with a bad parameter. The second one means the library got further.
  • CKR_ARGUMENTS_BAD: Some libraries report a parameter that had to be null under arguments bad rather than here, and the choice varies by mechanism.
  • CKR_DATA_LEN_RANGE: When a length rule depends on the parameter, the IV or the tag, the library may blame the data instead.

By library

SoftHSMv2

Symmetric initialisation checks the IV against the cipher (SoftHSM.cpp ), and the symmetric derive path checks each derive parameter structure field by field ([SoftHSM.cpp](ht tps://github.com/softhsm/SoftHSMv2/blob/884cb38f3d2012a0447bd5f50dbd29c 429987c41/src/lib/SoftHSM.cpp#L13848-L13905)).

IBM opencryptoki

Close to four hundred sites, and the CCA back end alone has more than eighty, because the hardware accepts a narrower set of combinations than the specification. The same OAEP or PSS structure can pass on the software token and fail on the CCA one, from a single library.

YubiHSM 2

The OAEP parameter parser and the ECDH-with-KDF path are the main sources, followed by the encrypt initialisation ([util_pkcs11.c](https: //github.com/Yubico/yubihsm-shell/blob/b3ba0e80d61c507eb59bd734220af139 d90650a6/pkcs11/util_pkcs11.c)).

Sources

Every description, cause and check on this page is written from scratch. The specification is cited for the constant's name and its number, which are facts, and for nothing else.