1. PKCS11 Key Protection
And the Insider Threat

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

3. 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)

4. 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

5. 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

6. 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.

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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.

13. 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

14. 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

15. 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

16. 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?)