808bits

CKR_FUNCTION_NOT_SUPPORTED

PKCS#11 return value · 0x00000054 · decimal 84
hex 0x00000054 decimal 84 name CKR_FUNCTION_NOT_SUPPORTED

A library has to export every function in the table whether or not the token behind it can do the work, and the stub that returns this code is how it says no. Which functions are stubs varies more from one library to the next than any other part of the interface, and nothing in the function list tells you in advance. The same library can also answer differently per slot.

What the token is reporting

The library implements this call as a refusal. Your arguments were not examined, so there is nothing to fix in the call itself. Either use a different function or a different library.

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 3.0 message-based or dual-purpose function on a 2.x-shaped library

C_MessageEncryptInit and its relatives, the four dual-function updates such as C_DigestEncryptUpdate, C_SetOperationState, and the recover variants of sign and verify are stubs in most open source libraries and in many vendor ones. Bindings that expose the whole 3.0 surface let you call them, and the library declines.

Check it: Read the version from C_GetInfo, then check the library’s own documentation for the function. If the failure does not depend on the key or the mechanism, it is a stub.

Fix: Use the single-part 2.x equivalent. For dual-function calls, run the two operations in sequence yourself.

The token cannot do that class of operation at all

A smart card with no wrap command, a network HSM with wrapping disabled by policy, a token with no seedable random source. The library knows before contacting the device and refuses at the entry point.

Check it: Try the same function with another key and another mechanism. If it fails identically, the function is unsupported. If the failure moves, you are looking at a mechanism or key problem instead.

A multi-backend library where this slot's backend lacks the function

Libraries that front several token types fill a function table per backend, and a missing entry is answered with this code. The same call works on the software slot and fails on the hardware one, which reads as a bug until you look at which slot the session belongs to.

Check it: Repeat the call on a session in a different slot of the same library.

The function works, but not for this kind of object

Some libraries refuse a function for a subset of objects rather than returning an attribute or key code. Session-derived keys and objects the library synthesizes rather than stores are the usual cases.

Check it: Retry against a token object of the same class. If that works, the refusal was about the object, not the function.

Which calls return it

C_SetOperationState, C_SeedRandom, C_VerifyRecover, C_DigestEncryptUpdate, C_MessageEncryptInit, C_WrapKey

What it is not

It is not the mechanism being missing. A mechanism the library lacks is CKR_MECHANISM_INVALID, and that means the function itself is fine. It is also not a permissions or licensing signal, which arrives as function rejected or key function not permitted.

Often confused with

  • CKR_MECHANISM_INVALID: The distinction people get backwards. Function not supported means the call is a stub, mechanism invalid means the call works and the algorithm is unavailable.
  • CKR_KEY_FUNCTION_NOT_PERMITTED: The key's own attributes forbid this use. The function and the mechanism are both fine.
  • CKR_FUNCTION_FAILED: The function ran and something went wrong. Not the same as a refusal at the door.

By library

SoftHSMv2

The stubs are C_VerifyRecover, the four dual-function updates and C_WaitForSlotEvent (SoftHSM.cpp), plus the 3.2 encapsulation calls when the build lacks the algorithm. Everything else is implemented.

OpenSC

C_SetOperationState, C_SeedRandom, the recover variants, C_LoginUser and every message-based 3.0 function are stubs. Separately, anything the card driver reports as not supported becomes this code through the error translation (misc.c), so on a card it can also mean the card declined a command the library itself understands.

IBM opencryptoki

The API layer returns it whenever the token’s function table lacks the entry (api_interface.c), and each token type fills that table differently. The answer depends on the slot, not on the library.

YubiHSM 2

C_SetAttributeValue on an ECDH session key returns this rather than an attribute code (yubihsm_pkcs11.c). An example of a refusal that is about the object.

Thales Luna

Twelve native codes map to it, and they include high availability not supported, ECC not supported, masking not supported and no offboard storage. On a Luna this code is as likely to be a capability or licence limit as a missing entry point, and the native code in the client log is what says which.

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.