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

[Michael StJohns <[e-mail]>]

On 9/17/2013 12:00 PM, Salz, Rich wrote:
>> 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.
> 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.

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


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

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


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