[pki-devel][PATCH]0061-Enhance-tkstool-for-capabilities-and-security.patch
Enhance tkstool for capabilities and security This simple ticket is to fix tkstool to allow it to create the master key with the proper flags to make the key data private such that it can't be easily viewed when using tools to print out sym keys on the token. Fix tested on the "internal" token by trying the various tkstool cmds to make sure having the key private does not cause issues. Also tried a simple key changeover operation with tpsclient to make sure that symkey can still do what it needs to do witht the master key. Further testing with a full hsm will be required. The goal was the create the key with the same flags that are used with the previous "PK11_GenKeyOnToken" (name approx) is used. This version had no flags and created a default set. This fix uses the version With flags and does what the old one did, but made sure the key is private and sensitive. Master key can be tested by using the tool: /usr/lib64/nss/unsupported-tools/symkeyutil -d ./ -L
I think I will be more conservative and give conditional ACK to this patch pending on tests on servers running on both LunaSA and nethsm. Although the code in the patch might very well work for both, those two HSM's are known to require different sets of pk11AtrFlags and often one set would work for one but not the other. thanks, Christina On 01/15/2016 04:24 PM, John Magne wrote:
Enhance tkstool for capabilities and security
This simple ticket is to fix tkstool to allow it to create the master key with the proper flags to make the key data private such that it can't be easily viewed when using tools to print out sym keys on the token.
Fix tested on the "internal" token by trying the various tkstool cmds to make sure having the key private does not cause issues. Also tried a simple key changeover operation with tpsclient to make sure that symkey can still do what it needs to do witht the master key.
Further testing with a full hsm will be required. The goal was the create the key with the same flags that are used with the previous "PK11_GenKeyOnToken" (name approx) is used. This version had no flags and created a default set. This fix uses the version With flags and does what the old one did, but made sure the key is private and sensitive.
Master key can be tested by using the tool:
/usr/lib64/nss/unsupported-tools/symkeyutil -d ./ -L
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Ticket #1641 Enhance tkstool for capabilities and security The key is now generated with the flags needed to keep the data from being displayed with simple tools such as symkeyutil. As per cfu's instructions, I was able to test this with the nethsm only. I also was able to make the key des3 and everything works fine with the master key. This will help all the warnings we get about insecure des2 keys. If there is a problem with luna, we can file another ticket. Also there could be a built in tool for luna to generate keys such as is present on hsm. Pushed to master. ----- Original Message ----- From: "Christina Fu" <cfu@redhat.com> To: pki-devel@redhat.com Sent: Wednesday, January 27, 2016 10:24:26 AM Subject: Re: [Pki-devel] [pki-devel][PATCH]0061-Enhance-tkstool-for-capabilities-and-security.patch I think I will be more conservative and give conditional ACK to this patch pending on tests on servers running on both LunaSA and nethsm. Although the code in the patch might very well work for both, those two HSM's are known to require different sets of pk11AtrFlags and often one set would work for one but not the other. thanks, Christina On 01/15/2016 04:24 PM, John Magne wrote: Enhance tkstool for capabilities and security This simple ticket is to fix tkstool to allow it to create the master key with the proper flags to make the key data private such that it can't be easily viewed when using tools to print out sym keys on the token. Fix tested on the "internal" token by trying the various tkstool cmds to make sure having the key private does not cause issues. Also tried a simple key changeover operation with tpsclient to make sure that symkey can still do what it needs to do witht the master key. Further testing with a full hsm will be required. The goal was the create the key with the same flags that are used with the previous "PK11_GenKeyOnToken" (name approx) is used. This version had no flags and created a default set. This fix uses the version With flags and does what the old one did, but made sure the key is private and sensitive. Master key can be tested by using the tool: /usr/lib64/nss/unsupported-tools/symkeyutil -d ./ -L _______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
participants (2)
-
Christina Fu -
John Magne