PKCS11 Key Protection And the Insider Threat

Outline The Insider Threat Existing Protection Mechanism Primary Key vs Secondary Key Primary Key Protection Secondary Key Protection Related Items

The Insider Threat General design goal – if desired, key material checks in but never checks out (PKCS11, the roach motel of key material) Insider threat is authorized, but illegitimate, user Stolen credentials (e.g. PIN) Hacked application using PKCS11 token for security Attacker is authorized token user, but token should prevent extraction attacks. PKCS11 has reasonable protection for primary keys, but little or no protection for secondary keys (see below)

Existing Protection Mechanisms (1) CKA_PRIVATE Limits key use to CKU_USER if true Needs work or replacement if we add user logins (or additional roles) CKA_SENSITIVE Generally prevents use of C_GetAttributeValue with “sensitive” attributes if true CKA_EXTRACTABLE Allows the use of C_WrapKey if true But see also CKA_WRAP_WITH_TRUSTED and CKA_TRUSTED CKA_DERIVE, CKA_SIGN, etc Allows use of C_DeriveKey, C_Sign etc if true

Existing Protection Mechanism (2) CKA_WRAP_WITH_TRUSTED If CKA_EXTRACTABLE is true, limits wrapping of *this* key to only by CKA_TRUSTED=true keys CKA_TRUSTED Can only be set to true by CKU_SO But CKU_SO can’t see CKA_PRIVATE keys to set them Limits usefulness of CKA_WRAP_WITH_TRUSTED to public keys. Or non-private symmetric keys CKA_ALLOWED_MECHANISMS Locks key to specific set of mechanisms Doesn’t appear to be a sticky attribute

Existing Protection Mechanisms (3) CKA_WRAP_TEMPLATE Limits use of *this* key to only wrap keys that match template Simple to bypass by creating a new wrapping key without this restriction CKA_UNWRAP_TEMPLATE Forces unwrapped key to have certain attributes Currently *not* a sticky attribute Easy to bypass by copying key and clearing the template CKA_COPYABLE, CKA_DESTROYABLE, CKA_MODIFIABLE If true, allows C_CopyObject, C_DestroyObject, C_SetAttributeValue respectively Some issues with policy language should be clarified.

Primary Key vs Secondary Key For the purposes of this presentation Primary Key Key created or loaded by legitimate user for which the source key material is not accessible to an attacker Generated on token, or securely loaded Sticky attributes set at creation Secondary key A key created through the use of C_DeriveKey from a Primary or Secondary Key Creation can be repeated at any time assuming public data and original key Or a key created through the use of C_UnwrapKey where the wrapped key material is accessible at some point to an attacker Unwrapping can be repeated at any time as long as unwrapping key is still on token

Primary Key Protection (1) Creator can prevent extraction CKA_EXTRACTABLE=false (sticky) Creator can prevent key data extraction CKA_SENSITIVE=true (sticky) Creator can limit key to specific use CKA_DERIVE, CKA_SIGN, etc But not sticky, so attacker can change Creator can limit key to specific mechanisms CKA_ALLOWED_MECHANISMS Other stickyness problems for other protection attributes

Primary Key Protection (2) Extractable Keys (CKA_EXTRACTABLE=true) Constrained by CKA_WRAP_WITH_TRUSTED and CKA_WRAP_TEMPLATE But attacker can add new key with less restrictive wrap template. Re-loaded wrapped keys Wrapped keys don’t contain original attributes Unwrapped keys can be set with any attributes But some protection through CKA_UNWRAP_TEMPLATE

Primary Key Protection (3) Fixes? Add stickyness language to all protection attributes Ensure attributes can become more restrictive, but not less Allow key to specify its wrap key at creation CKA_WRAP_WITH_UUID CKA_UUID (read only, internally generated) Doesn’t require SO intervention to specify a “trusted” key. Specify at least one wrapping mechanism that preserves/restores key attributes CKM_SEAL_KEY

Secondary Key Protection (1) General model of attack for C_Derive is that attacker Has use permission for primary key Has access to “public data” used for the derive operation E.g. other side public key, random data, label, etc Re-derives desired key But sets attributes of derived key so key data is extractable E.g. CKA_SENSITIVE=false or CKA_EXTRACTABLE=true Extracts key data and passes it on or uses it No mechanism to enforce setting of policy on derived secondary keys

Secondary Key Protection (2) Second method of attack for C_DeriveKey is that attacker Has use of CKK_GENERIC_SECRET primary key Has access to public data used by derive operation Has use of the underlying PRF CMAC or HMAC function used by the derive mechanism Knows the derive function Uses the CMAC or HMAC function with the primary key and public data to directly produce a public version of the key stream Extracts the key data and passes it on or uses it CKA_ALLOWED_MECHANISMS is currrently only way to protect against this, but attribute is non-sticky.

Secondary Key Protection (3) General method of attack for C_UnwrapKey is that attacker Has use of unwrapping key Has access to wrapped key data Unwraps the wrapped key But sets attributes of unwrapped key so key data is extractable Extracts key data and passes it on or uses it CKA_UNWRAP_TEMPLATE enforces attributes of unwrapped keys But CKA_UNWRAP_TEMPLATE is not currently sticky, so trivial for attacker to remove it in C_CopyObject or by C_SetAttributeValue Some vendors did fix this though. Possible for legitimate user to screw up unwrap configuration

Secondary Key Protection (4) Fixes? Specify a mechanism to enforce policy on derived keys I.e., CKA_DERIVE_TEMPLATE Since derives can be multilevel, mechanism must be able to propagate through each level of derive Revisit default and permitted sensitivities for all derive mechanisms (e.g. default is at least as sensitive as key being derived from, but if template is provided at original key creation, permitted values can be weaker If done this way, template can only be applied at key creation and is read-only or prohibited after (otherwise violates the “changes must be in direction of more secure” policy

Secondary Key Protection (5) Example: TLS wants to protect pre-master and master secret from extraction, but wants to export mac and encryption secrets for use by general purpose processor. Default for TLS would be if pre-master and master were “sensitive” and “non-extractable” then so would derived keys Template would allow for easing restriction at creation of master secret

Related Items CKK_GENERIC_SECRET Can be used with derivation, CMAC and HMAC mechanisms Problematic for policy controls especially as C_Derive mechanisms use underlying CMAC or HMAC PRFs Perhaps instead: CKK_MASTER_SECRET – can be used with C_Derive mechanisms only CKK_AES_CMAC, CKK_DES_CMAC etc (or only CKK_CMAC?) CKK_SHA1_HMAC, CKK_SHA2_HMAC (or CKK_HMAC? Or CKK_SHA(224|256|384)_HMAC?)