pkcs11 key protection n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
PKCS11 Key Protection PowerPoint Presentation
Download Presentation
PKCS11 Key Protection

Loading in 2 Seconds...

play fullscreen
1 / 16

PKCS11 Key Protection - PowerPoint PPT Presentation


  • 139 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'PKCS11 Key Protection' - inigo


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
pkcs11 key protection

PKCS11 Key Protection

And the Insider Threat

outline
Outline
  • The Insider Threat
  • Existing Protection Mechanism
  • Primary Key vs Secondary Key
  • Primary Key Protection
  • Secondary Key Protection
  • Related Items
the insider threat
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
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
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
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
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
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
primary key protection 2
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
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
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
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
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
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
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
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?)