808bits

CKR_KEY_FUNCTION_NOT_PERMITTED

PKCS#11 return value · 0x00000068 · decimal 104
hex 0x00000068 decimal 104 name CKR_KEY_FUNCTION_NOT_PERMITTED

Keys carry a set of permissions that say which operations they may be used for, and those are fixed at creation. This code is that check firing. It is one of the few errors in the specification that is purely a policy decision rather than a fault, which also means there is nothing to debug: either the key should have been created differently, or the call is asking for the wrong thing.

What the token is reporting

The key does not have the attribute corresponding to the operation you attempted. A key without the sign attribute will not sign, whatever else is true about it.

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 attribute was never set at creation

Templates that omit an attribute get the token’s default, and the defaults are conservative. A key generated for signing that was never explicitly marked for signing may well not be able to.

Check it: Read the key’s attributes back from the token rather than trusting the template you wrote. The token is allowed to have ignored parts of it.

The wrong half of a key pair

Public keys verify and private keys sign, and a lookup by label that matches both will hand back whichever comes first. The resulting call is well-formed and asks the wrong object to do the work.

Check it: Include the object class in the search rather than filtering afterwards. A search by label alone is ambiguous by construction.

A key derived or unwrapped with a narrower template than intended

Keys arriving through unwrapping or derivation take their attributes from the template supplied at that moment, not from the key they came from. A key that could sign on the token it was exported from may not be able to on the token it lands in.

Check it: Compare the attributes of the imported key against the original. The difference is in the template used at import.

Which calls return it

C_SignInit, C_EncryptInit, C_WrapKey, C_DeriveKey

What it is not

It is not about the session or the logged-in role. Being an administrator will not persuade a key to perform an operation it was not created for, and on most tokens the permission attributes cannot be changed after creation.

Often confused with

  • CKR_KEY_TYPE_INCONSISTENT: The key is the wrong type for the mechanism rather than the right type without permission. That points at the mechanism, not at the template.
  • CKR_FUNCTION_FAILED: What some libraries return for the same situation, which is why a generic failure on a key operation is worth checking the attributes for.

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.