PKCS#11 provider issues with min and max size
Tomas Gustavsson
tomas at primekey.se
Tue Feb 13 14:00:29 UTC 2018
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