Robert, On Tuesday, 2012-10-16 14:52:09 +0200, Robert Kisteleki <[email protected]> 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 _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
