[dns-operations] HSM - snake oil or... something that is not snake oil (was Anyone still using a Sun/Oracle SCA6000 with OpenSSL?)

[Shane Kerr]

Robert,

On Tuesday, 2012-10-16 14:52:09 +0200, 
Robert Kisteleki <robert at ripe.net> wrote:
> Hi,
> 
> (Blowing the dust off of an old hat of mine...)
> 
> 
> On 2012.10.16. 12:34, Shane Kerr wrote:
> >> i keep wondering about the use of hsms in dnssec and rpki
> >> signing.  i suspect that the threat model is not well thought out.
> > 
> > The only attack that I could see an HSM protecting against is an
> > insider stealing the keys without being detected, like Alexander
> > mentioned. The idea is that a motivated attacker could in principle
> > make a copy of the keys - but not if they are stored in an HSM.
> 
> The attacker's point is not to *steal* the key, but to *sign*
> something with it; most likely a hash or such. If I can inject a
> hash-to-be-signed into the to-be-signed queue, then I won, I don't
> really care about the key itself. Sure, if I actually have a copy of
> the key, then it's way easier :-) but as you say, HSMs can prevent
> that.

You describe a useful but less potent attack.

With DNS, if you publish a bogus zone file, it is straightforward for
the "real" owner of the zone data to detect the bad data, and then you
can do an emergency roll-over, publish a new zone, and Bob's your uncle.

However, a stolen key can be used to send bad data to a resolver
without the operators of the authoritative server ever knowing about
it, Kaminsky-style. They could do this presumably until you rolled your
key, which is probably several years away.

(A sufficiently sophisticated attack could in theory produce a signed
zone with bogus data, and then a signed zone without bogus data, and
somehow insure that only the "good" zone gets published, but that seems
unrealistic.)

> > Also note that there are possible weaknesses with even an HSM,
> > depending on how backups are made. These can be worked around with
> > procedure and extra layers of security (cameras, access logs, ...).
> 
> It's possible to come up with bad escrow mechanisms, which leave the
> key vulnerable. That's just bad engineering, it's got nothing to do
> with HSMs. However, a properly designed procedure with enough support
> from the HSM will defend against this.

I think this actually brings up what I consider a major problem with
the recommendation to use an HSM in general: unless you are going to
revise all of your entire security processes, it's a waste. And unless
there was something wrong with your security processes, then why should
you be forced to change them just because you are now using DNSSEC?

My take on HSM:

  For ICANN: of course (and all the theater too!)
  
  For TLD/banks/governments: if you feel that you must

  For everyone else: don't bother

--
Shane