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

[Luis Diego Espinoza S.]

Hi Shane, I agree with the levels of HSM according with the level on the DNS tree.
But the chain breaks at it's weakest link.
DNSSEC is a chain, and a TLD manager probably don't want to be the weakest link.
Strength does not involve expensive technology, but rather involves doing things right.

If is possible to provide some model of low cost HSM to all levels of the chain, why not to implemented to provide strength to the chain.
A cheap smart card (FIPS aware) could be enough to many lower levels of the DNS tree, the key to deploy it massively could be simplified and automate procedures.
If is possible to fit all the key generation, storage and signing process within a usb device, could be an interesting solution.

Luis,

On Oct 16, 2012, at 10:05 AM, Shane Kerr <shane at isc.org> wrote:

> 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
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

-- 
Luis D. Espinoza
Jefe TI - NIC Costa Rica



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20121016/04871a5f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firmasNicLDE-ES.jpg
Type: image/jpeg
Size: 60615 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20121016/04871a5f/attachment.jpg>