PKCS11 Key Protection

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 • But not sticky, so attacker can change • 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?)