Re: [TLS] HSM-friendly Key Computation

On 4/19/2015 12:22 AM, Peter Gutmann wrote:
> Russ Housley <housley@vigilsec.com> writes:
>
>> If one wants to implement the cryptographic functions in a Hardware Security
>> Module (HSM), this structure is far from ideal.
> Weelll... it's far from ideal if you want to use traditional/historic PKCS #11
> mechanisms, but since a new PRF will need updated HSM support anyway

And that's where we differ I think.
> it
> shouldn't be any problem to accommodate it, and now that PKCS #11 is being
> managed by OASIS rather than RSADSI/EMC and things have got moving again in
> advancing the spec, it shouldn't be that big a deal.  If you look at how
> CKM_TLS_PRF works, it's a significant change from how C_DeriveKey() normally
> functions that was made in order to accommodate how TLS wants to do things.
> For the TLS 2.0 (a.k.a. 1.3) PRF the PKCS #11 folks can make the same
> accommodation.  It's an issue for the HSM vendors to adapt, not the TLS spec
> to adapt.

It's not exactly that.   If you go back and look at PKCS11 2.20 , you'll 
note that they just placed the TLS/SSL  functionality in by rote - 
mainly by hacking the PKCS11 mechanism construct to provide a way of 
outputting multiple keys.

There are actually SSL mechanisms:

CKM_SSL3_MASTER_KEY_DERIVE
CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_SSL3_PRE_MASTER_KEY_GEN
CKM_SSL3_MASTER_KEY_DERIVE_DK

And TLS mechanisms

CKM_TLS_PRE_MASTER_KEY_GEN
CKM_TLS_MASTER_KEY_DERIVE
CKM_TLS_KEY_AND_MAC_DERIVE
CKM_TLS_MASTER_KEY_DERIVE_DH

They also handily provided the CKM_TLS_PRF  mechanism which basically 
allowed you to extract ANY key stream material from a given master 
secret (since all the bytes from a call using this mechanism were 
provided nicely packaged in the place specified in the mechanism 
structure).  But that was as was requested by TLS implementers and 
probably didn't get enough vetting by the security deep thinkers.

CKM_SSL_KEY_AND_MAC_DERIVE, CKM_TLS_KEY_AND_MAC_DERIVE and CKM_TLS_PRF 
are insecure in that they allow trivial extraction of material from a 
derived key stream.   That is an artifact of multiple things:  how the 
TLS KDF function is currently defined, the use of key exporters with out 
a model for cryptographic separation; the use of TLS specific functions.

PKCS11 tries to fix the worst of these in the new version when it added 
support for TLS1.2: 2.40 deprecates CKM_TLS_PRF, adds a CKM_TLS_MAC 
function for signing the finished messages, deprecates 
CKM_TLS_KEY_AND_MAC_DERIVE in favor of CKM_TL12_KEY_SAFE_DERIVE. There 
is a CKM_TLS12_KEY_AND_MAC_DERIVE, but it comes with a black box 
warning.  Its there only because the current AEAD suites require a 
source of session nonce information and they get it from the IV production.

What I would love to see for TLS1.3 is NO TLS specific mechanisms being 
added to PKCS11.    That if we still sign the finished message, we use a 
true MAC function.  That if we derive keys, we use a bog standard KDF.  
That we stomp on every TLS specific twist unless there is a specific 
security need to keep TLS secure.

At this point the set of KDFs in PKCS11 is very protocol specific and 
constitute a good part of the non-common mechanisms.  Most of the rest 
seem to relate to one family or another (e.g. suite b, GOST, etc).  It 
would be great if we could pick a standardized KDF of family of KDFs for 
the IETF and not go through this again.

Mike

>
> Peter.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls