808bits

CKR_ATTRIBUTE_SENSITIVE

PKCS#11 return value · 0x00000011 · decimal 17
hex 0x00000011 decimal 17 name CKR_ATTRIBUTE_SENSITIVE

Of every code in the specification this is the one that means the token is working as designed, since a key whose private value cannot be read is the reason for putting it in a token at all. The reports worth investigating are the ones where the caller did not think it was reading key material, and a handful of library habits explain most of those.

What the token is reporting

You asked for an attribute the object holds and marks as sensitive, or the object is not extractable and the attribute is part of its private material. The length field for that entry is set to CK_UNAVAILABLE_INFORMATION. The rest of the template may have been filled.

Likely causes

Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.

Reading CKA_VALUE or the RSA private components on a private or secret key

Export and backup code, key-to-PEM converters and “dump the object” helpers all do this. On most hardware the private value is sensitive from the moment the key is generated, whatever the template said, and cannot be made otherwise afterwards.

Check it: Read CKA_SENSITIVE and CKA_EXTRACTABLE. Sensitive true or extractable false is the answer.

Fix: If the bytes have to leave the token, wrap the key with C_WrapKey under a wrapping key, which is what extractable is for. If the key was meant to be readable in the clear it must be created with sensitive false and extractable true, and many tokens will still refuse.

A generic attribute dump walking every attribute

Inventory tools read a long template in one call. One sensitive entry fails the call, every other entry was actually filled, and a tool that checks only the return code reports the whole object as unreadable.

Check it: Inspect the per-entry lengths after the call. Only the sensitive entries carry the unavailable marker.

Fix: Skip the value attributes for private and secret key classes, or tolerate the unavailable marker per entry.

Token policy made it sensitive without you asking

A template with sensitive false can still yield a sensitive key, because a token may force the attribute on generation and the specification only lets it change from false to true, never back. Code that created the key expecting to read it later finds it locked.

Check it: Read CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE. If both are true the key has been locked since birth and no template would have changed that on this token.

Which calls return it

C_GetAttributeValue

What it is not

It is not a login or role problem. An authenticated session gets the same answer. It is also not a dead end for the key itself: wrapping still works if the key is extractable, and signing with it never needed the value.

Often confused with

  • CKR_ATTRIBUTE_TYPE_INVALID: The other reason a read comes back with an unavailable length. Type invalid means the attribute is not there, sensitive means it is there and withheld.
  • CKR_USER_NOT_LOGGED_IN: What you get for a private object with no session authentication. That one goes away after a login. This one does not.
  • CKR_KEY_UNEXTRACTABLE: The wrap-time counterpart. A key that refuses to be read also refuses to be wrapped when extractable is false, and that is the code for it.

By library

SoftHSMv2

A read that hits both a sensitive attribute and an unknown one reports sensitive, by an explicit priority in the attribute loop (P11Objects.cp p).

IBM opencryptoki

Whether an attribute is hidden is decided per key type, and only for private and secret key classes with sensitive true or extractable false. The failing entries get the unavailable marker and the loop continues (object.c), so the rest of the template is filled. An object whose sensitivity flags cannot be read is treated as fully hidden.

OpenSC

The RSA private components are refused with this code regardless of the card’s own flags (framework-pkcs15.c), which is honest, because no card the library supports would hand them out anyway.

YubiHSM 2

CKA_VALUE for EC keys and CKA_PRIVATE_EXPONENT for RSA keys are refused unconditionally (util_pkcs11.c). There is no such thing as a readable private key on a YubiHSM 2, whatever the template asked 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.