808bits

CKR_FUNCTION_FAILED

PKCS#11 return value · 0x00000006 · decimal 6
hex 0x00000006 decimal 6 name CKR_FUNCTION_FAILED

Two codes in this specification mean roughly "something went wrong" and the difference between them matters more than either one on its own. This is the recoverable half: the call did not do what you asked, the token is where it was, and the next call can be expected to work. Which means whatever caused it is still there, waiting, and is worth finding.

What the token is reporting

The requested operation could not be completed. The library remains usable and the token’s state is unchanged, which is what separates this from the general error and makes it the more common of the two by a wide margin.

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 mechanism cannot do what you asked of it

A mechanism appearing in the mechanism list does not mean it supports every operation. Each one carries flags saying which operations it is good for, and asking a sign-only mechanism to wrap a key is a perfectly well-formed call that simply cannot work.

Check it: Read the mechanism’s flags for the slot you are on and check them against the operation you attempted. On a ProtectServer token those flags are on the library page here, and the same call works against any library.

The key is not allowed to perform the operation

Key attributes are checked at use time, not at creation time, so a key created without the sign attribute will generate happily and then refuse to sign. Some libraries report that refusal precisely and some report it here.

Check it: Read back the attributes of the key you are using rather than the template you think you created it with. The two differ more often than people expect, because a token is allowed to refuse an attribute quietly.

The input does not suit the mechanism

A block cipher given input that is not a multiple of the block size, a raw signature mechanism given the wrong digest length, or data larger than the token will process in one piece all land here on some libraries.

Check it: Try the same operation with a textbook-sized input. If a small, well-aligned input succeeds, the problem is the data rather than the key or the mechanism.

A policy on the token forbids it

Appliances can be configured to refuse operations that the library and the key both permit, and a token in a restricted mode will decline algorithms it otherwise lists. The mechanism is present, the key is fine, and it still will not run.

Check it: Check the token’s policy or security configuration for the algorithm in question, and check whether the token is in a restricted or approved mode.

Which calls return it

C_Sign, C_Encrypt, C_WrapKey, C_DeriveKey, C_GenerateKeyPair

What it is not

It is not a reason to reinitialize the library. The library is fine. If restarting the process makes the problem go away, something else was wrong and this code was not it.

Often confused with

  • CKR_GENERAL_ERROR: The severe half of the pair. That one means the library has given up, this one means only the call did.
  • CKR_MECHANISM_INVALID: Returned when the library does not know the mechanism at all, rather than knowing it and being unable to apply it here.

See also

By library

SoftHSMv2

SoftHSMv2 returns this almost only from the object store. Ninety-eight of its hundred uses are rv = CKR_FUNCTION_FAILED after an attribute could not be written to the token’s files on disk, and the other two follow a failed [destroyObject](https://github.com/softhsm/SoftHSMv2 /blob/884cb38f3d2012a0447bd5f50dbd29c429987c41/src/lib/SoftHSM.cpp#L20 25). A crypto failure comes back as the general error instead. So on this library the code points at the token directory, its permissions and its free space, rather than at the mechanism or the key.

OpenSC

Only five places in the OpenSC module return this, and the one that matters is a context override in [misc.c](https://github.com/OpenSC/Op enSC/blob/4fab8b57301f035432191d582922d95d7d426802/src/pkcs11/misc.c#L 37-L42): a card answering C_Sign or C_Decrypt with “not allowed” is reported here rather than as a key permission error. The card’s usage rules for that key are the first thing to check.

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.