808bits

CKR_DEVICE_ERROR

PKCS#11 return value · 0x00000030 · decimal 48
hex 0x00000030 decimal 48 name CKR_DEVICE_ERROR

This is the code a library returns when the token itself has gone wrong and it has nothing more specific to say. That vagueness is the whole problem: it covers a card that was pulled, a network HSM whose client lost its connection, a module that failed a self test, and a firmware that quietly refuses an operation it advertised. The useful move is not to look it up but to work out which of those you are in, and a fresh process talking to the same slot usually settles it in one command.

What the token is reporting

The library is reporting a fault at the device end of the boundary rather than a fault in your call. It is the last resort in the specification’s error vocabulary, so a library reaches for it when the firmware returned something it cannot map, when the transport underneath the library broke, or when the token entered a state where it will no longer serve the session you hold.

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 token was reset or lost power while your session was open

Session and object handles are only meaningful to the token that issued them. A reset, a power cycle, a firmware restart or a removed card invalidates every one of them, and the next call on a stale handle comes back as a device fault rather than as an invalid handle.

Check it: Run a status tool in a fresh process against the same slot. If a new process can enumerate the slot and read the token normally, the device is fine and your handles are stale.

Fix: Finalize and re-initialize the library, open a new session, and re-find your objects by label or id. Handles must never be cached across a reconnect.

The client cannot reach the HSM any more

On a network attached HSM the library is a thin client. When the daemon dies, a certificate on the client link expires, or the network path drops, the failure surfaces at the first call that needs the device rather than at connect time.

Check it: Check the client daemon is running and read its log rather than your application’s. The client log names the transport failure. Your application only ever sees the mapped return value.

The module is in an error state after a failed self test

A module that fails a power-up or conditional self test is required to stop serving cryptographic operations. Some libraries surface that as a device fault on every subsequent call, which makes it look like a transient fault when it is a module that has deliberately shut itself down.

Check it: Read the HSM’s own event log rather than inferring from return values. A self test failure is recorded there with a reason. If the log is clean, rule this out and move on.

The firmware will not perform a mechanism the library advertised

A mechanism appearing in the mechanism list means the library knows the constant, not that the current firmware, key type and security policy will run it. Some libraries return a clean mechanism error for this and some return a device fault.

Check it: Enumerate the mechanism list for the slot and read the key size range and flags for the one you used, then check your key against them. On ProtectToolkit, ctstat -m -s0 prints every mechanism the token offers with its minimum and maximum key size, and a key outside that range is a different failure than a mechanism that is refused outright.

Which calls return it

C_Login, C_OpenSession, C_GetTokenInfo, C_Sign, C_Encrypt, C_GenerateKeyPair

What it is not

It is not a statement about your arguments. If the call was malformed you would have been told so more precisely, so resist the urge to start editing the template or the mechanism parameters. Work outward from the device first.

Often confused with

  • CKR_DEVICE_REMOVED: The specific version of the first cause above. A library that noticed the token leave will say so, and that is a more useful signal than the general fault.
  • CKR_DEVICE_MEMORY: The device is healthy but out of room. Worth checking before you go looking for a transport problem that is not there.

See also

By library

OpenSC

Three libopensc conditions land here through the translation switch ([ misc.c](https://github.com/OpenSC/OpenSC/blob/4fab8b57301f035432191d58 2922d95d7d426802/src/pkcs11/misc.c#L70-L123)): a card that stopped answering, a reader locked by another process, and a card reporting a memory failure, which on a smart card means its EEPROM. The first two clear with a reset or by finding the other process. The third does not clear.

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.