[TLS] TLS and hardware security modules - some issues related to PKCS11

[Michael StJohns <[e-mail]>]

HI -

I'm currently working with the PKCS11 group in Oasis.  One of the items 
for the new draft (2.40) was adding PKCS11 mechanism definitions for 
TLS1.2.  As part of that, I started looking closely at TLS and its key 
derivation mechanisms.

Hardware Security Modules (HSMs) are used both for cryptographic 
acceleration, and for protection of key material.  The way TLS (1.0, 1.1 
and 1.2) does its key derivations pose a number of challenges for that 
second goal.

Consider the typical chain of derived material generated for a TLS 
connection:

(keywrap or key agreement) -> pre-master secret

pre-master secret -> master secret

master secret -> mac key client
                          -> mac key server
                          -> encrypt key client
                          -> encrypt key server
                          -> client IV (public data)
                          -> server IV (public data)

master secret -> client finished "mac" (public data)
                          -> server finished "mac" (public data)

All of these are produced through the application of the TLS PRF to a 
key using a specific  "label" and other data.   In PKCS11 v2.40, the 
CKM_TLS_PRF mechanism can be used with a key to produce public data.  
This is used both to produce the finished verify_data and for the more 
general use of key exporters.  However, as defined, there is no 
restriction on using that function with any tls "label" and with any 
other additional data.  That basically allows someone who has access to 
"use" the master_secret with the "key expansion" label and the random 
data to produce a public version of the mac and encryption keys.

In the current PKCS11 draft to fix the above, the CKM_TLS_PRF user 
accessible mechanism has been deprecated in favor of a TLS KDF that can 
be used for a key exporter (and produces only private key material), and 
a TLS MAC that is used to produce the finished message verify data 
(public data). The latter function doesn't allow a label to be supplied, 
but instead takes a parameter that references two fixed label values - 
those associated with the finished message verify_data.

That still leaves a second problem.  The "key expansion" stage produces 
both private (key material) and public (iv data) by producing a key 
stream and then splitting up (based on the sizes of keys needed) into 
the 4 keys and 2 IVs.

o Consider  an application that needs to produce 2 128 bit AES keys and 
2 IVs (for say GCM).
o Consider that an attacker (or a hacked program that's being used to 
extract keys) re-runs the derivation using the same master key and same 
random data, this time specifying zero length keys (or 64 bits of keys 
etc), but still asks for the IV material.

The part of the key stream previously assigned to the encryption keys is 
now assigned to the IV material.  Since IVs by their nature are public, 
the attacker now has direct access to the key material previously used 
for encryption.

Fortunately, TLS1.1 changed the way IVs were calculated making it 
possible to prohibit that leaking.  Unfortunately, the CCM and GCM 
mechanisms for TLS1.2 decided to use the IV values making impossible to 
prohibit the leaking.

For the current PKCS11 draft, we finessed it by creating two mechanisms 
- one that created only key material, and one that created key material 
and IVs.  PKCS11 allows a specific key to be constrained to a specific 
mechanism so that permits some security for the non-AEAD suites.  It's 
not ideal, but its a beginning


Going forward (e.g. TLS1.3 and any revision to the TLS1.2 AEAD 
mechanisms) , I'd like to recommend the following changes to the "key 
expansion" derivation step (this replaces text in section 6.3 of RFC5256):

>>  When keys and MAC keys are generated, the master secret is used as an
>>    entropy source.
>>
>>    To generate the key material, compute
>>
>>       key_block = PRF(SecurityParameters.master_secret,
>>                       "key expansion",
>>                       SecurityParameters.server_random +
>>                       SecurityParameters.client_random);
>>
>>    until enough output has been generated.  Then, the key_block is
>>    partitioned as follows:
>>
>>       client_write_MAC_key[SecurityParameters.mac_key_length]
>>       server_write_MAC_key[SecurityParameters.mac_key_length]
>>       client_write_key[SecurityParameters.enc_key_length]
>>       server_write_key[SecurityParameters.enc_key_length]
> *** Change begins here
>>       iv_subkey [32 bytes] (if IV material is requested)
>>
>>    The IV's are generated by computing
>>
>>       iv_block = PRF (iv_subkey,
>>                            "iv generation",
>>               SecurityParameters.server_random +
>>               SecruityParameters.client_random);
>>
>>    until enough output has been generated.  Then the iv_block is
>>    partitioned as follows:
>>
>>       client_write_IV[SecurityParameters.fixed_iv_length]
>>       server_write_IV[SecurityParameters.fixed_iv_length]
>>
>

Basically, doing it this way places a "firewall" between the private 
data and the public data that can't be trivially defeated by varying the 
length of the requested key material.

Alternately, the IV production as part of key expansion could be removed 
completely and crypto suites directed to find another way of selecting 
the IV.

Thanks - Mike