Craton HSM

Glossary

This page defines the acronyms and terms used across the Craton HSM documentation. Definitions are scoped to how the term is used in this project; standards and RFCs are linked by name in the surrounding prose rather than inline here.

PKCS#11 and cryptographic module terms

PKCS#11. The Public-Key Cryptography Standard #11, also known as Cryptoki. Defines a vendor-neutral C API for cryptographic tokens. Craton HSM implements OASIS PKCS#11 v3.0.

Slot. An abstraction representing a physical or logical slot in which a token may be present. Craton HSM exposes up to 256 slots, configurable via slot_count in the [token] section of craton_hsm.toml.

Token. The cryptographic device bound to a slot. In Craton HSM a token corresponds to an encrypted on-disk store. Tokens carry PINs, an object store, and persistent state.

Session. A connection between an application and a token. Sessions have state (public or private, read-only or read/write) and carry the results of in-flight operations (sign, verify, encrypt, decrypt, digest).

SO (Security Officer). The administrative role on a PKCS#11 token. The SO initializes the token, sets and resets the user PIN, and may back up or restore token data. The SO PIN is separate from the user PIN.

User. The non-administrative PKCS#11 role that performs cryptographic operations on private objects.

Mechanism. A cryptographic algorithm identifier in PKCS#11 (e.g. CKM_RSA_PKCS_PSS, CKM_AES_GCM, CKM_ECDSA). Mechanism validity is filtered through the FIPS policy when FIPS approved mode is enabled.

Object. An addressable item in the token — a key, a certificate, or a data object. Objects carry attributes (CKA_CLASS, CKA_KEY_TYPE, CKA_LABEL, etc.) that drive template-based search via C_FindObjects.

CKR_*. The return-code namespace of PKCS#11. Every C_* function returns a CK_RV; successful calls return CKR_OK, failures map to specific error codes such as CKR_SESSION_HANDLE_INVALID, CKR_MECHANISM_INVALID, or CKR_PIN_LOCKED.

CK_OBJECT_HANDLE. A 32-bit integer handle to an object within a session. Handles are not portable across processes.

FIPS and NIST terms

FIPS 140-3. The current U.S. federal standard for cryptographic modules, published by NIST and maintained by CMVP. Supersedes FIPS 140-2 and is based on ISO/IEC 19790:2012.

CMVP (Cryptographic Module Validation Program). The joint NIST / CSE program that accredits laboratories, reviews validation reports, and issues certificates for FIPS 140-3 modules. A module is only "FIPS validated" once it appears on the CMVP public register with a certificate number.

POST (Power-On Self-Test). The suite of known-answer tests and integrity checks run at module start-up. Craton HSM runs 17 self-tests covering all approved algorithms plus a module integrity check; failure places the module in a POST-failed state that rejects all cryptographic calls until re-initialization.

KAT (Known-Answer Test). A test that feeds a fixed input into an algorithm and checks the output against a known expected value. KATs are preferred over round-trip tests for self-tests because they catch symmetric bugs that a pure encrypt/decrypt round-trip would not.

DRBG (Deterministic Random Bit Generator). The approved random-number generator class defined in SP 800-90A. Craton HSM uses HMAC-SHA256 DRBG with prediction resistance and an SP 800-90B continuous health test.

CSP (Critical Security Parameter). Key material or other security-relevant data whose disclosure would compromise the module. CSPs must be zeroized on drop and are tracked in the FIPS Security Policy.

Glossary

Glossary

PKCS#11 and cryptographic module terms

FIPS and NIST terms

Protocols and encodings

System and memory primitives

Licensing