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

[Michael StJohns <[e-mail]>]

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



On 9/17/2013 1:05 PM, Nikos Mavrogiannopoulos wrote:
> On Tue, Sep 17, 2013 at 5:45 PM, Michael StJohns <[e-mail]> wrote:
>
>>> 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.
>> 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.
>
>> I want to protect inside of the HSM all of the following:
>> 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).
>
>> b) the pre-master key
>> c) the master key
>> 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
>
>