PKCS11 Key Protection And the Insider Threat - PowerPoint Presentation

Slide1

PKCS11 Key Protection

And the Insider ThreatSlide2

Outline

The

Insider Threat

Existing Protection Mechanism

Primary Key

vs

Secondary Key

Primary Key Protection

Secondary Key Protection

Related ItemsSlide3

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

)Slide4

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 trueSlide5

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 attributeSlide6

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

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 tokenSlide8

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 attributesSlide9

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_TEMPLATESlide10

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_KEYSlide11

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 keysSlide12

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

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 configurationSlide14

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” policySlide15

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 secretSlide16

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