I would have thought SoftHSM by definition is probably vulnerable to the 
ability to export private keys and hence provide a backup mechanism ?

For "real" HSMs, as noted by David Vasek, by definition they are designed to be 
impossible to extract the private key (including going as far as tamper 
mechanisms that destroy the key in the event of physical attempts at 
extraction).

Backups in "real" HSMs is typcially done through a Key Wrapping mechanism (i.e. 
the key is exported in an encrypted format that can only be imported into 
another HSM from the same manufacturer).

The other option is you can create your key externally to the HSM and import it 
into multiple HSMs.  By definition this is less secure than generating the key 
inside the HSM.  Also I don't know if Knot support this sort of mechanism 
anyway.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Thursday, August 12th, 2021 at 12:27 AM, Luveh Keraph <[email protected]> 
wrote:

> Thanks for your reply. I am trying to address the case in which an HSM is 
> used. My guess is that, in such a case, the best that one can do using the 
> Knot framework itself is to back up the KASP (which contains public keys and 
> zone metadata, but no private keys) while relying on some external, 
> HSM-dependent mechanism to back up (and restore, as needed) the matching 
> private keys. Is this a correct assessment of things?
>
> If I understood you correctly, the backup command that you mention would work 
> (in 3.1) when using the default cryptographic provider alone - i.e. not with 
> SoftHSM, or any actual HSM. Right?
>
> On Wed, Aug 11, 2021 at 5:07 PM David Vasek <[email protected]> wrote:
>
> > Hello Luveh,
> >
> > this will backup the KASP DB and all private keys, unless they are
> >
> > stored in a HSM, and nothing else:
> >
> > knotc zone-backup +backupdir your_backup_directory +kaspdb +nozonefile
> >
> > +nojournal +notimers +nocatalog
> >
> > The details are described here:
> >
> > https://www.knot-dns.cz/docs/3.1/html/man_knotc.html
> >
> > This is new in 3.1, in previous versions, KASP DB and private keys
> >
> > couldn't be backed up separately without the other data. Please don't
> >
> > forget that the keys are stored in plain in the backup, i.e. in the same
> >
> > way as Knot stores them in its repository.
> >
> > Regards,
> >
> > David
> >
> > On 2021-08-11 21:39, Luveh Keraph wrote:
> >
> > > According to the documentation, one can back up the KASP using the
> >
> > > mdb_dump command. Now I understand things correctly, this will just
> >
> > > back up the public component of key pairs, plus some metadata for the
> >
> > > zones the public keys are associated with.
> >
> > >
> >
> > > Are there any provisions in Knot concerning the backing up of the
> >
> > > private components of key pairs, or is this something that must be
> >
> > > done separately and within the context of whatever cryptographic
> >
> > > provider is used?
-- 
https://lists.nic.cz/mailman/listinfo/knot-dns-users

Reply via email to