[Opendnssec-develop] Creating keys

[Roy Arends]

John Dickinson <jad at jadickinson.co.uk> wrote on 11/28/2008 07:03:27 PM:

> On 28 Nov 2008, at 17:31, Roy Arends wrote:
> 
> > Stephen Morris wrote on 11/28/2008 05:47:32 PM:
> >
> >> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
> >>
> >>>
> >>> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
> >>>
> >>>>
> >>>> So I guess if you have a large zone like co.uk then a couple of
> >>>> seconds in the 6 odd minutes that it would take to sign from 
> >>>> scratch
> >
> >>>> is nothing. However, if you have 1000's of small zones or you are
> >>>> dynamically updating every minute then it could make a big
> > difference.
> >>>
> >>> But even then... the key-rollover would take place only once per 
> >>> month
> >
> >>> or so. So this 2 second pain per zone only happens once or twice per
> >>> month.
> >>
> >> In this approach, are there any problems in ensuring that the keys 
> >> are
> >> replicated to a backup HSM before they are used?  Do you need any 
> >> type
> > of
> >> "master" password to export private keys from the HSM?
> >
> > I guess in a situation where the procedures require that keys need 
> > to be
> > backed up, it is up to the specific HSM implementation if such a 
> > scenario
> > is possible. Different HSMs use different methods. For instance, to be
> > fully FIPS 140-2 level 3 compliant, the HSM needs to be in complete 
> > "do
> > not export" state, which guarantees that keys stored on an HSM can't 
> > be
> > exported. Another requirement is that "do not export" is irreversible.
> 
> This means that to allow for backup you might want to have the key 
> generation on a separate machine - I did once imagine a system where 
> an offline server generated keys in a "master" HSM. The HSM backup 
> system was then used to copy those keys to HSMs to be attached to the 
> signing server. This would allow the HSMs attached to the signer to be 
> locked (backups not possible). (But then again, can you have one HSM 
> that is the duplicate of another where one is in FIPS 140-2 level 3 
> and one not??)
> 
> >
> > What I think is fairly common is that a keystore (containing the 
> > actual
> > private DNSKEY's) is an encrypted filesystem (the individual files are
> > encrypted, not the directory structure) on a regular disk, while the
> > Keystore Decryption Key (or Master Key, or SuperKey or RootToken, all
> > depending on which vendor you talk to) resides physically in the 
> > HSM. This
> 
> We have had this conversation elsewhere: But WHY? Just use an HSM or 
> soft token for all the keys :)

I think we're not aligned here :-)

1) Backup and Fallback of private DNSKEYs is a requirement for us.
2) private DNSKEYs should never leave an HSM unencrypted.
3) the encryption key must never (EVER!) leave an HSM while in production.

In our design at Nominet, we've satisfied all three requirements.

Surely we could use an HSM where the private DNSKEYs reside on a HSM (ie 
in hardware), but that would be overkill.

> > Decryption key can actually be synchronised between the various HSMs 
> > (of
> > the same brand, as there is currently no standard defined way). 
> > There are
> > different methods to do this. Once the decrytion key is equal on all 
> > HSMs,
> > keystores can be read by all involved HSMs, while the same encrypted
> > keystores (filesystems) can be backed-up, replicated, etc.
> >
> >
> > However, since the methods on key-retrieval, backup, recovery is so
> > incredibly vendor specific, I think that is out of scope. We should 
> > just
> 
> I agree, key backup is outside the scope of OpenDNSSEC and should be 
> done according to the mechanism designed by the HSM manufacturer. 
> Ability to do this would be a consideration when selecting an HSM or 
> soft token.
> 
> However, I do agree with Stephen, an operator might want a chance to 
> know that they had backups before deciding to use a key. Given that 
> backup is likely to be a manual step maybe pre-creation is needed, at 
> least for some people. Maybe we need a backup interval between 
> generation and publication.

Ack.

> >
> > allow the system to be able to pre-generate keys, in order to allow
> > redundant keystores.
> 
> I am a bit confused - is that pre-generate the same as the "So, why 
> not pre-create as many keys as needed, instead of as much as 
> possible?" in the previous email?

Yes.

> BTW - how many is "as many keys as 
> needed"? Enough for the immediate key rollover that the enforcer is 
> trying to do or enough for all the key rollovers planned in the next x 
> minutes?

Enough for the next planned backup procedure. If the backup procedure is 
to be done every six month (say), than you need to have keys that will 
take you past those six months, plus some slack.

> Or should we allow the operator to select pre-generate or only 
> generate the minimum needed?

I don't think these two are comparable. Can you elaborate?

Roy