808bits

CKR_KEY_TYPE_INCONSISTENT

PKCS#11 return value · 0x00000063 · decimal 99
hex 0x00000063 decimal 99 name CKR_KEY_TYPE_INCONSISTENT

The mechanism you named and the key you handed it disagree about what kind of key it is, and the library noticed before touching the token. It is one of the more honest codes, with two habits that make it confusing: several libraries use it for wrapping-key mismatches too, and a search that returned the wrong object produces it with a handle that looks perfectly valid.

What the token is reporting

The object’s CKA_KEY_TYPE, or its class, is not one the mechanism accepts. The key exists and you have access to it. It is the pairing that is wrong.

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 find that returned a different object than you meant

A search by label or by CKA_ID with no class in the template matches the private key, the public key and the certificate that share the identifier, and C_FindObjects returns whichever the library lists first. The handle is real. C_SignInit with a certificate is rejected under this code on most libraries.

Check it: Read CKA_CLASS and CKA_KEY_TYPE from the handle that failed, rather than from the object you believe it is.

Fix: Put CKA_CLASS in every search template.

Mechanism family and key family do not match

CKM_RSA_PKCS with an EC key, CKM_ECDSA with an Ed25519 key, which needs CKM_EDDSA, an AES mechanism with a generic secret, a DES3 mechanism with a single DES key. Keys imported through other tooling often carry a type the importer chose rather than the one you expected.

Check it: Look the mechanism up in the specification’s mechanism table, which names the key types it takes, and compare with the key’s type.

Derivation base key of the wrong type

The data-encryption derive mechanisms want a base key of the matching cipher, the concatenation ones want a secret key, and the ECDH ones want an EC private key. A base key that works for encryption can still be the wrong type for the derive you chose.

Check it: Check the class and type of the base key against the derive mechanism, not against the key you are trying to produce.

A wrapping key mismatch reported under the plain code

The specification has separate wrapping and unwrapping variants of this code. Several libraries return the plain one from C_WrapKey and C_UnwrapKey when it is the wrapping key that is wrong, so the code alone does not say which of the two keys to look at.

Check it: If the failing call is a wrap or unwrap, check the wrapping key first.

Which calls return it

C_SignInit, C_VerifyInit, C_EncryptInit, C_DecryptInit, C_DeriveKey, C_WrapKey, C_UnwrapKey

What it is not

It is not a permission problem, which is key function not permitted, and not a size problem, which is key size range. The type is checked before either of those.

Often confused with

  • CKR_KEY_FUNCTION_NOT_PERMITTED: The key is the right type and its attributes forbid the use. Fix the attributes at creation, not the mechanism.
  • CKR_MECHANISM_INVALID: The library does not have the mechanism at all. This code means it does and the key does not suit it.
  • CKR_OBJECT_HANDLE_INVALID: What the same wrong-object mistake becomes when the find returned nothing and the code used a zero handle.

By library

SoftHSMv2

C_DeriveKey checks the base key’s class and type against each derive mechanism in turn (SoftHSM.cpp), which is where most of its uses of the code sit.

OpenSC

Used for object creation, wrap, unwrap, derive and decrypt initialisation (pkcs11-object.c). OpenSC reports a wrapping key of the wrong type with this code rather than the wrapping-specific ones.

IBM opencryptoki

Most sites are in the encryption and decryption managers, one per mechanism, plus the CCA and EP11 token back ends which check again against what the hardware will take.

Thales Luna

Three native codes map here, and one of them is the DES key parity check. A DES key with bad parity bits surfaces on a Luna as a type inconsistency rather than as a value error, which is not where anyone looks first.

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.