From pspacek at redhat.com Thu Jul 17 10:38:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 17 Jul 2014 12:38:01 +0200 Subject: [Softhsm-develop] CKA_SENSITIVE and CKA_EXTRACTABLE handling Message-ID: <53C7A789.5070908@redhat.com> Hello list, I'm working on CKM_RSA_PKCS support for C_WrapKey (as I promised earlier). I have found out that SoftHSM allows me to *wrap* key if and only if this key has CKA_SENSITIVE=FALSE and CKA_EXTRACTABLE=TRUE. Unfortunately, this combination of flags also means that I'm able to get plaintext values from the token (using C_GetAttributeValue for CKA_VALUE or so). I think that SoftHSM should allow key wrapping in case where CKA_EXTRACTABLE=TRUE and CKA_SENSITIVE=TRUE. In that case C_GetAttributeValue with CKA_VALUE should fail but C_WrapKey should work. IMHO this is allowed behavior, see [1] page 83: If the CKA_SENSITIVE attribute is CK_TRUE, or if the CKA_EXTRACTABLE attribute is CK_FALSE, then certain attributes of the secret key cannot be revealed in plaintext outside the token. Which attributes these are is specified for each type of secret key in the attribute table in the section describing that type of key. This text talks only about plain text values, not about key wrapping. I think that this is in line with CKA_EXTRACTABLE and CKA_SENSITIVE definitions: CKA_EXTRACTABLE in [1] on page 79: CK_TRUE if key is extractable and can be wrapped. CKA_SENSITIVE in [1] on page 79: CK_TRUE if key is sensitive My personal translation to natural language is: CKA_EXTRACTABLE defines if user is allowed to get "any" values (plaintext or wrapped). CKA_SENSITIVE defines if user is allowed to get plaintext values. Do you agree? Would you accept patch which will modify attribute handling to follow logic explained above? Thank you for your time! [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf -- Petr Spacek @ Red Hat From pspacek at redhat.com Thu Jul 17 17:19:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 17 Jul 2014 19:19:09 +0200 Subject: [Softhsm-develop] support for CKM_RSA_PKCS key un/wrapping Message-ID: <53C8058D.7090306@redhat.com> Hello, I have opened pull request #83 which adds support for CKM_RSA_PKCS key un/wrapping. https://github.com/opendnssec/SoftHSMv2/pull/83 Let's discuss about this code and your requirements :-) Current code uses AsymmetricAlgorithm->encrypt() and decrypt() directly. I wonder if it is really necessary to introduce new AsymmetricAlgorithm interface for wrap() and unwrap(). To me it seems that calling encrypt() and decrypt() with correct AsymMech could be enough... Other alternative would be to add wrap() and unwrap() interface and simply relay calls wrap()->encrypt() etc. It would allow us to filter out some inappropriate mechanism from wrap() call but that is all. (E.g. refusing to do key wrapping if mechanism is CKM_SHA1_RSA_PKCS or something like that.) Is it worth doing so? Thank you for your opinions. I'm looking forward to hear results of code review. Have a nice day! -- Petr Spacek @ Red Hat From Roland.vanRijswijk at surfnet.nl Fri Jul 18 08:18:37 2014 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Fri, 18 Jul 2014 10:18:37 +0200 Subject: [Softhsm-develop] CKA_SENSITIVE and CKA_EXTRACTABLE handling In-Reply-To: <53C7A789.5070908@redhat.com> References: <53C7A789.5070908@redhat.com> Message-ID: <53C8D85D.7080206@surfnet.nl> Hi Petr, Petr Spacek wrote: > I'm working on CKM_RSA_PKCS support for C_WrapKey (as I promised earlier). > > I have found out that SoftHSM allows me to *wrap* key if and only if > this key has CKA_SENSITIVE=FALSE and CKA_EXTRACTABLE=TRUE. > > Unfortunately, this combination of flags also means that I'm able to get > plaintext values from the token (using C_GetAttributeValue for CKA_VALUE > or so). > > I think that SoftHSM should allow key wrapping in case where > CKA_EXTRACTABLE=TRUE and CKA_SENSITIVE=TRUE. In that case > C_GetAttributeValue with CKA_VALUE should fail but C_WrapKey should work. > > IMHO this is allowed behavior, see [1] page 83: > Do you agree? Would you accept patch which will modify attribute > handling to follow logic explained above? Yes, I agree, that is a correct interpretation of the PKCS #11 specification, I'm a bit surprised that we didn't implement it that way. We will certainly accept a patch that fixes this, thanks! Cheers, Roland -- -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4412 bytes Desc: S/MIME Cryptographic Signature URL: From Roland.vanRijswijk at surfnet.nl Fri Jul 18 08:29:10 2014 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Fri, 18 Jul 2014 10:29:10 +0200 Subject: [Softhsm-develop] support for CKM_RSA_PKCS key un/wrapping In-Reply-To: <53C8058D.7090306@redhat.com> References: <53C8058D.7090306@redhat.com> Message-ID: <53C8DAD6.3030305@surfnet.nl> Hi Petr, Petr Spacek wrote: > I have opened pull request #83 which adds support for CKM_RSA_PKCS key > un/wrapping. > https://github.com/opendnssec/SoftHSMv2/pull/83 > > Let's discuss about this code and your requirements :-) > > Current code uses AsymmetricAlgorithm->encrypt() and decrypt() directly. > > I wonder if it is really necessary to introduce new AsymmetricAlgorithm > interface for wrap() and unwrap(). To me it seems that calling encrypt() > and decrypt() with correct AsymMech could be enough... > > Other alternative would be to add wrap() and unwrap() interface and > simply relay calls wrap()->encrypt() etc. It would allow us to filter > out some inappropriate mechanism from wrap() call but that is all. (E.g. > refusing to do key wrapping if mechanism is CKM_SHA1_RSA_PKCS or > something like that.) > > Is it worth doing so? Thank you for your opinions. I think it is worthwhile having a separate interface. Not just because it looks cleaner, also because you can manage permissions on keys that allow or disallow certain operations (such as wrapping/unwrapping). I also think it is worthwhile having a constructor on AsymmetricKey objects that allow a PKCS #8 blob as input, such that a call to unwrap using a SymmetricKey can invoke such a constructor. Conversely, there should be a function on AsymmetricKey objects that output a suitable PKCS #8 blob for an invocation of wrap using a SymmetricKey object. Cheers, Roland -- -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4412 bytes Desc: S/MIME Cryptographic Signature URL: From pspacek at redhat.com Fri Jul 18 17:00:59 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 18 Jul 2014 19:00:59 +0200 Subject: [Softhsm-develop] CKA_SENSITIVE and CKA_EXTRACTABLE handling In-Reply-To: <53C8D85D.7080206@surfnet.nl> References: <53C7A789.5070908@redhat.com> <53C8D85D.7080206@surfnet.nl> Message-ID: <53C952CB.7030500@redhat.com> On 18.7.2014 10:18, Roland van Rijswijk - Deij wrote: > Petr Spacek wrote: >> I think that SoftHSM should allow key wrapping in case where >> CKA_EXTRACTABLE=TRUE and CKA_SENSITIVE=TRUE. In that case >> C_GetAttributeValue with CKA_VALUE should fail but C_WrapKey should work. >> >> IMHO this is allowed behavior, see [1] page 83: >> Do you agree? Would you accept patch which will modify attribute >> handling to follow logic explained above? > > Yes, I agree, that is a correct interpretation of the PKCS #11 > specification, I'm a bit surprised that we didn't implement it that way. > We will certainly accept a patch that fixes this, thanks! Here it is: https://github.com/opendnssec/SoftHSMv2/pull/84 I have extended test suite a little bit to make sure that CKA_SENSITIVE works as described above. Enjoy. -- Petr Spacek @ Red Hat From pspacek at redhat.com Fri Jul 18 17:23:04 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 18 Jul 2014 19:23:04 +0200 Subject: [Softhsm-develop] support for CKM_RSA_PKCS key un/wrapping In-Reply-To: <53C8DAD6.3030305@surfnet.nl> References: <53C8058D.7090306@redhat.com> <53C8DAD6.3030305@surfnet.nl> Message-ID: <53C957F8.8060205@redhat.com> On 18.7.2014 10:29, Roland van Rijswijk - Deij wrote: > Hi Petr, > > Petr Spacek wrote: >> I have opened pull request #83 which adds support for CKM_RSA_PKCS key >> un/wrapping. >> https://github.com/opendnssec/SoftHSMv2/pull/83 >> >> Let's discuss about this code and your requirements :-) >> >> Current code uses AsymmetricAlgorithm->encrypt() and decrypt() directly. >> >> I wonder if it is really necessary to introduce new AsymmetricAlgorithm >> interface for wrap() and unwrap(). To me it seems that calling encrypt() >> and decrypt() with correct AsymMech could be enough... >> >> Other alternative would be to add wrap() and unwrap() interface and >> simply relay calls wrap()->encrypt() etc. It would allow us to filter >> out some inappropriate mechanism from wrap() call but that is all. (E.g. >> refusing to do key wrapping if mechanism is CKM_SHA1_RSA_PKCS or >> something like that.) >> >> Is it worth doing so? Thank you for your opinions. > > I think it is worthwhile having a separate interface. Not just because > it looks cleaner, also because you can manage permissions on keys that > allow or disallow certain operations (such as wrapping/unwrapping). I Could you be more specific, please? What do you mean with 'permissions'? Do you mean PKCS#11 tables which say e.g. that CKM_SHA1_RSA_PKCS cannot be used for key wrapping? Or something else? It seems to me that crypto layer (AsymmetricAlgorithm and others) is deep below P11Object so those objects doesn't have any knowledge of allowed key usages. I mean: In cases where PKCS#11 *standard* allows to use given mechanism for encryption and wrapping but P11Object says something else (e.g. allows only key wrapping) there is no way for AsymmetricAlgorithm to know about this limitation. Please correct me if I'm wrong. I can certainly write wrap() as a wrapper around encrypt() which will implement PKCS#11 'tables'. I imagine that it would be fairly simple: bool wrap(..., padding) { switch (padding) { case RSA_PKCS: return encrypt(..., padding); default: // includes CKM_SHA1_RSA_PKCS return false; } } Adding knowledge about allowed key usage to AsymmetricAlgorithm would be more invasive change. > also think it is worthwhile having a constructor on AsymmetricKey > objects that allow a PKCS #8 blob as input, such that a call to unwrap > using a SymmetricKey can invoke such a constructor. Conversely, there > should be a function on AsymmetricKey objects that output a suitable > PKCS #8 blob for an invocation of wrap using a SymmetricKey object. Do I understand correctly that 'unwrap' method of SymmetricKey object should yield new AsymmetricKey object (constructed from PKCS8 blob)? What method do you propose for distinguishing cases where wrapped blob contains symmetric or asymmetric key? (AFAIK it can happen with symmetric algorithms.) Thank you for guidance! -- Petr Spacek @ Red Hat From pspacek at redhat.com Mon Jul 21 14:59:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 21 Jul 2014 16:59:31 +0200 Subject: [Softhsm-develop] support for CKM_RSA_PKCS key un/wrapping In-Reply-To: <53C957F8.8060205@redhat.com> References: <53C8058D.7090306@redhat.com> <53C8DAD6.3030305@surfnet.nl> <53C957F8.8060205@redhat.com> Message-ID: <53CD2AD3.90500@redhat.com> On 18.7.2014 19:23, Petr Spacek wrote: > On 18.7.2014 10:29, Roland van Rijswijk - Deij wrote: >> Hi Petr, >> >> Petr Spacek wrote: >>> I have opened pull request #83 which adds support for CKM_RSA_PKCS key >>> un/wrapping. >>> https://github.com/opendnssec/SoftHSMv2/pull/83 >>> >>> Let's discuss about this code and your requirements :-) >>> >>> Current code uses AsymmetricAlgorithm->encrypt() and decrypt() directly. >>> >>> I wonder if it is really necessary to introduce new AsymmetricAlgorithm >>> interface for wrap() and unwrap(). To me it seems that calling encrypt() >>> and decrypt() with correct AsymMech could be enough... >>> >>> Other alternative would be to add wrap() and unwrap() interface and >>> simply relay calls wrap()->encrypt() etc. It would allow us to filter >>> out some inappropriate mechanism from wrap() call but that is all. (E.g. >>> refusing to do key wrapping if mechanism is CKM_SHA1_RSA_PKCS or >>> something like that.) >>> >>> Is it worth doing so? Thank you for your opinions. >> >> I think it is worthwhile having a separate interface. Not just because >> it looks cleaner, also because you can manage permissions on keys that >> allow or disallow certain operations (such as wrapping/unwrapping). I > > Could you be more specific, please? What do you mean with 'permissions'? Do > you mean PKCS#11 tables which say e.g. that CKM_SHA1_RSA_PKCS cannot be used > for key wrapping? > > Or something else? It seems to me that crypto layer (AsymmetricAlgorithm and > others) is deep below P11Object so those objects doesn't have any knowledge of > allowed key usages. > > I mean: In cases where PKCS#11 *standard* allows to use given mechanism for > encryption and wrapping but P11Object says something else (e.g. allows only > key wrapping) there is no way for AsymmetricAlgorithm to know about this > limitation. > > Please correct me if I'm wrong. > > > I can certainly write wrap() as a wrapper around encrypt() which will > implement PKCS#11 'tables'. I imagine that it would be fairly simple: > > bool wrap(..., padding) { > switch (padding) { > case RSA_PKCS: > return encrypt(..., padding); > > default: > // includes CKM_SHA1_RSA_PKCS > return false; > } > } > > > Adding knowledge about allowed key usage to AsymmetricAlgorithm would be more > invasive change. > >> also think it is worthwhile having a constructor on AsymmetricKey >> objects that allow a PKCS #8 blob as input, such that a call to unwrap >> using a SymmetricKey can invoke such a constructor. Conversely, there >> should be a function on AsymmetricKey objects that output a suitable >> PKCS #8 blob for an invocation of wrap using a SymmetricKey object. > > Do I understand correctly that 'unwrap' method of SymmetricKey object should > yield new AsymmetricKey object (constructed from PKCS8 blob)? > > What method do you propose for distinguishing cases where wrapped blob > contains symmetric or asymmetric key? (AFAIK it can happen with symmetric > algorithms.) > > Thank you for guidance! Proof-of-concept code is available: https://github.com/opendnssec/SoftHSMv2/pull/85 Please let me know if it fulfills your requirements or what should be changed. Thank you! -- Petr Spacek @ Red Hat From Roland.vanRijswijk at surfnet.nl Mon Jul 21 15:03:47 2014 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Mon, 21 Jul 2014 17:03:47 +0200 Subject: [Softhsm-develop] Update on wrap/unwrap Message-ID: <53CD2BD3.9070701@surfnet.nl> Hi Petr, First of all thanks for all the time you are putting into this, it is great to have new contributions to SoftHSM v2! Now, I'm going to ask for a little bit of your patience. I would like to ask Rickard Bellgrim to review the code before we merge it and to discuss implementation options with you. Unfortunately, Rickard is currently on holiday so this will take some time, I hope that is not too inconvenient for you. Rickard will be back in 3 weeks time (as of today). If I find some time myself to do the review I will do so, unfortunately I cannot guarantee that I can find the time before Rickard is back, so please bear with us. Thanks again for contributing! Best regards, Roland -- -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4412 bytes Desc: S/MIME Cryptographic Signature URL: From pspacek at redhat.com Tue Jul 22 11:37:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Jul 2014 13:37:00 +0200 Subject: [Softhsm-develop] Re: Update on wrap/unwrap In-Reply-To: <53CD2BD3.9070701@surfnet.nl> References: <53CD2BD3.9070701@surfnet.nl> Message-ID: <53CE4CDC.8010508@redhat.com> Hi Roland, On 21.7.2014 17:03, Roland van Rijswijk - Deij wrote: > First of all thanks for all the time you are putting into this, it is > great to have new contributions to SoftHSM v2! Now, I'm going to ask for > a little bit of your patience. I would like to ask Rickard Bellgrim to > review the code before we merge it and to discuss implementation options > with you. Unfortunately, Rickard is currently on holiday so this will > take some time, I hope that is not too inconvenient for you. Rickard > will be back in 3 weeks time (as of today). I will keep it in mind, thank your for information. Originally I was somehow hopping that we can polish and merge my patches this week because I will be on vacation and later on FLOCK conference between Saturday 2014-07-26 and Sunday 2014-08-10. Anyway, I can live with my developer builds [1] for now. For me the hard deadline is Thursday 2014-08-21. I would like to have everything in upstream git at that time. What do you think? Is it possible? (The other alternative is to patch upstream code in Fedora packages which is undesirable. Fedora policy is to work with upstream as closely as possible.) Have a nice day. [1] https://copr.fedoraproject.org/coprs/pspacek/ -- Petr Spacek @ Red Hat From jerry at opendnssec.org Tue Jul 22 14:59:04 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Tue, 22 Jul 2014 16:59:04 +0200 Subject: [Softhsm-develop] Re: Update on wrap/unwrap In-Reply-To: <53CE4CDC.8010508@redhat.com> References: <53CD2BD3.9070701@surfnet.nl> <53CE4CDC.8010508@redhat.com> Message-ID: <1406041144.32410.3.camel@what> Hi Petr, On tis, 2014-07-22 at 13:37 +0200, Petr Spacek wrote: > Anyway, I can live with my developer builds [1] for now. For me the hard > deadline is Thursday 2014-08-21. I would like to have everything in upstream > git at that time. What do you think? Is it possible? Since SoftHSMv2 is still in alpha and new alpha release is easy and fast to make but this still needs to be reviewed by Rickard. Seeing that he should be back the week before your hard deadline there should be plenty of time to get this in before that. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From pspacek at redhat.com Tue Jul 22 15:49:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Jul 2014 17:49:23 +0200 Subject: [Softhsm-develop] Re: Update on wrap/unwrap In-Reply-To: <1406041144.32410.3.camel@what> References: <53CD2BD3.9070701@surfnet.nl> <53CE4CDC.8010508@redhat.com> <1406041144.32410.3.camel@what> Message-ID: <53CE8803.6060805@redhat.com> On 22.7.2014 16:59, Jerry Lundstr?m wrote: > Hi Petr, > > On tis, 2014-07-22 at 13:37 +0200, Petr Spacek wrote: >> Anyway, I can live with my developer builds [1] for now. For me the hard >> deadline is Thursday 2014-08-21. I would like to have everything in upstream >> git at that time. What do you think? Is it possible? > > Since SoftHSMv2 is still in alpha and new alpha release is easy and fast > to make but this still needs to be reviewed by Rickard. Seeing that he > should be back the week before your hard deadline there should be plenty > of time to get this in before that. Let me clarify that I don't need "release". Pure git push to upstream repo is enough if we can agree on patches. Have a nice day! -- Petr Spacek @ Red Hat