Thanks. You are right - once the keymgr operation is launched on a zone that is defined in knot.conf so that the SoftHSM policy applies to it, the keys involved are managed by the softhsm module. I have verified that such is the case for keymgr when using the generate command, and it stands to reason that the same would apply to other commands supported by keymgr. I haven't tried modifying the template section, as you suggest, but I am sure it works as expected. This all also explains and justifies why an option to specify a keystore for keymgr to work with, present in older versions, has been removed - it is not necessary.
Thanks for your help/
-----Original Message-----
From: "Daniel Salzman" [daniel.salzman(a)nic.cz]
Date: 05/03/2021 01:57 AM
To: "Full Name" <nuncestbibendum(a)excite.com>, knot-dns-users(a)lists.nic.cz
Subject: Re: [knot-dns-users] keymgr and keystores
If you don't specify any configuration or kaspdb explicitly, keymgr uses default Knot configuration (file or database).
So the problem probably is that you are generating keys for zones with default dnssec policy, which doesn't use the softhsm keystore.
Try setting:
template:
- id: default
...
dnssec-policy: RSAPol
On 5/2/21 3:46 PM, Full Name wrote:
> Thanks for your reply. Please see my comments below.
>
> -----Original Message-----
> From: "Daniel Salzman" [daniel.salzman(a)nic.cz]
> Date: 05/02/2021 04:51 AM
> To: knot-dns-users(a)lists.nic.cz
> Subject: Re: [knot-dns-users] keymgr and keystores
>
>
> On 4/30/21 7:47 PM, Full Name wrote:
>> I am evaluating version 2.9.5 of Knot, in particular in what concerns key management. This examination has resulted in the following issues/questions, which I would like to bring up to this forum for discussion/clarification:
>>
>> 1. I have been testing with the default Knot out-of-the-box setup, with the following knot.conf file:
>>
>> server:
>> listen: [10.0.0.1 ]
>>
>> log:
>> - target: syslog
>> any: info
>>
>> template:
>> - id: default
>> global-module: mod-stats
>>
>> mod-stats:
>> - id: default
>>
>> policy:
>> - id: RSAPol
>> algorithm: RSASHA256
>> ksk-size: 2048
>> zsk-size: 1024
>>
>> zone:
>> - domain: s0.mydomain.com
>> storage: /var/lib/MyZones/db
>> file: db.s0
>> dnssec-signing: on
>> dnssec-policy: RSAPol
>>
>> On launching Knot, this works as expected:
>>
>> - The necessary key pairs are generated and stored in /var/lib/knot/keys in the clear, with files data.db and lock.db created in /var/lib/knot.
>> - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db.
>>
>> 2. I next tried with SoftHSM for the low-level cryptographic support. The knot.conf file is the same as above, with the following changes:
>>
>> - I added a keystore section:
>>
>> keystore:
>> - id: SoftHSM
>> backend: pkcs11
>> config: "pkcs11:token=KNOT;pin-value=112233 libsofthsm2.so"
>>
>> - I modified the zone section to use SoftHSM:
>
> [DS] I expect you modified the policy section!
>
> Yes, I added a line
>
> keystore: SoftHSM
>
> I.e. the policy section reads
>
> policy:
> - id: RSAPol
> algorithm: RSASHA256
> ksk-size: 2048
> zsk-size: 1024
> keystore: SoftHSM
>
> I should have pointed this out explicitly - my mistake.
>
>
>>
>> zone:
>> - domain: s0.mydomain.com
>> storage: /var/lib/MyZones/db
>> file: db.s0
>> dnssec-signing: on
>> dnssec-policy: RSAPol
>> keystore: SoftHMS
>>
>
> Notice it should read keystore: SoftHSM. This is just a transcription error on my side - it is correct in the actual knot.conf file that I am using.
>
>> Before proceeding, I removed everything from /var/lib/knot. On launching knot again, this is what happens:
>>
>> - data.db and lock.db are created under /var/lib/knot, but no key pairs are created under /var/lib/knot/keys.
>> - Key pairs are created under /var/lib/softhsm/tokens/adf76cd6-5411-843e-6036-b8523580ef94.
>> - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db.
>>
>> This is all pretty much as expected, in that the signing keys have been generated in the space set aside by SoftHSM, and the signatures have been computed by the SoftHSM module.
>>
>> Now what I was wondering is whether keymgr can be used to manage keys in SofHSM? By default, it would seem to be the case that whenever I generate a key pair with keymgr, the key pair is stored under /var/lib/knot/keys, in the clear. Nothing seems to change under /var/lib/softhsm/tokens as a result of such a keymgr command. This is the case no matter what version of the knot.conf files described above I use.
>
> [DS] What are your parameters to keymgr? Don't you use default configuration (-d parameter)?
>
> No parameters. I just invoke it as
>
> keymgr mydomain.com. generate algorithm=RSASHA256
>
> Specifying -d /tmp will create db files under /tmp, and a keys directory under /tmp containing the actual keys in the clear. The essence of the issue remains the same though: the private keys are in the clear, and don't seem to have been generated by SoftHSM.
>
>
>> Here is my question:
>>
>> Is keymgr capable of managing keys in some separate device - SoftHSM, or a real, hardware HSM - or is it limited to keys generated by the default mechanism, with no HSM?
>
> [DS] Keymgr follows the zone's policy. So it uses the keystore which is configured for the zone.
>
> That's what I thought. Here's the thing though: in the knot.conf file above I changed the config entry in the keystore section, so that the wrong user PIN is supplied when attempting to access the services of the SoftHSM module. However, when using the keymgr command above, key pairs are are still generated without error, and stored outside the disk area allocated for SoftHSM. This makes me think that SoftHSM is not being used for this operation. This conclusion is reinforced by the fact that when I launch knot with that incorrect PIN in knot.conf, signatures are not computed and I get errors in syslog to that effect.
>
> The bottom line is that, although key pairs are definitely created by SoftHSM, and stored in the disk area for SoftHSM, when the automatic key generation process, as driven by knot.conf, kicks in, when using keymgr I have yet to be able to get SoftHSM to generate key pairs and store them in its disk area. What am I doing wrong?
>
>
>
>>
>> I notice that in previous versions of Knot, the keymgr utility supported options to use different keystores. Such options seem to be gone from keymgr as distributed with Knot 2.9.5. Can anybody elaborate on why they were removed, and whether some other utility is provided to achieve the same goals?
>>
>> Ultimately, what I am interested in is to have all of my keys so that they are available to the HSM alone, and I want to find out what tools does Knot provide - if any - to manage those keys, bearing in mind that they will have to be protected in permanent storage until such time that they are meant to be loaded into the HSM to be used. This is crucial, for most HSMs won't keep any keys across power cycles, and even when they do, they number that they can keep will in general be too small for my needs.
>>
>>
>>
>>
Thanks for your reply. Please see my comments below.
-----Original Message-----
From: "Daniel Salzman" [daniel.salzman(a)nic.cz]
Date: 05/02/2021 04:51 AM
To: knot-dns-users(a)lists.nic.cz
Subject: Re: [knot-dns-users] keymgr and keystores
On 4/30/21 7:47 PM, Full Name wrote:
> I am evaluating version 2.9.5 of Knot, in particular in what concerns key management. This examination has resulted in the following issues/questions, which I would like to bring up to this forum for discussion/clarification:
>
> 1. I have been testing with the default Knot out-of-the-box setup, with the following knot.conf file:
>
> server:
> listen: [10.0.0.1 ]
>
> log:
> - target: syslog
> any: info
>
> template:
> - id: default
> global-module: mod-stats
>
> mod-stats:
> - id: default
>
> policy:
> - id: RSAPol
> algorithm: RSASHA256
> ksk-size: 2048
> zsk-size: 1024
>
> zone:
> - domain: s0.mydomain.com
> storage: /var/lib/MyZones/db
> file: db.s0
> dnssec-signing: on
> dnssec-policy: RSAPol
>
> On launching Knot, this works as expected:
>
> - The necessary key pairs are generated and stored in /var/lib/knot/keys in the clear, with files data.db and lock.db created in /var/lib/knot.
> - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db.
>
> 2. I next tried with SoftHSM for the low-level cryptographic support. The knot.conf file is the same as above, with the following changes:
>
> - I added a keystore section:
>
> keystore:
> - id: SoftHSM
> backend: pkcs11
> config: "pkcs11:token=KNOT;pin-value=112233 libsofthsm2.so"
>
> - I modified the zone section to use SoftHSM:
[DS] I expect you modified the policy section!
Yes, I added a line
keystore: SoftHSM
I.e. the policy section reads
policy:
- id: RSAPol
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
keystore: SoftHSM
I should have pointed this out explicitly - my mistake.
>
> zone:
> - domain: s0.mydomain.com
> storage: /var/lib/MyZones/db
> file: db.s0
> dnssec-signing: on
> dnssec-policy: RSAPol
> keystore: SoftHMS
>
Notice it should read keystore: SoftHSM. This is just a transcription error on my side - it is correct in the actual knot.conf file that I am using.
> Before proceeding, I removed everything from /var/lib/knot. On launching knot again, this is what happens:
>
> - data.db and lock.db are created under /var/lib/knot, but no key pairs are created under /var/lib/knot/keys.
> - Key pairs are created under /var/lib/softhsm/tokens/adf76cd6-5411-843e-6036-b8523580ef94.
> - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db.
>
> This is all pretty much as expected, in that the signing keys have been generated in the space set aside by SoftHSM, and the signatures have been computed by the SoftHSM module.
>
> Now what I was wondering is whether keymgr can be used to manage keys in SofHSM? By default, it would seem to be the case that whenever I generate a key pair with keymgr, the key pair is stored under /var/lib/knot/keys, in the clear. Nothing seems to change under /var/lib/softhsm/tokens as a result of such a keymgr command. This is the case no matter what version of the knot.conf files described above I use.
[DS] What are your parameters to keymgr? Don't you use default configuration (-d parameter)?
No parameters. I just invoke it as
keymgr mydomain.com. generate algorithm=RSASHA256
Specifying -d /tmp will create db files under /tmp, and a keys directory under /tmp containing the actual keys in the clear. The essence of the issue remains the same though: the private keys are in the clear, and don't seem to have been generated by SoftHSM.
> Here is my question:
>
> Is keymgr capable of managing keys in some separate device - SoftHSM, or a real, hardware HSM - or is it limited to keys generated by the default mechanism, with no HSM?
[DS] Keymgr follows the zone's policy. So it uses the keystore which is configured for the zone.
That's what I thought. Here's the thing though: in the knot.conf file above I changed the config entry in the keystore section, so that the wrong user PIN is supplied when attempting to access the services of the SoftHSM module. However, when using the keymgr command above, key pairs are are still generated without error, and stored outside the disk area allocated for SoftHSM. This makes me think that SoftHSM is not being used for this operation. This conclusion is reinforced by the fact that when I launch knot with that incorrect PIN in knot.conf, signatures are not computed and I get errors in syslog to that effect.
The bottom line is that, although key pairs are definitely created by SoftHSM, and stored in the disk area for SoftHSM, when the automatic key generation process, as driven by knot.conf, kicks in, when using keymgr I have yet to be able to get SoftHSM to generate key pairs and store them in its disk area. What am I doing wrong?
>
> I notice that in previous versions of Knot, the keymgr utility supported options to use different keystores. Such options seem to be gone from keymgr as distributed with Knot 2.9.5. Can anybody elaborate on why they were removed, and whether some other utility is provided to achieve the same goals?
>
> Ultimately, what I am interested in is to have all of my keys so that they are available to the HSM alone, and I want to find out what tools does Knot provide - if any - to manage those keys, bearing in mind that they will have to be protected in permanent storage until such time that they are meant to be loaded into the HSM to be used. This is crucial, for most HSMs won't keep any keys across power cycles, and even when they do, they number that they can keep will in general be too small for my needs.
>
>
>
>
--
https://lists.nic.cz/mailman/listinfo/knot-dns-user
I am evaluating version 2.9.5 of Knot, in particular in what concerns key management. This examination has resulted in the following issues/questions, which I would like to bring up to this forum for discussion/clarification:
1. I have been testing with the default Knot out-of-the-box setup, with the following knot.conf file:
server:
listen: [10.0.0.1 ]
log:
- target: syslog
any: info
template:
- id: default
global-module: mod-stats
mod-stats:
- id: default
policy:
- id: RSAPol
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
zone:
- domain: s0.mydomain.com
storage: /var/lib/MyZones/db
file: db.s0
dnssec-signing: on
dnssec-policy: RSAPol
On launching Knot, this works as expected:
- The necessary key pairs are generated and stored in /var/lib/knot/keys in the clear, with files data.db and lock.db created in /var/lib/knot.
- The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db.
2. I next tried with SoftHSM for the low-level cryptographic support. The knot.conf file is the same as above, with the following changes:
- I added a keystore section:
keystore:
- id: SoftHSM
backend: pkcs11
config: "pkcs11:token=KNOT;pin-value=112233 libsofthsm2.so"
- I modified the zone section to use SoftHSM:
zone:
- domain: s0.mydomain.com
storage: /var/lib/MyZones/db
file: db.s0
dnssec-signing: on
dnssec-policy: RSAPol
keystore: SoftHMS
Before proceeding, I removed everything from /var/lib/knot. On launching knot again, this is what happens:
- data.db and lock.db are created under /var/lib/knot, but no key pairs are created under /var/lib/knot/keys.
- Key pairs are created under /var/lib/softhsm/tokens/adf76cd6-5411-843e-6036-b8523580ef94.
- The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db.
This is all pretty much as expected, in that the signing keys have been generated in the space set aside by SoftHSM, and the signatures have been computed by the SoftHSM module.
Now what I was wondering is whether keymgr can be used to manage keys in SofHSM? By default, it would seem to be the case that whenever I generate a key pair with keymgr, the key pair is stored under /var/lib/knot/keys, in the clear. Nothing seems to change under /var/lib/softhsm/tokens as a result of such a keymgr command. This is the case no matter what version of the knot.conf files described above I use.
Here is my question:
Is keymgr capable of managing keys in some separate device - SoftHSM, or a real, hardware HSM - or is it limited to keys generated by the default mechanism, with no HSM?
I notice that in previous versions of Knot, the keymgr utility supported options to use different keystores. Such options seem to be gone from keymgr as distributed with Knot 2.9.5. Can anybody elaborate on why they were removed, and whether some other utility is provided to achieve the same goals?
Ultimately, what I am interested in is to have all of my keys so that they are available to the HSM alone, and I want to find out what tools does Knot provide - if any - to manage those keys, bearing in mind that they will have to be protected in permanent storage until such time that they are meant to be loaded into the HSM to be used. This is crucial, for most HSMs won't keep any keys across power cycles, and even when they do, they number that they can keep will in general be too small for my needs.
