[Opendnssec-develop] Creating keys

[Roland van Rijswijk]

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

Cheers,

Roland.

-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl