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

From: Michael StJohns <[email-masked]>
Date: Fri, 06 Sep 2013 00:10:36 -0400

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

---

From: "Juraj Somorovsky" <[email-masked]>
Date: 17 Sep 2013 00:47:03 +0200

Hi Mike,

> etc), but still asks for the IV material.
Just a quick questions:
I do not know if I understand this scenario correctly...but how can this
be achieved in TLS?
New key/IV material is always generated from client's as well as
server's random. The attacker can choose the same client random, but he
cannot influence the server random... thus always new key/IV material is
generated.

Maybe in a PKCS11 scenario this is different?
> not ideal, but its a beginning
I would propose to make it more concrete for PKCS11 and generate the
keys depending on the algorithms they are used in. For example, if you
have a master_secret used to generate keys for AES_GCM and AES_CBC, you
would use:
k_GCM = PRF(master_secret, "AES_GCM", [further params])
k_CBC = PRF(master_secret, "AES_CBC", [further params])

This ensures that the attacker cannot enforce the same key is used for
two different algorithms, which could lead to some specific attacks (for
more information see our paper on Backwards compatibility attacks:
http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/)

Best Regards
Juraj

---

From: Michael StJohns <[email-masked]>
Date: Mon, 16 Sep 2013 19:37:39 -0400

> cannot influence the server random... thus always new key/IV material is

This isn't about influencing the new key, but being able to extract the 
old key.  Assume the attacker a) has use of the master key (either 
because he's running as hacked code, or because he managed to capture 
the PKCS11 pin and has access to the PKCS11 module), b) has captured all 
the necessary public data (e.g. has the previous random values from 
listening to the TLS exchange).   He then calls PKCS11 with the master 
key, the random data, but specifies that he needs smaller (e.g. no) mac 
and encryption keys.  The part of the key stream previously assigned to 
the mac and encryption keys (and safely protected inside the PKCS11 
module) is now assigned to the IV part of the structure and is now 
accessible to the attacker/caller of the module.   That attacker then 
takes that data and sends it off to someone who can intercept the 
traffic somewhere in the middle. There are a number of sub-scenarios 
which are dependent on where the PKCS11 module is, and where the 
attacker is and where the data is intercepted.

> k_CBC = PRF(master_secret, "AES_CBC", [further params])

As long as you can control the length of the encryption and mac key in 
the call to PKCS11, you have an issue if you can produce IV material 
from the same key stream you use to produce encryption or mac keys.    
If you're suggesting using the above for generating IV material, it's 
doable, but maybe a bit of overkill.  I'd rather generate the IV from 
the public information only (e.g. only use the random data as the PRF seed).

Mike

---

From: [email-masked] (Martin Rex)
Date: Tue, 17 Sep 2013 14:49:48 +0200 (CEST)

I fail to understand what you're trying to protect.

The master secret of a session is never a secret that is hidding
within the hardware module, instead, it is something known to the
calling TLS protocol stack and part of the TLS session cache.

For vanilla RSA cipher suites, it is deterministically derived
from randomness generated by the client and conveyed under
RSA encryption, deterministically combined with data known
in plain to the TLS protocol stack.

-Martin

---

From: Pascal Urien <[email-masked]>
Date: Tue, 17 Sep 2013 14:57:00 +0200

Why don't you realize a TLS stack in a secure element ?. For both full and
resume mode , in order to protect the master secret

see
http://www.ethertrust.com/wp-content/themes/ethertrust/about_ethertrust.pdf

Pascal

2013/9/17 Martin Rex <[email-masked]>

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 17 Sep 2013 11:45:43 -0400

> calling TLS protocol stack and part of the TLS session cache.

Um.  No, not if you designed things properly.  It should be possible for 
any protocol the IETF designs to do all the crypto operation inside a 
hardware module and not depend on the weak security of a general purpose 
computer.

I want to protect inside of the HSM all of the following:

a) the private keys related to the server or client identity
b) the pre-master key
c) the master key
d) the session keys.

I want to be able to do all the cryptographic processing inside that 
module and only allow out true plain text.

> in plain to the TLS protocol stack.

I think you're talking about the pre-master secret?  If so, yes, but 
so?  The encrypted pre-master secret goes to the HSM where it's 
decrypted, run through a KDF and used to produce the master secret. 
Ideally, that master secret may be retained within the HSM and protected 
from disclosure.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 17 Sep 2013 11:52:10 -0400

On 9/17/2013 8:57 AM, Pascal Urien wrote:
> Why don't you realize a TLS stack in a secure element ?. For both full 
> and resume mode , in order to protect the master secret
> see 

This is a valid solution, but doesn't actually match what PKCS11 is 
designed to do - e.g. provide generic access to cryptographic functions, 
rather than build the TLS stack inside the token.

Also, the above doesn't provide any support for TLS key material 
exporters. (And wasn't that a problem to solve with PKCS11 safely).

The nice thing about PKCS11 is that its a toolkit that can be used for a 
lot of things - not just TLS.

Mike

>
>
> 2013/9/17 Martin Rex <[email-masked] <mailto:[email-masked]>>
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Sep 2013 12:00:41 -0400

>I want to be able to do all the cryptographic processing inside that module and only allow out true plain text.

The programming model for such a beast is probably more like an I/O processor than an HSM.  You need input and output "local plaintext" data streams, and the same for "to/from the network crypto streams."  And ways to signal "I can't give you more plaintext until you write this on the network and get more data back from the other side."  And so on.

Have you seen a market need for this kind of thing?  Have you got an API designed?  I'd be curious about both.

I also don't understand why you do not trust the host software with the ability to decrypt its own data (i.e,. session) when you don't have control over what it does with the plaintext, like copy it over to an adversary directly.

	/r$
 
--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 17 Sep 2013 12:13:09 -0400

On 9/17/13 12:00 , "Salz, Rich" <[email-masked]> wrote:

>The programming model for such a beast is probably more like an I/O
>processor than an HSM.  You need input and output "local plaintext" data
>streams, and the same for "to/from the network crypto streams."  And ways
>to signal "I can't give you more plaintext until you write this on the
>network and get more data back from the other side."  And so on.
>

Doesn't HAIPE do something like that?

http://en.wikipedia.org/wiki/High_Assurance_Internet_Protocol_Encryptor

>I also don't understand why you do not trust the host software with the
>ability to decrypt its own data (i.e,. session) when you don't have
>control over what it does with the plaintext, like copy it over to an
>adversary directly.

I guess this is more about protecting the cryptographic keys and
infrastructure rather than protecting plaintext of a given session (which
belongs to the application who is free to do with it whatever it wishes).

---

From: [email-masked] (Martin Rex)
Date: Tue, 17 Sep 2013 18:14:48 +0200 (CEST)

> Ideally, that master secret may be retained within the HSM and protected 

Typically, the PKCS#11 module will export an RSA PKCS#1 v1.5 decryption
primitive, and the server will typically be able to pass the encrypted
premaster-secret, reference his strongly protected server credentials
and obtain the RSA-decrypted output.  Once that decrypted pre-master
secret is obtained, everything else is deterministic.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Sep 2013 12:16:28 -0400

> http://en.wikipedia.org/wiki/High_Assurance_Internet_Protocol_Encryptor

I didn't see any mention of TLS.

> belongs to the application who is free to do with it whatever it wishes).

Yes, but why protect the *session key* from the application?

---

From: Michael StJohns <[email-masked]>
Date: Tue, 17 Sep 2013 12:26:24 -0400

> The programming model for such a beast is probably more like an I/O processor than an HSM.  You need input and output "local plaintext" data streams, and the same for "to/from the network crypto st…

What?  No.

TLS is pretty much a two stage beast:

1) Figure out the keys. (TLS handshaking, data gathering, key transport 
and/key derivation).
2) use the crypto suite and the keys from (1) to encrypt and decrypt the 
messages.

Both of these are general purpose crypto operations.  How you get there 
is wrapped in TLS protocols, but the HSM doesn't actually need to know 
anything about TLS except its defined cryptographic operations (e.g., 
PKCS11 implements all of the various cipher and mac modes, implements 
signature creation and verification, and in addition, implements the TLS 
specific KDF (the TLS PRF in its various uses)).

> I also don't understand why you do not trust the host software with the ability to decrypt its own data (i.e,. session) when you don't have control over what it does with the plaintext, like copy i…

Small amounts of data (e.g. recovered keys) might be missed.  Harder to 
miss pretty much a doubling in traffic (e.g. a complete copy of the 
decrypted stream now being sent to the adversary).

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Sep 2013 19:05:27 +0200

On Tue, Sep 17, 2013 at 5:45 PM, Michael StJohns <[email-masked]> wrote:

> Um.  No, not if you designed things properly.  It should be possible for any
> protocol the IETF designs to do all the crypto operation inside a hardware
> module and not depend on the weak security of a general purpose computer.

What you care is protection of the long term keys by the security
module. Are you really sure you want to protect the temporal session
keys (i.e. TLS master key) as well? What do you gain if you do that?
If you want to protect the key from a software vulnerability that
gives access to the system to an adversary, then you have succeeded
your goal to protect the key but failed on the goal to protect the
data the key is encrypting/decrypting. Thus making the effort to
protect the session key pretty futile, as it is as important as the
data it protects.

> a) the private keys related to the server or client identity

This makes sense because a private key is used more than one sessions
and can be used to attack future (and in some cases past sessions).

> d) the session keys.

All of these are session-specific keys and protect the data that are
exchanged in that particular session. IMO there is no much sense
trying to isolate them from the software handling the data.

regards,
Nikos

---

From: Bill Frantz <[email-masked]>
Date: Tue, 17 Sep 2013 17:21:05 -0700

On 9/17/13 at 8:45 AM, [email-masked] (Michael StJohns) wrote:

>Um.  No, not if you designed things properly.  It should be 
>possible for any protocol the IETF designs to do all the crypto 
>operation inside a hardware module and not depend on the weak 
>security of a general purpose computer.

While I have no objections to this requirement, I'm not sure 
that hardware is more secure than software if your attacker is a 
large country national crypto agency or sophisticated criminal 
gangs. I worry about Russia, England, China, France etc. as well 
as the USA.

Without taking the chips apart, even validated hardware can be 
replaced at the chip foundry with a different implementation 
which leaks keys via paths such as IVs or uses bogus random numbers.

These attacks can be minimized by using forward security -- more 
keys to attack/leak; making IVs deterministic based on the plain 
text and checked; using a cypher in counter mode for IVs, 
calculating them separately at each end, and not transmitting 
them etc.

There is no real safe heaven these days.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Truth and love must prevail  | Periwinkle
(408)356-8506      | over lies and hate.          | 16345 
Englewood Ave
www.pwpconsult.com |               - Vaclav Havel | Los Gatos, 
CA 95032

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 18 Sep 2013 13:15:10 -0400

Bill,

In short, I concur. Though some hardware is known to be more secure than the other. ;)
--
Regards,
Uri               <[email-masked]>

---

From: "Juraj Somorovsky" <[email-masked]>
Date: 19 Sep 2013 09:38:54 +0200

> attacker is and where the data is intercepted.

Thanks for the explanation, I understand it now. If this is how PKCS11
modules could be used in SSL, I admit this is a threat and agree with
your changes.

> the public information only (e.g. only use the random data as the PRF
Let me please extend your scenario:
o Consider  an application that needs to produce 2 128 bit AES keys.
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 64 bits of DES keys.
o Consider that the attacker can "break" DES (can get key from
plaintext-ciphertext pairs), but cannot break AES.

The part of the key stream previously used for AES is now assigned to
the DES keys. If the PKCS11 module now produces some
plaintext-ciphertext pairs, the attacker can break DES and thus gets
part of the key stream previously assigned to AES.

I admit I am not that familiar with PKCS11 modules used in
TLS...However, would this be a valid scenario?

My previous point was to extend your algorithm to force different keys
for different security algorithms.

Thanks
Juraj

---

From: Michael StJohns <[email-masked]>
Date: Sat, 21 Sep 2013 14:49:53 -0400

I'm going to top post - this is a general response to three messages 
with the gist "why do you want to protect the session keys inside the HSM"?

The threat model I'm trying to protect against is an authorized user of 
the HSM (hardware security module) keys who is none the less illegitimate:

  o someone who stole the PIN or credential to access the HSM
  o a hacked program that is doing everything the original program was 
designed to do, but is also extracting and relaying data to a third party.

In both of these cases, assume that the design of the TLS protocol (or 
the HSM module) is such that the session keys can be extracted (either 
by design, or as a side effect of things like how the key expansion 
stage was defined).

Assume that an attacker can extract the session keys and send them to a 
third party.

Assume that the sending of a few key blobs (containing the extracted 
session keys) is less detectable than sending the entire stream of a TLS 
connection.

Assume that the third party can capture the TLS  packet stream at some 
point between the originator and destination.

Given these assumptions: an attacker can use the combination of key 
extraction and packet interception to do virtually undetectable 
interception of the decrypted stream.  Worse, it may be able to change 
the bits actually received in an undetectable manner.

Continuing on this - a smart attacker can decouple the key capture in 
time from the delivery of the key to an attacker.  E.g. batches up the 
capture of 50-100 key states and sends it to the third party maybe once 
a day.  Or publishes it as a steno on on the web server that was hacked. 
or... you get the idea.   As long as the attacker has a copy of the 
encrypted stream of data, he can do the decryption any time after he 
retrieves the key.

I'm of the opinion that it makes sense to make things harder on an 
attacker, and that means doing virtually all of the cryptographic 
operations within a cryptographic boundary.     There are times where 
this is neither necessary nor desirable, but for TLS, I would say that 
this should apply to most communications where there is real-world value 
involved, especially at the server side.

With respect to the specific TLS protocols and my suggestions about the 
key expansion stages, I'm hoping to get it to the point where the 
trivial key extraction attacks enabled by the current key expansion 
mechanism no longer exist.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Sat, 21 Sep 2013 15:09:10 -0400

> TLS...However, would this be a valid scenario?

Yes and yes.

Yes - PKCS11 doesn't actually get any information on the specific TLS 
suite, so it doesn't know what keys are required or their length.   And 
the suites are all over the place in required keys and lengths - the 
null encryption suites don't require encryption keys, and the AEAD 
suites don't require MAC keys, so PKCS11 can't really enforce minimum 
lengths there.

Yes - yuck - I didn't even consider this.  Even if you don't leak out 
into the IV, there are crypto algorithms still in use with way too short 
key lengths.  You could do exactly what you said and use this to brute 
force the DES 56 bit keys (plus 8 parity) and then concatenate the 
individual results to get the AES keys.

Thanks for this.  I think it can be fixed though and relatively simply, 
but will require changes to the key expansion step that are a bit more 
than I suggested:

E.g. in addition to the master_key, label and random data being fed into 
the KDF, also feed in - in order for each output key - 2 or 4 bytes each 
that describe the length of the key.  And that's taken directly from the 
inputs for the key lengths requested.

That means that any time you vary the length of ANY key in the key 
expansion, the entire key stream changes.

It also means that there isn't a need for a separate IV sub key for the 
key expansion stage (I think....)

I'll write it up.

Mike

---

From: "Juraj Somorovsky" <[email-masked]>
Date: 23 Sep 2013 11:20:36 +0200

> key expansion stage (I think....)
I do not think this is enough to solve this problem. There are
algorithms that have the same key and IV lengths....e.g. an AES-128 key
has the same length as the IV used in AES-CBC. I think this would break
your key derivation???

An additional problem is that the same key would be used for the same
block ciphers in different modes of operation, e.g. AES-CBC would use
the same key as AES-GCM.

As mentioned in my previous post, a solution would be to derive the
material based on the master secret and the encryption scheme / IV it is
used for. For example you could derive :
- a symmetric key for AES-GCM:
k_GCM = PRF(master_secret, "AES_GCM", [further params])
- a symmetric key for AES-CBC:
k_CBC = PRF(master_secret, "AES_CBC", [further params])
- initialization vector:
IV = PRF(master_secret, "IV", [further params])

This solution however assumes that if k_GCM is generated, the attacker
cannot enforce the PKCS11 module to use it for the AES-CBC computation.
Again, I am not that familiar with PKCS11...can this be achieved in a
typical PKCS11 module?

In other words: can a PKCS11 module admin/user enforce that if a
specific material is derived with a "AES-GCM" parameter, the resulted
key can only be used in AES-GCM?

Thanks
Juraj

---

From: Michael StJohns <[email-masked]>
Date: Mon, 23 Sep 2013 12:29:30 -0400

> has the same length as the IV used in AES-CBC. I think this would break

The general problem here is that pretty much all encryption modes are 
based on ECB - if you can do ECB, you can do the operations that make up 
the mode.

I don't think this is as much of an issue.  The DES key issue was of 
more interest because its substantially easier to brute force 2 keys of 
length 64 than it is a single key of length 128.  This appears to be no 
change in the attack surface to extract the key.

> IV = PRF(master_secret, "IV", [further params])

The issue with the above approach is that the KDF is currently pretty 
generic - a key plus some public data (e.g. the label, the random 
stuff.  I can't prevent a re-derivation using whatever label the 
attacker wants to use.  So it would be pretty easy to generate either 
k_GCM or k_CBC given the master secret and the random stuff.

But mostly, I don't see this as a large threat  - how would this benefit 
an attacker with access to the master key?

The arguments against CBC tend to be with respect to attacks to recover 
the plain text, not the key.  The question I would ask for the above is 
whether being able to use the same AES key in multiple encryption modes 
provides additional attack surface to recover the key?  If not, then 
it's a don't care for PKCS11 I think.

> key can only be used in AES-GCM?

The admin can restrict a specific key to a specific set of mechanisms - 
e.g. CKM_AES_GCM.  There are some problems with this approach which 
we're working through having to do with how the restrictions are set and 
how they're retained across derivations.

Mike

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 23 Sep 2013 16:51:31 +0000

Comments in-line.

>change in the attack surface to extract the key.

Agreed. But this is not the only attack of interest. See below.

>an attacker with access to the master key?

Juraj was too polite to point out this paper from NDSS 2013:

http://www.isg.rhul.ac.uk/~kp/BackwardsCompatibilityAttacks.pdf

for an example of what can go wrong when the same key is used in two
different modes one of which
is subject to plaintext recovery attacks (full disclosure: Juraj and I are
co-authors on this paper along
with Tibor Jager).

TL;DR: you can recover low entropy GCM plaintexts if the same key is used
in a mode like CBC.

>provides additional attack surface to recover the key?

Not as far as we know. But if I can recover your AES-GCM plaintext,
wouldn't you
just be a little bit concerned?

>If not, then 

So, do you care now? :-)

Cheers,

Kenny

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 23 Sep 2013 11:18:25 -0700

I've been trying to follow this discussion and it appears to me that the
goal is to have a HSM that protects the master secret and session keys
internally, yet also allows for extractors to ask the HSM to run the PRF
for them.  The problem is that a naive HSM might be tricked into revealing
the session keys.

Couldn't this be dealt with by having the HSM simply refuse to compute the
PRF given a label of "key expansion"?  Any other label should cause the
output to differ wildly from the session keys, right?

Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 23 Sep 2013 15:00:35 -0500

> module and not depend on the weak security of a general purpose computer.

But evidently you must care about the application plaintext.  Why not
move the application into the HSM as well then?

That deserves a tongue-in-cheek smiley, of course :^)

> a) the private keys related to the server or client identity

Sure.

> and only allow out true plain text.

Why?  The HSM will become a cryptographic decelerator if you do that,
unless it's a fantastically expensive HSM anyways, and even then there
will be latency costs.  Meanwhile the session keys are of little or no
additional value to the application plaintext, and you're leaving the
application outside the HSM (of course, for obvious reasons).

So why do this?  The one answer that comes to mind is: to make sure
you get the crypto right, without possibility of screwups/backdoors in
various OS components (e.g., RNG).  But the performance cost more than
outweighs that answer in most of the use cases I can think of.

Nico
--

---

From: Michael StJohns <[email-masked]>
Date: Mon, 23 Sep 2013 16:30:49 -0400

Comments in line.  Previous text omitted.

> TL;DR: you can recover low entropy GCM plaintexts if the same key is used

Right.  But you can't recover the key.

Let me reiterate the threat model:

1) All keys are kept in an HSM (not supposed to be extracted - but TLS 
KDF trivially allows this)
2) Attacker has access to use the keys (e.g. either has HSM credentials, 
or has hacked the program using the HSM that has HSM credentials - the 
TLS stack for example).

Because of (2), the attacker can directly decrypt the cipher text (or 
already has access to the plain text), so an attack where I can force 
the HSM to use multiple cipher modes for the same key is no worse than 
what's already happening.  I'm trying to prevent key recovery attacks 
with this change, NOT plaintext recovery attacks.

I agree that it would be useful to prevent (by HSM policy) a key from 
being used with both CBC and GCM, but the actual threat is a protocol 
one, rather than solely an HSM one assuming the attacker already has 
access to use the key in the HSM.  PKCS11 *does* have some of this, but 
it turns out that its difficult to employ on derived keys (e.g. by ECDH, 
DH or by KDFs) in a manner that prevents attacks based on re-derivation 
of the key.

In some respect,  the selection of IVs for GCM - e.g. no repeats - could 
be viewed as an HSM problem (rather than a protocol problem), but the 
HSM may not (and generally does not) have knowledge of each and every 
previously IV used with the key.  The current PKCS11 API doesn't 
actually provide for the ability to have the HSM link the IV state to 
the key used to the encryption mode - it's one of the things we're 
considering for 3.0 though.

Right now I'm trying to deal with the wide range of problems a piece at 
a time.  In this case, the TLS KDF mechanism has substantial challenges 
with being implemented securely in an HSM - unless the HSM is really a 
TLS accelerator and all the TLS negotiation  and encryption is done 
inside the HSM.  That's one implementation choice - but PKCS11 is 
defined for a more general model where it can be plugged in to support 
lots of different protocols.

> just be a little bit concerned?

See above.

>> it's a don't care for PKCS11 I think.

Still no I think.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 23 Sep 2013 16:31:13 -0400

> http://www.isg.rhul.ac.uk/~kp/BackwardsCompatibilityAttacks.pdf

By the way - nice paper.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 23 Sep 2013 16:47:44 -0400

> That deserves a tongue-in-cheek smiley, of course :^)

There are SSL/TLS accelerators that move a whole bunch more of the 
crypto stuff inside the HSM, but PKCS11 is designed to be useful for 
more than just TLS.

> outweighs that answer in most of the use cases I can think of.

Consider a specific field of use - 10s of Millions of smart grid capable 
electric power meters.  Consider that I have a back office system that 
talks to each and every one of them securely.  Consider that I'm worried 
about insider threats with respect to reading and controlling (e.g. 
remote disconnection of the meters) these devices.  Consider that I 
never ever ever want a control key to be present outside of an HSM in 
plaintext form.  Consider that some smart grid technologies are using 
TLS as the sole credential layer for controlling substantial amounts of 
power.

For TLS, I agree with you about performance, BUT, security is always a 
tradeoff with performance.  I may not always want to keep the session 
keys inside the HSM, but there are some times that prudence and good 
practice require this.

TLS should be designed so this is possible.  I believe it currently has 
a limitation that makes this goal difficult or impossible to achieve.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 23 Sep 2013 16:59:57 -0400

> output to differ wildly from the session keys, right?

Nope.  Even if you restrict this, you still have the problem in that the 
mac and encryption keys can be caused to "leak" into the part of the key 
stream used for IVs.

I think TLS should have been spec'd with a KDF  and a MAC as distinct 
functions rather than as simple composites of the PRF function.  Also 
using the master secret both as the secret to the KDF  (key expansion) 
and to the MAC (finish message integrity tag) has some issues as well 
(not cryptographically, but in getting a PKCS11 module to enforce use 
separation on the key).

The actual way we dealt with your comment above in PKCS11 v2.40 was to 
deprecate the PRF function from direct use, create a TLS KDF function 
(which could be used with any label and random and produced only keys - 
and the IVs) and create a TLS MAC function (which internally used only 
the two server and client finish message labels and didn't allow any 
others) which produces the public integrity tag.

Because of the IV leaking problem and because the AEAD ciphers still 
require the production of an IV through the TLS PRF, we created a second 
KDF function which *doesn't* produce IV material.  That at least allowed 
a specific key to be marked so that it wasn't subject to the key 
extraction through the IV attack.

Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 23 Sep 2013 18:00:58 -0500

> crypto stuff inside the HSM, but PKCS11 is designed to be useful for

That's not responsive though.  The fundamental question is: why should
anyone treat session keys as more valuable than the plaintext they are
used to protect?

I think there is an acceptable answer, namely: where the TLS (or
whatever) channel carries some data that is not trusted and where you
want privilege separation, and where you really just don't trust the
hardware furnishing the plaintext.  But you kinda have to say that
that's what you're after, and then consider other issues that come up as
a result.  For example, you might actually need a significant part of
your application to live in the HSM.

> Consider a specific field of use - 10s of Millions of smart grid
> capable electric power meters.  Consider that I have a back office
> system that talks to each and every one of them securely.  Consider
> that I'm worried about insider threats with respect to reading and
> controlling (e.g. remote disconnection of the meters) these devices.
> Consider that I never ever ever want a control key to be present
> outside of an HSM in plaintext form.  Consider that some smart grid
> technologies are using TLS as the sole credential layer for
> controlling substantial amounts of power.

I've considered these things.  See above.

> TLS should be designed so this is possible.  I believe it currently
> has a limitation that makes this goal difficult or impossible to
> achieve.

Or you could design a better HSM.  Why isn't that an answer?  PKCS#11
may not be the hammer that you're looking for.

Nico
--

---

From: Michael StJohns <[email-masked]>
Date: Tue, 24 Sep 2013 14:52:50 -0400

> anyone treat session keys as more valuable than the plaintext they are

1) Smuggling out the keys is easier than smuggling out the whole plaintext.
    a) Consider a web site running TLS, it extracts the session keys and 
posts them as a stego picture on the self same website (e.g. the photo 
of the company headquarters?).
2) We generally assume (for design purposes) that ciphertext may be 
captured without detection.
3) Attacker gathers picture and ciphertext together, extracts the keys 
and then extracts the plain text.

I generally assume that targets of value (e.g. banks, etc) have decent 
self-monitoring capabilities both at the network and system level.  That 
tends to suggest that less is more when it comes to exporting data from 
an attack.

> your application to live in the HSM.

Its not that I don't trust the "hardware" furnishing the plaintext, I 
don't trust any general purpose computer system to be immune from 
hacking attacks (and I'm of the firm belief that any one that does is 
delusional).  I would like to use HSM policy and security guarantees to 
reduce the impact of those attacks.  For TLS, this may ultimately come 
down to doing everything inside a HSM purpose built for TLS, but that's 
not the problem I'm trying to solve.

  I'm trying to get the policy controls of PKCS11 to do the correct 
things with derived keys (general problem, not just TLS).  The current 
TLS KDF math has holes in it that are inconsistent with this goal (e.g. 
any policy control absent doing all of the TLS negotiations inside the 
secure perimeter of an HSM [NOT a PKCS11 possibility] may be trivially 
defeated due to the way the key expansion step is defined).  I'd like to 
revise that math in a fairly straightforward way to close those holes 
and make it possible to apply appropriate policy controls.

Mike

---

From: "Juraj Somorovsky" <[email-masked]>
Date: 24 Sep 2013 23:21:47 +0200

> or has hacked the program using the HSM that has HSM credentials - the
You are right, the attacks do not apply to your scenario since they do
not recover the key.

...Sorry, my last one attack scenario :) ...assuming you are going to
use your KDF taking as input the key length. This would mean you would
generate the same key for AES-128 and RC4? (both have the key lengths of
16 bytes)

If the user would use AES-128, the attacker could force the HSM to
regenerate a new key for RC4 (in this case the same key as for AES-128
would be generated) and generate the RC4 keystream. Afterwards, he could
run one of the attacks against RC4 to learn the original RC4 key (and
thus also the AES key).

Does it make sense?
Thanks
Juraj

---

From: Michael StJohns <[email-masked]>
Date: Tue, 24 Sep 2013 23:08:49 -0400

> run one of the attacks against RC4 to learn the original RC4 key (and

Yes.  But preventing that requires a different/additional set of policy 
protections to be built into PKCS11.  I'm working on them in the PKCS11 
group.  The general idea is provide a way to specify mandatory policies 
(e.g. key types) for keys derived from other keys.  That problem is 
broader than just the KDFs used for TLS.

In some ways, the right answer to the above threat is to prevent the 
module from actually providing RC4 based keys and mechanisms.  Ah well....

Mike

---

From: "Juraj Somorovsky" <[email-masked]>
Date: 25 Sep 2013 09:33:35 +0200

> broader than just the KDFs used for TLS.
I understand that it is not that easy...

Are these policies going to restrict the key usage based on the KDF input?
If yes, what speaks against to use a derivation concept that takes as
input algorithm name the key is used for?

The key derivation based on the algorithm name (+ its key length) brings
the same security as yours. In addition, once your PKCS11 policy concept
is ready and implemented in HSMs, one could define new policies based on
the input of the KDF and restrict the usage of the derived keys.
> module from actually providing RC4 based keys and mechanisms.  Ah well....
Yes, it would be possible to define only a set of secure ciphers (and
thus remove RC4)...however, what happens if one of these secure ciphers
is broken and thus affects security of a different one, which
accidentally uses the same key length?

Best
Juraj