[Opendnssec-develop] Creating keys
roy at nominet.org.uk
Mon Dec 1 09:48:14 UTC 2008
Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 11/28/2008
> Hi all,
> Just thought I'd contribute my 2 cents to the discussion.
> John Dickinson wrote:
> > 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
> >>>>> 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
> >>>> or so. So this 2 second pain per zone only happens once or twice
> >>>> month.
> >>> In this approach, are there any problems in ensuring that the keys
> >>> replicated to a backup HSM before they are used? Do you need any
> >> of
> >>> "master" password to export private keys from the HSM?
> >> I guess in a situation where the procedures require that keys need to
> >> backed up, it is up to the specific HSM implementation if such a
> >> is possible. Different HSMs use different methods. For instance, to
> >> fully FIPS 140-2 level 3 compliant, the HSM needs to be in complete
> >> not export" state, which guarantees that keys stored on an HSM can't
> >> exported. Another requirement is that "do not export" is
> > 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
> > 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
> >> What I think is fairly common is that a keystore (containing the
> >> private DNSKEY's) is an encrypted filesystem (the individual files
> >> 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 :)
> >> Decryption key can actually be synchronised between the various HSMs
> >> the same brand, as there is currently no standard defined way). There
> >> 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
> > 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.
> I agree as well, I know of quite a few HSM manufacturers that use the
> model described above (master key in the HSM, actual key material stored
> on disk with ways to restore the master key). A good example is nCipher.
> I'm pretty sure each manufacturer provides their own methods for backing
> up and restoring key material and also for duplicating security worlds
> across multiple distributed HSMs.
> In my opinion, functionality like key backup should be addressed in
> something like a manual (it's something operators should at least think
> about) but should not be solved by OpenDNSSEC.
Exactly. This is what I was referring to with "procedure".
> HSM manufacturers have
> much more experience in this which should be leveraged. Unfortunately
> they also have widely varying implementations which makes it hard to
> specify a single statement on how to go about backing up your keys :-(.
> > 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.
> It's a good point that operators may want to have some assurance about
> having a backup. The trouble is that it is going to be hard to ascertain
> this by querying the HSM. There is no 'this key is backed up' flag in
> PKCS #11. For these reasons I'm doubtful whether there should be a
> technical facility in OpenDNSSEC to enforce this.
There should not. I agree.
> What I could imagine
> is that an operator knows the creation date of a key (which should thus
> be stored somewhere) and knows the last time the HSM was backed up and
> can thus manually verify that a backup is available.
> >> 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
> > pre-create as many keys as needed, instead of as much as possible?" in
> > the previous email? 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?
> Although key generation is computationally expensive, this should not be
> overestimated. Especially for ZSKs where the key size is likely to be
> limited to something like 1024 bits, key generation is not that hard to
> do, especially for some special purpose hardware like a HSM. This only
> becomes an issue for KSKs which are rolled over far less often. IMHO it
> should be possible to work out the number of keys that should be kept in
> store according to some formula based on the number of zones (thus ZSKs
> and KSKs), the validity period of each key and a worst case scenario
> where all keys expire at the same time (which is unlikely) and then
> provide enough keys to roll over each key at least n-times where n is
> Then there could be a background daemon that chugs away at a lower
> priority generating key material as needed. On that point: this may
> require some form of load balancing interface to sit between the
> processes using the HSM and the HSM itself that decides which has a
> higher priority (key generation or signing) since I can imagine that
> there may be a few HSMs that can only do one thing at a time (especially
> if you include a really cheap HSM: a smart card in a reader).
> > Or should we allow the operator to select pre-generate or only
> > the minimum needed?
> Why not make this configurable? I think it should be possible to come up
> with a sensible default scenario with some formula as I proposed above
> but leave it up to more experienced administrator to decide on their own
> Another thing I'm pondering is the policy for KSKs. Have you already
> discussed having one KSK for all zones administered by an OpenDNSSEC box
> versus having a KSK for each zone? (If you have, forgive me for bringing
> it up).
> There are of course risks in having a single KSK (bigger impact
> if the key is compromised), but benefits as well (less key material
> floating around, easier to communicate to your parent). And then there
> are legal issues to consider (who is signing on behalf of whom,
> especially in the case where an ISP manages many zones for a lot of
> different entities); there is going to be a point where people start
> wondering who 'owns' the key material that is used to sign a zone and
> who is legally responsible for the statement of authenticity that is
> being given for the signed data.
> Finally, there is one other thing I'd like to bring up (and again, since
> I don't know the whole history of the discussions you've had before,
> please ignore it if it's already been discussed and decided on):
> It may make sense to store KSKs in an expensive device like a HSM but to
> store ZSKs in a soft token (because of limitations in the HSMs storage
> space, etc. etc.). I would like to point out that it would still make a
> lot of sense to generate the key material in the HSM because of the
> better quality key generator in the HSM (care taken to provide entropy,
> filtering of weak keys, etc.).
It does indeed make sense. We have pondered about it as well.
> These could then be exported in a
> standard format (have a look at PKCS #8) in wrapped form (e.g. wrapped
> using a symmetric algorithm) and be imported into the soft token where
> they are then unwrapped and stored for use.
> Hope I've helped a bit...
More information about the Opendnssec-develop