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 = <providername> >> library = <p11 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 < 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 >>>>> >