Re: [TLS] Private Key Security [Was Re: DHE key derivation]

[[e-mail] (Martin Rex)]

Michael StJohns wrote:
> 
> With respect to whether a key will be stolen or not, you really need 
> only compare the value of the data being protected by that key to the 
> cost to an attacker to retrieve that key (and the data).  If the value 
> of the data is >> or >>> than the cost to attack, chances are someone 
> has done so.

If someone if after the data, then it will go after the data,
not after the keys.  

> 
> HSMs increase the cost of attack and that's a good reason to use them, 

For the vast majority of useful attacks it is entirely irrelevant
whether your keys are in a HSM or not.

First of all, HSMs will always and significantly increase the cost
of setting up and running a TLS peer by a significant amount, and
in particular, for a server, when performance is an issue.
HSMs also do not scale with multi-core CPUs; instead, you got to pay
factors more for a faster HSM.

With existing TLS, your HSM would have to implement current TLS versions
in its entirety, which most of the current HSMs probably do not.  And
interop with current TLS is likely going to be necessary for another
two decades (SSLv3 is 18 years old and we only recently managed to put
SSLv2 to rest (on paper, that is)).

Even when you have your keys in a HSM, this will not prevent that a
subverted server could look at incoming connections and perform
TLS-protected communication with a purely software-based TLS protocol
and software-based keys with the attacker.  In many situations,
the value is primarily in the data of the server, i.e. access to
data the server is processing or has on persistent storage.

Listening into communication and determining which client does what
might be interesting for collection by spooks (NSA, GCQH, etc.)
for performing data mining on the bigger picture, but is pretty
irrelevant for the average malfeasant attacker.

Being able to impersonate users might be *MUCH* more interesting
to attackers than being able to listen into boring communication,
e.g. obtaining credentials for users by various means, such as
pulling them from the data persistence, modifying access control lists,
capturing credentials of a disclosing authentication within the server
(rather than trying to sniff and decrypt them from the network),
setting/overwriting user credentials, creating new admin users,
adding X.509 trust anchors for acceptable TLS client certs and
probably lots of other things that are more powerful and more
devastating than obtaining the server's boring private key.


-Martin