Re: PKCS#11 provider issues with min and max size
Hi Valerie, Sorry for delayed response, I've been away :-( Turns out there is a bug report for this already, although related to RSA keys, not EC as in my case. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8183107 I can not add additional information to the issue of course, but the information we exchanged here should be valuable input to this issue. Also that there are several users with this issue. Cheers, Tomas --- Meet us at RSA Conference, booth #1518. Use the code X8EPRIME to get your free expo pass. ** PrimeKey Solutions AB Lundagatan 16, 171 63 Solna, Sweden Mob: +46 (0)707421096 Internet: www.primekey.se Twitter: twitter.com/primekeyPKI ** On 2018-02-15 23:51, Valerie Peng wrote: > > Yes, please go ahead and file a bug for this. > Thanks! > Valerie > > On 2/13/2018 6:00 AM, Tomas Gustavsson wrote: >> Thanks for taking a look. >> >> I haven't created a bug for this (yet) Let me know if that would help. >> >> Regards, >> Tomas >> On 2018-02-09 20:04, Valerie Peng wrote: >>> Hmm, seems reasonable to support this in the provider configuration >>> file. >>> Or, on a similar note, but slightly different approach is to just add an >>> configuration option for disabling checking the supported key size >>> range. >>> Regards, >>> Valerie >>> >>> On 2/9/2018 2:16 AM, Tomas Gustavsson wrote: I just realized that a natural place to configure provider behavior is in the provider construction, which is also per provider, so you can have multiple ones with different configuration. We are already using an InputStream to construct SunPKCS11, and adding more parameters to configure/override defaults would be natural. I.e.: - name = library = ; slot = slot rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN rsakeygenmechminsize = 1024 rsakeygenmechmaxsize = 8192 attributes(*, CKO_PUBLIC_KEY, *) = { CKA_TOKEN = false CKA_ENCRYPT = true CKA_VERIFY = true CKA_WRAP = true } attributes(*, CKO_PRIVATE_KEY, *) = { CKA_DERIVE = false CKA_TOKEN = true CKA_PRIVATE = true CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_DECRYPT = true CKA_SIGN = true CKA_UNWRAP = true } attributes(*, CKO_SECRET_KEY, *) = { CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_ENCRYPT = true CKA_DECRYPT = true CKA_SIGN = true CKA_VERIFY = true CKA_WRAP = true CKA_UNWRAP = true } - Cheers, Tomas On 2018-02-09 09:55, Tomas Gustavsson wrote: > Hi, > > Thanks for the answer. (sorry I was out with the flu for a week) > >> I am not too keen to add an env var/system property to accommodate >> this >> kind of PKCS11 library bugs since this should be rare I hope. >> Valerie > Unfortunately I don't see it as rare and the impact is huge due to the > slow turnaround of HSM firmware. Due to FIPS certification and whatnot > HSM vendors do not fix simple things like this sometimes in years. > This > puts customers to a complete halt in the meantime. These are heavily > certified environments where re-certification alone takes at least 6 > months. > > Having worked with all major HSM vendors for many years I know that > PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 > natively, you can hack around by ignoring bad values, but when using > SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 > which is not for everyone. > > Due to the strictness of using SunPKCS11 compared to native PKCS#11, > some more flexibility in configuration would help a lot. > > For many years SunPKCS11 have worked great. But also the HSM world is > moving faster than they did 5 years ago, and unfortunately this means > that we're seeing a huge rise in PKCS#11 issues in the last year, > requiring quite a lot of hacking in SunPKCS11 to workaround. In theory > it should not be needed, but in practice it is. Faster evolution = > more > bugs. > > I just showed two real world use cases that you really need to be able > to work around. And these will not be the last. PKCS#11 is a complex > standard and implementors will rarely get it exactly right. > > Increased flexibility and more control around PKCS#11 will be > needed in > the future imho, or users will be forced to move to other solutions > like > JackNJI11. We'd much rather use SunPKCS11 but customers (end users) > can't get stuck between Java and HSM vendors in a fight who does > PKCS#11 > right or wrong. > > Cheers, > Tomas > > On 2018-02-01 01:07, Valerie Peng wrote: >> Thanks for the feedback. I suppose we can ignore values which >> obviously >> don'
Re: PKCS#11 provider issues with min and max size
Yes, please go ahead and file a bug for this. Thanks! Valerie On 2/13/2018 6:00 AM, Tomas Gustavsson wrote: Thanks for taking a look. I haven't created a bug for this (yet) Let me know if that would help. Regards, Tomas On 2018-02-09 20:04, Valerie Peng wrote: Hmm, seems reasonable to support this in the provider configuration file. Or, on a similar note, but slightly different approach is to just add an configuration option for disabling checking the supported key size range. Regards, Valerie On 2/9/2018 2:16 AM, Tomas Gustavsson wrote: I just realized that a natural place to configure provider behavior is in the provider construction, which is also per provider, so you can have multiple ones with different configuration. We are already using an InputStream to construct SunPKCS11, and adding more parameters to configure/override defaults would be natural. I.e.: - name = library = ; slot = slot rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN rsakeygenmechminsize = 1024 rsakeygenmechmaxsize = 8192 attributes(*, CKO_PUBLIC_KEY, *) = { CKA_TOKEN = false CKA_ENCRYPT = true CKA_VERIFY = true CKA_WRAP = true } attributes(*, CKO_PRIVATE_KEY, *) = { CKA_DERIVE = false CKA_TOKEN = true CKA_PRIVATE = true CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_DECRYPT = true CKA_SIGN = true CKA_UNWRAP = true } attributes(*, CKO_SECRET_KEY, *) = { CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_ENCRYPT = true CKA_DECRYPT = true CKA_SIGN = true CKA_VERIFY = true CKA_WRAP = true CKA_UNWRAP = true } - Cheers, Tomas On 2018-02-09 09:55, Tomas Gustavsson wrote: Hi, Thanks for the answer. (sorry I was out with the flu for a week) I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie Unfortunately I don't see it as rare and the impact is huge due to the slow turnaround of HSM firmware. Due to FIPS certification and whatnot HSM vendors do not fix simple things like this sometimes in years. This puts customers to a complete halt in the meantime. These are heavily certified environments where re-certification alone takes at least 6 months. Having worked with all major HSM vendors for many years I know that PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 natively, you can hack around by ignoring bad values, but when using SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 which is not for everyone. Due to the strictness of using SunPKCS11 compared to native PKCS#11, some more flexibility in configuration would help a lot. For many years SunPKCS11 have worked great. But also the HSM world is moving faster than they did 5 years ago, and unfortunately this means that we're seeing a huge rise in PKCS#11 issues in the last year, requiring quite a lot of hacking in SunPKCS11 to workaround. In theory it should not be needed, but in practice it is. Faster evolution = more bugs. I just showed two real world use cases that you really need to be able to work around. And these will not be the last. PKCS#11 is a complex standard and implementors will rarely get it exactly right. Increased flexibility and more control around PKCS#11 will be needed in the future imho, or users will be forced to move to other solutions like JackNJI11. We'd much rather use SunPKCS11 but customers (end users) can't get stuck between Java and HSM vendors in a fight who does PKCS#11 right or wrong. Cheers, Tomas On 2018-02-01 01:07, Valerie Peng wrote: Thanks for the feedback. I suppose we can ignore values which obviously don't make sense such as 0 or max being less than min key size. However, if the underlying PKCS11 library vendors forgot to update the max value as in your comment#2, supposedly they should fix it. I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: Hi, At some revision in the PKCS#11 provider there was introduced checking of C_GetMechanismInfo min and max sizes. This has turned out to be a bit fragile. Let me give two real world examples: 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The Java PKCS#11 provider will happily take 0 as maxSize and refuse to generate any EC keys at all. Needless to say, without the Java check it would be no problem. 131: C_GetMechanismInfo 2018-01-30 07:52:20.740 [in] slotID = 0x1 CKM_EC_KEY_PAIR_GEN [out] pInfo: CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware KeyPair ) Returned: 0 CKR_OK (we are reporting this to Amazon as well) 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize is not true. We have customers who used to generate 8192 bit RSA keys, but after a Java update can not do so anymore, because Java compar
Re: PKCS#11 provider issues with min and max size
Thanks for taking a look. I haven't created a bug for this (yet) Let me know if that would help. Regards, Tomas On 2018-02-09 20:04, Valerie Peng wrote: > > Hmm, seems reasonable to support this in the provider configuration file. > Or, on a similar note, but slightly different approach is to just add an > configuration option for disabling checking the supported key size range. > Regards, > Valerie > > On 2/9/2018 2:16 AM, Tomas Gustavsson wrote: >> I just realized that a natural place to configure provider behavior is >> in the provider construction, which is also per provider, so you can >> have multiple ones with different configuration. We are already using an >> InputStream to construct SunPKCS11, and adding more parameters to >> configure/override defaults would be natural. >> >> I.e.: >> - >> name = >> library = ; >> slot = slot >> rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN >> rsakeygenmechminsize = 1024 >> rsakeygenmechmaxsize = 8192 >> >> attributes(*, CKO_PUBLIC_KEY, *) = { >> CKA_TOKEN = false >> CKA_ENCRYPT = true >> CKA_VERIFY = true >> CKA_WRAP = true >> } >> attributes(*, CKO_PRIVATE_KEY, *) = { >> CKA_DERIVE = false >> CKA_TOKEN = true >> CKA_PRIVATE = true >> CKA_SENSITIVE = true >> CKA_EXTRACTABLE = false >> CKA_DECRYPT = true >> CKA_SIGN = true >> CKA_UNWRAP = true >> } >> attributes(*, CKO_SECRET_KEY, *) = { >> CKA_SENSITIVE = true >> CKA_EXTRACTABLE = false >> CKA_ENCRYPT = true >> CKA_DECRYPT = true >> CKA_SIGN = true >> CKA_VERIFY = true >> CKA_WRAP = true >> CKA_UNWRAP = true >> } >> - >> >> Cheers, >> Tomas >> >> On 2018-02-09 09:55, Tomas Gustavsson wrote: >>> Hi, >>> >>> Thanks for the answer. (sorry I was out with the flu for a week) >>> I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie >>> Unfortunately I don't see it as rare and the impact is huge due to the >>> slow turnaround of HSM firmware. Due to FIPS certification and whatnot >>> HSM vendors do not fix simple things like this sometimes in years. This >>> puts customers to a complete halt in the meantime. These are heavily >>> certified environments where re-certification alone takes at least 6 >>> months. >>> >>> Having worked with all major HSM vendors for many years I know that >>> PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 >>> natively, you can hack around by ignoring bad values, but when using >>> SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 >>> which is not for everyone. >>> >>> Due to the strictness of using SunPKCS11 compared to native PKCS#11, >>> some more flexibility in configuration would help a lot. >>> >>> For many years SunPKCS11 have worked great. But also the HSM world is >>> moving faster than they did 5 years ago, and unfortunately this means >>> that we're seeing a huge rise in PKCS#11 issues in the last year, >>> requiring quite a lot of hacking in SunPKCS11 to workaround. In theory >>> it should not be needed, but in practice it is. Faster evolution = more >>> bugs. >>> >>> I just showed two real world use cases that you really need to be able >>> to work around. And these will not be the last. PKCS#11 is a complex >>> standard and implementors will rarely get it exactly right. >>> >>> Increased flexibility and more control around PKCS#11 will be needed in >>> the future imho, or users will be forced to move to other solutions like >>> JackNJI11. We'd much rather use SunPKCS11 but customers (end users) >>> can't get stuck between Java and HSM vendors in a fight who does PKCS#11 >>> right or wrong. >>> >>> Cheers, >>> Tomas >>> >>> On 2018-02-01 01:07, Valerie Peng wrote: Thanks for the feedback. I suppose we can ignore values which obviously don't make sense such as 0 or max being less than min key size. However, if the underlying PKCS11 library vendors forgot to update the max value as in your comment#2, supposedly they should fix it. I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: > Hi, > > At some revision in the PKCS#11 provider there was introduced checking > of C_GetMechanismInfo min and max sizes. > > This has turned out to be a bit fragile. Let me give two real world > examples: > > 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The > Java PKCS#11 provider will happily take 0 as maxSize and refuse to > generate any EC keys at all. Needless to say, without the Java > check it > would be no problem. > > 131: C_GetMechanismInfo > 2018-01-30 07:52:20.740 > [in] slotID = 0x1 > CKM_EC_KEY_PAIR_GEN > [out] pInfo: > CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware > Ke
Re: PKCS#11 provider issues with min and max size
Hmm, seems reasonable to support this in the provider configuration file. Or, on a similar note, but slightly different approach is to just add an configuration option for disabling checking the supported key size range. Regards, Valerie On 2/9/2018 2:16 AM, Tomas Gustavsson wrote: I just realized that a natural place to configure provider behavior is in the provider construction, which is also per provider, so you can have multiple ones with different configuration. We are already using an InputStream to construct SunPKCS11, and adding more parameters to configure/override defaults would be natural. I.e.: - name = library = ; slot = slot rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN rsakeygenmechminsize = 1024 rsakeygenmechmaxsize = 8192 attributes(*, CKO_PUBLIC_KEY, *) = { CKA_TOKEN = false CKA_ENCRYPT = true CKA_VERIFY = true CKA_WRAP = true } attributes(*, CKO_PRIVATE_KEY, *) = { CKA_DERIVE = false CKA_TOKEN = true CKA_PRIVATE = true CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_DECRYPT = true CKA_SIGN = true CKA_UNWRAP = true } attributes(*, CKO_SECRET_KEY, *) = { CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_ENCRYPT = true CKA_DECRYPT = true CKA_SIGN = true CKA_VERIFY = true CKA_WRAP = true CKA_UNWRAP = true } - Cheers, Tomas On 2018-02-09 09:55, Tomas Gustavsson wrote: Hi, Thanks for the answer. (sorry I was out with the flu for a week) I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie Unfortunately I don't see it as rare and the impact is huge due to the slow turnaround of HSM firmware. Due to FIPS certification and whatnot HSM vendors do not fix simple things like this sometimes in years. This puts customers to a complete halt in the meantime. These are heavily certified environments where re-certification alone takes at least 6 months. Having worked with all major HSM vendors for many years I know that PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 natively, you can hack around by ignoring bad values, but when using SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 which is not for everyone. Due to the strictness of using SunPKCS11 compared to native PKCS#11, some more flexibility in configuration would help a lot. For many years SunPKCS11 have worked great. But also the HSM world is moving faster than they did 5 years ago, and unfortunately this means that we're seeing a huge rise in PKCS#11 issues in the last year, requiring quite a lot of hacking in SunPKCS11 to workaround. In theory it should not be needed, but in practice it is. Faster evolution = more bugs. I just showed two real world use cases that you really need to be able to work around. And these will not be the last. PKCS#11 is a complex standard and implementors will rarely get it exactly right. Increased flexibility and more control around PKCS#11 will be needed in the future imho, or users will be forced to move to other solutions like JackNJI11. We'd much rather use SunPKCS11 but customers (end users) can't get stuck between Java and HSM vendors in a fight who does PKCS#11 right or wrong. Cheers, Tomas On 2018-02-01 01:07, Valerie Peng wrote: Thanks for the feedback. I suppose we can ignore values which obviously don't make sense such as 0 or max being less than min key size. However, if the underlying PKCS11 library vendors forgot to update the max value as in your comment#2, supposedly they should fix it. I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: Hi, At some revision in the PKCS#11 provider there was introduced checking of C_GetMechanismInfo min and max sizes. This has turned out to be a bit fragile. Let me give two real world examples: 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The Java PKCS#11 provider will happily take 0 as maxSize and refuse to generate any EC keys at all. Needless to say, without the Java check it would be no problem. 131: C_GetMechanismInfo 2018-01-30 07:52:20.740 [in] slotID = 0x1 CKM_EC_KEY_PAIR_GEN [out] pInfo: CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware KeyPair ) Returned: 0 CKR_OK (we are reporting this to Amazon as well) 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize is not true. We have customers who used to generate 8192 bit RSA keys, but after a Java update can not do so anymore, because Java compares against this value. * Suggestions: 1. In the constructor of P11KeyPairGenerator where minKeyLen and maxKeyLen are calculated, never allow maxKeyLen to be less than minKeyLen. I.e. change the part: // auto-adjust default keysize in case it's out-of-range if (
Re: PKCS#11 provider issues with min and max size
Oh-well, I suppose that we are all humans. ;) Let me take a closer look on this and see if there are other ways to relax this constraint than adding env var which should be the very last resort in my opinion. BTW, is there a bug filed for this? Thanks for the feedback, Valerie On 2/9/2018 12:55 AM, Tomas Gustavsson wrote: Hi, Thanks for the answer. (sorry I was out with the flu for a week) I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie Unfortunately I don't see it as rare and the impact is huge due to the slow turnaround of HSM firmware. Due to FIPS certification and whatnot HSM vendors do not fix simple things like this sometimes in years. This puts customers to a complete halt in the meantime. These are heavily certified environments where re-certification alone takes at least 6 months. Having worked with all major HSM vendors for many years I know that PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 natively, you can hack around by ignoring bad values, but when using SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 which is not for everyone. Due to the strictness of using SunPKCS11 compared to native PKCS#11, some more flexibility in configuration would help a lot. For many years SunPKCS11 have worked great. But also the HSM world is moving faster than they did 5 years ago, and unfortunately this means that we're seeing a huge rise in PKCS#11 issues in the last year, requiring quite a lot of hacking in SunPKCS11 to workaround. In theory it should not be needed, but in practice it is. Faster evolution = more bugs. I just showed two real world use cases that you really need to be able to work around. And these will not be the last. PKCS#11 is a complex standard and implementors will rarely get it exactly right. Increased flexibility and more control around PKCS#11 will be needed in the future imho, or users will be forced to move to other solutions like JackNJI11. We'd much rather use SunPKCS11 but customers (end users) can't get stuck between Java and HSM vendors in a fight who does PKCS#11 right or wrong. Cheers, Tomas On 2018-02-01 01:07, Valerie Peng wrote: Thanks for the feedback. I suppose we can ignore values which obviously don't make sense such as 0 or max being less than min key size. However, if the underlying PKCS11 library vendors forgot to update the max value as in your comment#2, supposedly they should fix it. I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: Hi, At some revision in the PKCS#11 provider there was introduced checking of C_GetMechanismInfo min and max sizes. This has turned out to be a bit fragile. Let me give two real world examples: 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The Java PKCS#11 provider will happily take 0 as maxSize and refuse to generate any EC keys at all. Needless to say, without the Java check it would be no problem. 131: C_GetMechanismInfo 2018-01-30 07:52:20.740 [in] slotID = 0x1 CKM_EC_KEY_PAIR_GEN [out] pInfo: CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware KeyPair ) Returned: 0 CKR_OK (we are reporting this to Amazon as well) 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize is not true. We have customers who used to generate 8192 bit RSA keys, but after a Java update can not do so anymore, because Java compares against this value. * Suggestions: 1. In the constructor of P11KeyPairGenerator where minKeyLen and maxKeyLen are calculated, never allow maxKeyLen to be less than minKeyLen. I.e. change the part: // auto-adjust default keysize in case it's out-of-range if ((minKeyLen != -1) && (keySize < minKeyLen)) { keySize = minKeyLen; } if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { keySize = maxKeyLen; } To include something like: // auto-adjust default keysize in case it's out-of-range if ((minKeyLen != -1) && (keySize < minKeyLen)) { keySize = minKeyLen; } if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { maxKeyLen = minKeyLen; } if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { keySize = maxKeyLen; } 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to ignore checking against C_GetMechanismInfo if you know that the HSM does not provide sane values. I.e. an environment variable for example reverting back to the old behavior when these were ignored. Regards, Tomas Gustavsson
Re: PKCS#11 provider issues with min and max size
I just realized that a natural place to configure provider behavior is in the provider construction, which is also per provider, so you can have multiple ones with different configuration. We are already using an InputStream to construct SunPKCS11, and adding more parameters to configure/override defaults would be natural. I.e.: - name = library = ; slot = slot rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN rsakeygenmechminsize = 1024 rsakeygenmechmaxsize = 8192 attributes(*, CKO_PUBLIC_KEY, *) = { CKA_TOKEN = false CKA_ENCRYPT = true CKA_VERIFY = true CKA_WRAP = true } attributes(*, CKO_PRIVATE_KEY, *) = { CKA_DERIVE = false CKA_TOKEN = true CKA_PRIVATE = true CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_DECRYPT = true CKA_SIGN = true CKA_UNWRAP = true } attributes(*, CKO_SECRET_KEY, *) = { CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_ENCRYPT = true CKA_DECRYPT = true CKA_SIGN = true CKA_VERIFY = true CKA_WRAP = true CKA_UNWRAP = true } - Cheers, Tomas On 2018-02-09 09:55, Tomas Gustavsson wrote: > > Hi, > > Thanks for the answer. (sorry I was out with the flu for a week) > >> I am not too keen to add an env var/system property to accommodate this >> kind of PKCS11 library bugs since this should be rare I hope. >> Valerie > > Unfortunately I don't see it as rare and the impact is huge due to the > slow turnaround of HSM firmware. Due to FIPS certification and whatnot > HSM vendors do not fix simple things like this sometimes in years. This > puts customers to a complete halt in the meantime. These are heavily > certified environments where re-certification alone takes at least 6 months. > > Having worked with all major HSM vendors for many years I know that > PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 > natively, you can hack around by ignoring bad values, but when using > SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 > which is not for everyone. > > Due to the strictness of using SunPKCS11 compared to native PKCS#11, > some more flexibility in configuration would help a lot. > > For many years SunPKCS11 have worked great. But also the HSM world is > moving faster than they did 5 years ago, and unfortunately this means > that we're seeing a huge rise in PKCS#11 issues in the last year, > requiring quite a lot of hacking in SunPKCS11 to workaround. In theory > it should not be needed, but in practice it is. Faster evolution = more > bugs. > > I just showed two real world use cases that you really need to be able > to work around. And these will not be the last. PKCS#11 is a complex > standard and implementors will rarely get it exactly right. > > Increased flexibility and more control around PKCS#11 will be needed in > the future imho, or users will be forced to move to other solutions like > JackNJI11. We'd much rather use SunPKCS11 but customers (end users) > can't get stuck between Java and HSM vendors in a fight who does PKCS#11 > right or wrong. > > Cheers, > Tomas > > On 2018-02-01 01:07, Valerie Peng wrote: >> >> Thanks for the feedback. I suppose we can ignore values which obviously >> don't make sense such as 0 or max being less than min key size. >> However, if the underlying PKCS11 library vendors forgot to update the >> max value as in your comment#2, supposedly they should fix it. >> I am not too keen to add an env var/system property to accommodate this >> kind of PKCS11 library bugs since this should be rare I hope. >> Valerie >> >> On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >>> Hi, >>> >>> At some revision in the PKCS#11 provider there was introduced checking >>> of C_GetMechanismInfo min and max sizes. >>> >>> This has turned out to be a bit fragile. Let me give two real world >>> examples: >>> >>> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >>> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >>> generate any EC keys at all. Needless to say, without the Java check it >>> would be no problem. >>> >>> 131: C_GetMechanismInfo >>> 2018-01-30 07:52:20.740 >>> [in] slotID = 0x1 >>> CKM_EC_KEY_PAIR_GEN >>> [out] pInfo: >>> CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware >>> KeyPair ) >>> Returned: 0 CKR_OK >>> >>> (we are reporting this to Amazon as well) >>> >>> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >>> 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize >>> is not true. >>> We have customers who used to generate 8192 bit RSA keys, but after a >>> Java update can not do so anymore, because Java compares against this >>> value. >>> >>> >>> * Suggestions: >>> >>> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >>> maxKeyLen are calculated, never allow maxKeyLen to be less than >>> minKeyLen. >>> >>> I.e. change the part: >>> // auto-adjust default keysize in case it's out-of-range >>> if ((minKeyLen != -1) && (keySize < minKey
Re: PKCS#11 provider issues with min and max size
Hi, Thanks for the answer. (sorry I was out with the flu for a week) > I am not too keen to add an env var/system property to accommodate this > kind of PKCS11 library bugs since this should be rare I hope. > Valerie Unfortunately I don't see it as rare and the impact is huge due to the slow turnaround of HSM firmware. Due to FIPS certification and whatnot HSM vendors do not fix simple things like this sometimes in years. This puts customers to a complete halt in the meantime. These are heavily certified environments where re-certification alone takes at least 6 months. Having worked with all major HSM vendors for many years I know that PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 natively, you can hack around by ignoring bad values, but when using SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 which is not for everyone. Due to the strictness of using SunPKCS11 compared to native PKCS#11, some more flexibility in configuration would help a lot. For many years SunPKCS11 have worked great. But also the HSM world is moving faster than they did 5 years ago, and unfortunately this means that we're seeing a huge rise in PKCS#11 issues in the last year, requiring quite a lot of hacking in SunPKCS11 to workaround. In theory it should not be needed, but in practice it is. Faster evolution = more bugs. I just showed two real world use cases that you really need to be able to work around. And these will not be the last. PKCS#11 is a complex standard and implementors will rarely get it exactly right. Increased flexibility and more control around PKCS#11 will be needed in the future imho, or users will be forced to move to other solutions like JackNJI11. We'd much rather use SunPKCS11 but customers (end users) can't get stuck between Java and HSM vendors in a fight who does PKCS#11 right or wrong. Cheers, Tomas On 2018-02-01 01:07, Valerie Peng wrote: > > Thanks for the feedback. I suppose we can ignore values which obviously > don't make sense such as 0 or max being less than min key size. > However, if the underlying PKCS11 library vendors forgot to update the > max value as in your comment#2, supposedly they should fix it. > I am not too keen to add an env var/system property to accommodate this > kind of PKCS11 library bugs since this should be rare I hope. > Valerie > > On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >> Hi, >> >> At some revision in the PKCS#11 provider there was introduced checking >> of C_GetMechanismInfo min and max sizes. >> >> This has turned out to be a bit fragile. Let me give two real world >> examples: >> >> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >> generate any EC keys at all. Needless to say, without the Java check it >> would be no problem. >> >> 131: C_GetMechanismInfo >> 2018-01-30 07:52:20.740 >> [in] slotID = 0x1 >> CKM_EC_KEY_PAIR_GEN >> [out] pInfo: >> CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware >> KeyPair ) >> Returned: 0 CKR_OK >> >> (we are reporting this to Amazon as well) >> >> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >> 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize >> is not true. >> We have customers who used to generate 8192 bit RSA keys, but after a >> Java update can not do so anymore, because Java compares against this >> value. >> >> >> * Suggestions: >> >> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >> maxKeyLen are calculated, never allow maxKeyLen to be less than >> minKeyLen. >> >> I.e. change the part: >> // auto-adjust default keysize in case it's out-of-range >> if ((minKeyLen != -1) && (keySize < minKeyLen)) { >> keySize = minKeyLen; >> } >> if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >> keySize = maxKeyLen; >> } >> >> To include something like: >> // auto-adjust default keysize in case it's out-of-range >> if ((minKeyLen != -1) && (keySize < minKeyLen)) { >> keySize = minKeyLen; >> } >> if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { >> maxKeyLen = minKeyLen; >> } >> if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >> keySize = maxKeyLen; >> } >> >> 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to >> ignore checking against C_GetMechanismInfo if you know that the HSM does >> not provide sane values. I.e. an environment variable for example >> reverting back to the old behavior when these were ignored. >> >> Regards, >> Tomas Gustavsson >> >
Re: PKCS#11 provider issues with min and max size
Thanks for the feedback. I suppose we can ignore values which obviously don't make sense such as 0 or max being less than min key size. However, if the underlying PKCS11 library vendors forgot to update the max value as in your comment#2, supposedly they should fix it. I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: Hi, At some revision in the PKCS#11 provider there was introduced checking of C_GetMechanismInfo min and max sizes. This has turned out to be a bit fragile. Let me give two real world examples: 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The Java PKCS#11 provider will happily take 0 as maxSize and refuse to generate any EC keys at all. Needless to say, without the Java check it would be no problem. 131: C_GetMechanismInfo 2018-01-30 07:52:20.740 [in] slotID = 0x1 CKM_EC_KEY_PAIR_GEN [out] pInfo: CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware KeyPair ) Returned: 0 CKR_OK (we are reporting this to Amazon as well) 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize is not true. We have customers who used to generate 8192 bit RSA keys, but after a Java update can not do so anymore, because Java compares against this value. * Suggestions: 1. In the constructor of P11KeyPairGenerator where minKeyLen and maxKeyLen are calculated, never allow maxKeyLen to be less than minKeyLen. I.e. change the part: // auto-adjust default keysize in case it's out-of-range if ((minKeyLen != -1) && (keySize < minKeyLen)) { keySize = minKeyLen; } if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { keySize = maxKeyLen; } To include something like: // auto-adjust default keysize in case it's out-of-range if ((minKeyLen != -1) && (keySize < minKeyLen)) { keySize = minKeyLen; } if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { maxKeyLen = minKeyLen; } if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { keySize = maxKeyLen; } 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to ignore checking against C_GetMechanismInfo if you know that the HSM does not provide sane values. I.e. an environment variable for example reverting back to the old behavior when these were ignored. Regards, Tomas Gustavsson
PKCS#11 provider issues with min and max size
Hi, At some revision in the PKCS#11 provider there was introduced checking of C_GetMechanismInfo min and max sizes. This has turned out to be a bit fragile. Let me give two real world examples: 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The Java PKCS#11 provider will happily take 0 as maxSize and refuse to generate any EC keys at all. Needless to say, without the Java check it would be no problem. 131: C_GetMechanismInfo 2018-01-30 07:52:20.740 [in] slotID = 0x1 CKM_EC_KEY_PAIR_GEN [out] pInfo: CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware KeyPair ) Returned: 0 CKR_OK (we are reporting this to Amazon as well) 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize is not true. We have customers who used to generate 8192 bit RSA keys, but after a Java update can not do so anymore, because Java compares against this value. * Suggestions: 1. In the constructor of P11KeyPairGenerator where minKeyLen and maxKeyLen are calculated, never allow maxKeyLen to be less than minKeyLen. I.e. change the part: // auto-adjust default keysize in case it's out-of-range if ((minKeyLen != -1) && (keySize < minKeyLen)) { keySize = minKeyLen; } if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { keySize = maxKeyLen; } To include something like: // auto-adjust default keysize in case it's out-of-range if ((minKeyLen != -1) && (keySize < minKeyLen)) { keySize = minKeyLen; } if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { maxKeyLen = minKeyLen; } if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { keySize = maxKeyLen; } 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to ignore checking against C_GetMechanismInfo if you know that the HSM does not provide sane values. I.e. an environment variable for example reverting back to the old behavior when these were ignored. Regards, Tomas Gustavsson -- ** PrimeKey Solutions AB Lundagatan 16, 171 63 Solna, Sweden Mob: +46 (0)707421096 Internet: www.primekey.se Twitter: twitter.com/primekeyPKI **