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

[Michael StJohns <[e-mail]>]

On 9/23/2013 4:00 PM, Nico Williams wrote:
> On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
> <[e-mail]> wrote:
>> On 9/17/2013 8:49 AM, Martin Rex wrote:
>>> 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.
>>
>> 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.
> 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.

>
>> I want to protect inside of the HSM all of the following:
>>
>> a) the private keys related to the server or client identity
> Sure.
>
>> 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.
> 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.

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

>
> Nico
> --
>
>