PKCS#11 provider issues with min and max size
Valerie Peng
valerie.peng at oracle.com
Thu Feb 15 22:51:44 UTC 2018
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 = <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
>>>>>>
More information about the security-dev
mailing list