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

[Nico Williams <[e-mail]>]

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 :^)

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

Nico
--