PKCS#11 provider issues with min and max size

Fri Feb 9 19:04:49 UTC 2018

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
>>>>