CKR_DATA_INVALID
Where the length check stops, this one starts. The library or token read the input and found it malformed for the mechanism, which in the base specification means things like a point that is not on the curve or a signature block that does not parse. Smart card libraries widen it into a translation of the card's data-error status words, and on Luna hardware more native conditions collapse into this code than into any other.
What the token is reporting
The input to a cryptographic operation is not valid for the mechanism. The content was examined, unlike the length code, and the operation did not run.Likely causes
Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.
A DigestInfo or hash the raw mechanism could not parse
CKM_RSA_PKCS signing expects a DER DigestInfo on tokens that check the structure, and a bare hash fails there. The reverse mistake, wrapping a digest in DigestInfo for a mechanism that wanted the raw digest, fails the same way on tokens that check.Check it: Hex-dump the first few bytes of the input. A DigestInfo begins with a DER sequence, a raw digest does not.
Fix: Use the hash-combined mechanism and pass the document, so the token builds the structure itself.
An EC point or key in the wrong encoding
CKA_EC_POINT is a DER octet string wrapping the point, and strict tokens reject a bare point. Peer public data for ECDH derivation is the opposite on most libraries, bare rather than wrapped, and code that copies one convention to the other place gets this code.Check it: Compare your bytes with what the same library returns for a key it generated itself.
A card returned a data or parameter status word
Smart card libraries translate the card’s invalid-data and incorrect- parameters errors into this code, so it can stand for anything the card disliked about a command’s data field. The APDU trace is the only place the real reason survives.Check it: Enable the library’s debug log and find the status word returned by the card just before the failure.
One of a long list of native conditions on a network HSM
Vendor libraries map many internal conditions onto this code, from a padding type the firmware does not know to serial number and firmware version checks that have nothing to do with your input. The native code is in the client log and is the thing to search for.Check it: Read the vendor’s native return code from the client log rather than the PKCS#11 code.
Which calls return it
C_Sign, C_Verify, C_Encrypt, C_DeriveKey, C_CreateObject
What it is not
It is not the length, and it is not a failed decryption or a failed verification. Those have their own codes and mean the operation ran.Often confused with
CKR_DATA_LEN_RANGE: The check before this one. Wrong count versus wrong content.CKR_ENCRYPTED_DATA_INVALID: The decrypt-side counterpart, and the one a padding failure actually returns.CKR_ARGUMENTS_BAD: A malformed call rather than malformed data. Null pointers and bad counts go there.
By library
OpenSC
The card layer’s invalid-data and incorrect-parameters errors both become this code (misc.c), so on a card it is a translation, not a judgement the library made itself.SoftHSMv2
Never returned. There is no site in the library that produces it, and a malformed input falls through to the general or function-failed codes instead. If you see it, it did not come from SoftHSM.IBM opencryptoki
Rare. It appears only in the RSA and the s390 hardware paths and in the EP11 login sequence, so it is not the catch-all it is on vendor libraries.YubiHSM 2
Comes from the reader for the library’s own metadata objects and fromC_CreateObject, not from any cryptographic path ([util_pkcs11.c](http s://github.com/Yubico/yubihsm-shell/blob/b3ba0e80d61c507eb59bd734220af1 39d90650a6/pkcs11/util_pkcs11.c)). On a YubiHSM it points at a stored object’s metadata rather than at your input.Thales Luna
Thirty-two native return codes map here, more than to any other value in the vendor’s table. Among them are padding type, private key type, RNG seed, session and access handle conditions, and several firmware update checks. The PKCS#11 code alone is nearly useless on a Luna, the native code is not.Sources
- PKCS #11 Specification Version 3.2, OASIS. Read 2026-09-10. Used for constant name and numeric value.
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.