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

[Michael StJohns <[e-mail]>]

On 9/23/2013 7:00 PM, Nico Williams wrote:
> On Mon, Sep 23, 2013 at 04:47:44PM -0400, Michael StJohns wrote:
>> On 9/23/2013 4:00 PM, Nico Williams wrote:
>>> On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
>>> <[e-mail]> wrote:
>>>
>>> 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 :^)
>> 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.
> 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?

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.

>
> 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.

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


>
>> 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