11 Srp
2021
11 Srp
'21
21:39
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?
12 Srp
12 Srp
1:07
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?
1:27
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 <david.vasek(a)nic.cz> 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?
9:49
Yes, backup of the keys in HSM must be done by the the HSM and its
tools. It's the purpose of HSM's not to make private keys available to
applications.
Regards,
David
On 2021-08-12 01:27, Luveh Keraph 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 <david.vasek(a)nic.cz>
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?
14:44
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 <1.41421(a)gmail.com> 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 <david.vasek(a)nic.cz> 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?
17:05
Thanks for your replies, guys. It would seem then that when an HSM is
involved one must resort to mechanisms external to Knot to carry out
complete key backups. Which is fine, and expected, for basic security
reasons.
On Thu, Aug 12, 2021 at 6:44 AM Laura Smith <
n5d9xq3ti233xiyif2vp(a)protonmail.ch> wrote:
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 <
1.41421(a)gmail.com> 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 <david.vasek(a)nic.cz> 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?
1000
days inactive
1001
days old
5 comments
3 participants
participants (3)
-
David Vasek -
Laura Smith -
Luveh Keraph