<\/p>\n
CRYPTOGRAPHIC TOKENS<\/p>\n
An application asks a PKCS #11 module to sign with a key handle. The call succeeds. No private value crosses the interface.<\/p>\n
That compact description is one of the standard’s strengths. It is also where many incorrect assumptions begin.<\/p>\n
The handle is not the key. It is a temporary reference into a logical object model exposed by a particular Cryptoki library. Behind it may be an HSM cluster, a smart card, a USB token, a remote service or a software implementation. The same function call can reach all of them, but it does not make their policies, failure modes or operational behaviour identical.<\/p>\n
PKCS #11 standardises a cryptographic interface. Using it well requires understanding where that abstraction ends.<\/p>\n
Cryptoki presents applications with slots, tokens, sessions and objects. A slot provides access to a token. A session creates a logical connection to it. Objects represent data, certificates and keys. Mechanisms identify cryptographic operations and their parameters.<\/p>\n
This vocabulary lets an application discover capabilities and request operations without speaking a device-specific command protocol. It deliberately hides whether a token has object storage, fixed key positions, several internal partitions or no physical hardware at all.<\/p>\n
The mapping is therefore constructive, not merely descriptive. A device with fixed key locations may be presented as a collection of key objects. An HSM cluster may look like one token. A smart card with strict command sequencing may be adapted to a session-oriented API.<\/p>\n
Portability exists at the logical boundary. Everything that affects the mapping can still vary:<\/p>\n
A portable application cannot assume the intersection of those behaviours is larger than it has tested.<\/p>\n
An object handle is meaningful only within the context in which the module returned it. It should not be stored as the durable identity of a key, passed between unrelated processes or expected to remain stable after the module is reinitialised.<\/p>\n
This matters because applications often need two distinct concepts:<\/p>\n
PKCS #11 attributes such as Search therefore needs an explicit naming model. The application should define which attributes establish identity, what uniqueness is expected within a token and what happens when zero or several objects match.<\/p>\n The PKCS #11 URI scheme adds a standard way to describe token and object selection, but it does not eliminate ambiguity in the underlying inventory. A precise URI cannot repair an imprecise provisioning policy.<\/p>\n A key object is more than key material. Its attributes constrain what the token permits an application to do with it.<\/p>\n For a secret or private key, relevant questions include:<\/p>\n These are not annotations added after key creation. They form part of the key’s effective policy.<\/p>\n Some attributes become read-only once an object exists. Some values are imposed by the token. Some combinations are rejected. Others are silently normalised according to device policy. A template that works on a software token may fail on a certified HSM because the hardware refuses a weaker lifecycle.<\/p>\n An application should treat object creation as policy negotiation with a strict postcondition: after creation, read back every attribute that is observable and verify that the resulting object has the intended capabilities. A successful handle is not sufficient evidence.<\/p>\n Sensitivity controls whether secret key material may be revealed through attribute access. Extractability controls whether the key may be exported through a wrapping operation. A non-extractable key should not become extractable later. Historical attributes such as Even then, the statement is bounded by the token implementation and its authorised operations. A key that cannot be exported may still be used to decrypt attacker-selected ciphertexts, derive other keys or wrap objects under an inappropriate mechanism. Preventing raw extraction does not make every permitted use safe.<\/p>\n The security boundary is the combination of key attributes, mechanisms, authentication state, application authorisation and token policy.<\/p>\n Two objects may expose the same attributes today while having different provenance.<\/p>\n A key generated inside the token may never have existed outside its boundary. An imported key necessarily existed elsewhere, at least during provisioning. A key unwrapped inside the token arrived as a protected blob, but its earlier custody depends on the wrapping system and the controls under which the blob was created.<\/p>\n PKCS #11 can express parts of this history through attributes such as whether a key was locally generated. It cannot attest to an entire ceremony by itself.<\/p>\n For meaningful assurance, the application needs an external record of:<\/p>\n The object handle points to current capability. It does not narrate provenance.<\/p>\n Key wrapping is sometimes treated as generic encrypted export. In practice it is a protocol between a source token, a destination token and the systems that assign policy on both sides.<\/p>\n The parties must agree on the wrapping mechanism, parameters, key type, transported attributes and destination template. They also need a way to bind the wrapped value to the intended environment and reject substitution or rollback.<\/p>\n Several questions follow:<\/p>\n A mechanism that can wrap a key is not automatically a migration design. As with algorithm agility<\/a>, the difficult part is completing the transition while preserving policy and recoverability.<\/p>\n A mechanism identifies an operation, but the surrounding contract may include parameters, input formatting and multi-part behaviour.<\/p>\n With RSA, an application may choose a mechanism that performs raw modular exponentiation, one that applies a signature encoding, or one that performs hashing and encoding inside the token. Those choices determine which bytes cross the interface and which component is responsible for constructing the signed statement.<\/p>\n With ECDSA, implementations may differ in supported curves, signature encoding at the API boundary and treatment of pre-hashed input. With authenticated encryption, parameter structures carry nonces, associated data and tag lengths whose validation can vary between versions and vendors.<\/p>\n Mechanism discovery through The relevant capability is not “supports ECDSA” or “supports AES-GCM.” It is a tested tuple of mechanism, parameters, key attributes, message size, session state and expected output encoding.<\/p>\n Cryptographic operations occur through sessions. A session may be read-only or read\/write, public or authenticated, and capable of holding temporary objects and active operation state.<\/p>\n This creates behaviour that is easy to miss behind higher-level language bindings:<\/p>\n A connection pool for a database and a session pool for an HSM do not have equivalent semantics. The latter carries cryptographic state, authentication state and object visibility rules.<\/p>\n Concurrency should therefore be designed at the PKCS #11 layer rather than left to an incidental wrapper. Each operation needs clear ownership of its session. Recovery needs to distinguish a retryable transport failure from an operation whose completion is unknown.<\/p>\n Cryptographic APIs are often evaluated by successful test vectors. Operational reliability depends equally on their failures.<\/p>\n A robust integration should exercise:<\/p>\n Retrying every failure is unsafe. A signature request may have completed even if the response was lost. Repeating a key-generation or unwrap operation can create duplicate objects. Reopening a session does not restore the state of an interrupted multi-part operation.<\/p>\n The application needs an error model tied to the semantics of each operation.<\/p>\n The complete PKCS #11 specification contains more behaviour than most applications or tokens implement. Portability becomes tractable when a deployment defines a narrower profile.<\/p>\n A useful application profile states:<\/p>\n This profile can be executed against a software token during development and against each target device before deployment. Differences then become explicit compatibility results rather than production surprises.<\/p>\n Software emulation remains useful, but it cannot prove hardware properties. It validates application behaviour at the interface. Claims about tamper resistance, non-exportability and key generation inside a certified boundary require evidence from the actual module and its configuration.<\/p>\n PKCS #11 succeeds because it gives very different cryptographic devices a common shape. Applications can locate objects, request operations and keep private material behind a defined interface.<\/p>\n The common shape should not be mistaken for identical semantics.<\/p>\n A handle is a reference. An attribute template is a policy request. A mechanism is an operation contract. A session is state. A token is an implementation of a logical boundary whose guarantees still need to be discovered, tested and operated.<\/p>\n The key may remain inside the device. The meaning of using it remains the responsibility of the system outside.<\/p>\n PKCS #11 gives applications a common view of cryptographic devices. The key’s policy, lifecycle and operational meaning still depend on what lies behind the handle.<\/p>\n","protected":false},"author":2,"featured_media":328,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","nlabs_series_part":1},"categories":[10],"tags":[68,69,72],"nlabs_series":[64],"nlabs_article_type":[36],"class_list":["post-329","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-research","tag-algorithms-primitives","tag-applied-cryptography","tag-key-management","nlabs_series-pkcs-11-key-policy","nlabs_article_type-primer"],"_links":{"self":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/329","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/comments?post=329"}],"version-history":[{"count":1,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/329\/revisions"}],"predecessor-version":[{"id":224740,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/329\/revisions\/224740"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media\/328"}],"wp:attachment":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media?parent=329"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/categories?post=329"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/tags?post=329"},{"taxonomy":"nlabs_series","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/nlabs_series?post=329"},{"taxonomy":"nlabs_article_type","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/nlabs_article_type?post=329"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}CKA_ID<\/code>, CKA_LABEL<\/code>, key type and object class can participate in a search template. None is automatically a globally unique identity. Labels may be duplicated. IDs may be assigned according to a local convention. A certificate, public key and private key may intentionally share an ID so that an application can associate them.<\/p>\nAttributes are policy, not decoration<\/h2>\n
\n
Sensitive and non-extractable are different claims<\/h2>\n
CKA_SENSITIVE<\/code> and CKA_EXTRACTABLE<\/code> are frequently compressed into the phrase “the key cannot leave the HSM.” The actual model is more precise.<\/p>\nCKA_ALWAYS_SENSITIVE<\/code> and CKA_NEVER_EXTRACTABLE<\/code> help describe whether those protections have held throughout the object’s lifetime.<\/p>\nGeneration and import create different histories<\/h2>\n
\n
Wrapping is a protocol<\/h2>\n
\n
A mechanism name is not a complete contract<\/h2>\n
C_GetMechanismList<\/code> and C_GetMechanismInfo<\/code> is necessary, but it is not a substitute for operation-level tests. A token can advertise a mechanism while rejecting the particular parameter set, key size or object policy the application needs.<\/p>\nSessions make the interface stateful<\/h2>\n
\n
Errors are part of the boundary<\/h2>\n
\n
Profiles make portability testable<\/h2>\n
\n
The boundary behind the handle<\/h2>\n
\nReferences<\/h2>\n
\n