[Opendnssec-develop] Creating keys

[Roy Arends]

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 11/28/2008 
09:52:36 PM:

> 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 
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 :)
> > 
> >>
> >> 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.
> 
> 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.

Sure.

> >> 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? 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 
> configurable.
> 
> 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 
generate 
> > 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 

> policy.
> 
> 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...


Definitely,

Thanks Roland

Roy