[Opendnssec-develop] Creating keys
Roland van Rijswijk
roland.vanrijswijk at surfnet.nl
Fri Nov 28 20:52:36 UTC 2008
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
>>>> 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
>>> 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
>>> "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.
> 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
>> 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. 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. 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 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
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
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.). 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...
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl
More information about the Opendnssec-develop