General Philosophy - What starts in the HSM, stays in the HSM.

[Michael StJohns <msj@nthpermutation.com>]

Hi

I've submitted a lot of proposals since we got this effort started. Most 
if not all of these proposals have been to deal with the current 
shortcomings of the key policy model with respect to whether or not a 
key can be extracted from the HSM. (or for things like CKM_SEAL_KEY - 
extracted outside of the cryptographic boundary). I wanted to try and 
explain what I believe are the shortcomings, and why I believe they 
exist.  Some of these could be 2.40.  Some of these must be deferred to 
3.0. The rest could go either way.

My first assumption is that, for most keys, the use of the keys is not a 
person but an application and that PIN values and other token 
credentials are mostly embedded in the application.  I'd like to be able 
to build a set of keys that are resistant to an authorized (with PIN) 
but illegitimate (attacker) entity being able to extract them from the 
HSM.  E.g. as long as I have physical control of the HSM, I'm pretty 
sure there are no copies of the keys that originated in the HSM in the 
clear somewhere outside the HSM.

Consider the following scenario:  I (as the application manager) 
generate an EC key pair.   The application, as it needs keys, does EC 
and KDF operations to get key material, and tags that material as 
private and sensitive.  An attacker gets access to the HSM at a later 
point in time.  The keys are still intact, but the attacker got physical 
or network access to the HSM.  He now uses PKCS11 to repeat the EC and 
KDF operations, but this time tags the material as not-private and/or 
not-sensitive and it is now extractable from the HSM.   Depending on the 
use environment, this could be done covertly.  The attacker, may - 
depending on the protocol - be able to use the key material to covertly 
control part of the network.

Proposed solution: Add CKA_DERIVE_TEMPLATE attribute to keys used for 
key derivation or for key agreement.  This allows the mandatory addition 
of CKA_PRIVATE and CKA_SENSITIVE attributes that holds even if the 
derivation mechanism allows the derived keys to be set to less 
sensitivity than the key's they are derived from.

Consider the following scenario:  The application generates a master key 
(or derives one using ECDH) inside the HSM and marks it private and 
sensitive.  It then generates a key hierarchy based on that master key 
and a kdf and some public data.  It then, at some point. An attacker 
later uses that same master key against the PRF underlying the KDF to 
produce the key stream it previously used to derive the key hierarchy.  
(E.g. the KDF produces keys, the HMAC function under the KDF produces 
public data).    If done covertly, the attacker (say another process on 
the same machine as the application), could then use the key stream 
material to read the confidential data of the application (e.g. this is 
the problem with the current TLS based mechanisms).

Proposed solution: (3.0) Deprecate existing TLS mechanisms, add 
C_DeriveKeys as a command to allow multiple keys per derive, add a TLS 
Mac mechanism that can't be used to extract key material.

Consider:  I create a key to wrap other keys.  I set up both a wrap 
template and an unwrap template.  I wrap several keys, trusting in that 
the unwrap template will ensure that unwrapped key will be treated as 
sensitive and private.  The attacker comes along with access to the HSM, 
he changes/deletes the CKA_UNWRAP_TEMPLATE of this key, and unwraps all 
those keys I thought were safe in a manner to allow them to be extracted.

Proposed solution:  Make CKA_UNWRAP_TEMPLATE a set once/read-only 
attribute.  This exactly mirrors CKA_UNWRAP_TEMPLATE

Consider:  I create a symmetric key to wrap other keys.  I'd like to 
mark it trusted, so that I can use the CKA_WRAP_WITH_TRUSTED attribute, 
BUT  the symmetric key has to be private otherwise anyone could use it.  
However, you need to be an SO to set CKA_TRUSTED, but an SO can only see 
CKA_PRIVATE=false data. So this is mostly impossible inside of PKCS11.  
(Note that this works with asymmetric keys as the public key is 
generally CKA_PRIVATE=false and can be set as CKA_TRUSTED=true).

Proposed solution: Add CKA_UUID to identify keys specifically and 
uniquely.  Add CKA_WRAP_WITH_UUID to link a key to a specific wrapping 
key at creation (this is also a set once, read-only attribute).


Consider: (defer to 3.0)  Good cryptographic practice generally 
restricts a key to one mode or usage model.  However, keys are rarely 
created with specific CKA_ALLOWED_MECHANISMS attributes.  And that has 
led to problems, especially with KDF  models.  E.g. being able to use 
the same generic master secret for the TLS KDF and the TLS PRF - private 
data producer and public data producer.

Proposal: Completely re-work the CKA_GENERIC_SECRET model - e.g. replace 
it with CKK_MASTER_KEY for kdf derivation keys (and the shared secret 
produced by DH and ECDH).  CKK_*_HMAC for hmac keys (either class - 
SHA1, SHA2 or specific SHA256), CKK_*_CMAC for cipher based MAC's  so 
these don't bleed over everthing.  There may need to be a CKK_TLS_MASTER 
which can be used for both the TLS KDF and the TKS MAC.  Deprecate 
CKA_GENERIC_SECRET unless someone can think of a use for it.

Proposal: identify those mechanisms (e.g. CKM_AES_GCM and CKM_AES_CCM) 
that have some restrictions (e.g. not allowing data to be released until 
the integrity tag verifies) that could be circumvented by letting the 
key be used with CKM_AES_CTR and CKM_AES_CMAC or CKM_AES_GMAC and note 
that keys can only be used with those mechanism if the key has a set 
CKA_ALLOWED_MECHANISMS consisting only of that mechanism.  *sigh*


This is food for thought - not food for a food fight.  Feel free to 
segment out individual proposals and scenarios and comment on them 
individually.

Mike