PKCS12 APIs with fips 3.0

[Jakob Bohm]

If the context does not limit the use of higher level compositions, then
OpenSSL 3.0 provides no way to satisfy the usual requirement that a
product can be set into "FIPS mode" and not invoke the non-validated
lower level algorithms in the "default" provider.

The usual context is to "sell" (give) products to the US Government or
its contractors that have a "FIPS" box-checking procurement requirement.

On 2021-01-28 10:46, Tomas Mraz wrote:
> There is unfortunately no simple straightforward answer to this
> question. It really depends on the context.
> 
> Anyway OpenSSL 3.0 gives you all the flexibility needed.
> 
> Tomas
> 
> On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users wrote:
>> Does FIPS 140 or the related legal requirements limit the use of
>> higher
>> level compositions such as PKCS12KDF, when using only validated
>> cryptography for the underlying operations?
>>
>> On 2021-01-28 09:36, Tomas Mraz wrote:
>>> I do not get how you came to this conclusion. The "true" FIPS mode
>>> can
>>> be easily achieved with OpenSSL 3.0 - either by loading just the
>>> fips
>>> and base provider, or by loading both default and fips providers
>>> but
>>> using the "fips=yes" default property (without the "?").
>>>
>>> The PKCS12KDF does not work because it is not an FIPS approved KDF
>>> algorithm so it cannot really work in the "true" FIPS mode. But IMO
>>> this does not mean that PKCS12 keys do not work at all - if you use
>>> right (more modern) algoritm based on PBKDF2 to do the password
>>> based
>>> key derivation, they should work.
>>>
>>> That in 1.0.x the PKCS12 worked with the FIPS module with legacy
>>> algorithms it only shows that the "true" FIPS mode was not as
>>> "true" as
>>> you might think. There were some crypto algorithms like the KDFs
>>> outside of the FIPS module boundary.
>>>
>>> Tomas Mraz
>>>
>>> On Thu, 2021-01-28 at 09:26 +0100, Jakob Bohm via openssl-users
>>> wrote:
>>>> Does that mean that OpenSSL 3.0 will not have a true "FIPS mode"
>>>> where
>>>> all the non-FIPS algorithms are disabled, but the FIPS-
>>>> independent
>>>> schemes/protocols in the "default" provider remains available?
>>>>
>>>> Remember that in other software systems, such as OpenSSL 1.0.x
>>>> and
>>>> MS
>>>> CryptoAPI, FIPS mode causes all non-validated algorithms to fail
>>>> hard,
>>>> so all higher level operations are guaranteed to use only FIPS-
>>>> validated
>>>> crypto.
>>>>
>>>> On 2021-01-27 02:01, Dr Paul Dale wrote:
>>>>> You could set the default property query to "?fips=yes".  This
>>>>> will
>>>>> prefer FIPS algorithms over any others but will not prevent
>>>>> other
>>>>> algorithms from being fetched.
>>>>>
>>>>> Pauli
>>>>>
>>>>> On 27/1/21 10:47 am, Zeke Evans wrote:
>>>>>> I understand that PKCS12 cannot be implemented in the fips
>>>>>> provider
>>>>>> but I'm looking for a suitable workaround, particularly
>>>>>> something
>>>>>> that is close to the same behavior as 1.0.2 with the fips 2.0
>>>>>> module.
>>>>>>
>>>>>> In my case, the default provider is loaded but I am calling
>>>>>> EVP_set_default_properties(NULL, "fips=yes").  I can wrap
>>>>>> calls
>>>>>> to
>>>>>> the PKCS12 APIs and momentarily allow non-fips algorithms
>>>>>> (ie:
>>>>>> "fips=no" or "provider=default") but that prevents the PKCS12
>>>>>> implementation from using the crypto implementations in the
>>>>>> fips
>>>>>> provider.  Is there a property string or some other way to
>>>>>> allow
>>>>>> PKCS12KDF in the default provider as well as the crypto
>>>>>> methods
>>>>>> in
>>>>>> the fips provider?  I have tried "provider=default,fips=yes"
>>>>>> but
>>>>>> that
>>>>>> doesn't seem to work.
>>>>>>
>>>>>> Using the default provider is probably a reasonable
>>>>>> workaround
>>>>>> for
>>>>>> reading in PKCS12 files in order to maintain backwards
>>>>>> compatibility.  Is there a recommended method going forward
>>>>>> that
>>>>>> would allow reading and writing to a key store while only
>>>>>> using
>>>>>> the
>>>>>> fips provider?
>>>>>>
>>>>>> Thanks,
>>>>>> Zeke Evans
>>>>>> Micro Focus
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: openssl-users <openssl-users-bounces at openssl.org> On
>>>>>> Behalf
>>>>>> Of
>>>>>> Dr Paul Dale
>>>>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>>>>> To: openssl-users at openssl.org
>>>>>> Subject: Re: PKCS12 APIs with fips 3.0
>>>>>>
>>>>>> I'm not even sure that NIST can validate the PKCS#12 KDF.
>>>>>> If it can't be validated, it doesn't belong in the FIPS
>>>>>> provider.
>>>>>>
>>>>>>
>>>>>> Pauli
>>>>>>
>>>>>> On 26/1/21 10:48 pm, Tomas Mraz wrote:
>>>>>>> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>>>>>>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>>>>>>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Many of the PKCS12 APIs (ie: PKCS12_create,
>>>>>>>>>> PKCS12_parse,
>>>>>>>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when
>>>>>>>>>> using
>>>>>>>>>> the fips
>>>>>>>>>> provider.  It looks like that is because they try to
>>>>>>>>>> load
>>>>>>>>>> PKCS12KDF
>>>>>>>>>> which is not implemented in the fips provider.  These
>>>>>>>>>> were all
>>>>>>>>>> working in 1.0.2 with the fips 2.0 module.  Will they
>>>>>>>>>> be
>>>>>>>>>> supported
>>>>>>>>>> in 3.0 with fips?  If not, is there a way for
>>>>>>>>>> applications running
>>>>>>>>>> in fips approved mode to support the same
>>>>>>>>>> functionality
>>>>>>>>>> and use
>>>>>>>>>> existing stores/files that contain PKCS12 objects?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> This is an even larger issue: Is OpenSSL 3.x so badly
>>>>>>>>> designed that
>>>>>>>>> the "providers" need to separately implement every
>>>>>>>>> standard
>>>>>>>>> or
>>>>>>>>> non-standard combination of algorithm invocations?
>>>>>>>>>
>>>>>>>>> In a properly abstracted design PKCS12KDF would be
>>>>>>>>> implemented by
>>>>>>>>> invoking general EVP functions for underlying
>>>>>>>>> algorithms,
>>>>>>>>> which
>>>>>>>>> would in turn invoke the provider versions of those
>>>>>>>>> algorithms.
>>>>>>>>
>>>>>>>> This is exactly the way it works. The implementation of
>>>>>>>> PKCS12KDF
>>>>>>>> fetches the underlying digest algorithm using whatever
>>>>>>>> providers it
>>>>>>>> has available. So, for example, if the PKCS12KDF
>>>>>>>> implementation needs
>>>>>>>> to use SHA256, then it will fetch an available
>>>>>>>> implementation
>>>>>>>> for it
>>>>>>>> - and that implementation may come from the FIPS provider
>>>>>>>> (or
>>>>>>>> any
>>>>>>>> other provider).
>>>>>>>>
>>>>>>>> However, in 3.0, KDFs are themselves fetchable
>>>>>>>> cryptographic
>>>>>>>> algorithms implemented by providers. The FIPS module
>>>>>>>> implements a set
>>>>>>>> of KDFs - but PKCS12KDF is not one of them. Its only
>>>>>>>> available from
>>>>>>>> the default provider.
>>>>>>>>
>>>>>>>> So, the summary is, while you can set things up so that
>>>>>>>> all
>>>>>>>> your
>>>>>>>> crypto, including any digests used by the PKCS12KDF, all
>>>>>>>> come
>>>>>>>> from
>>>>>>>> the FIPS provider, there is no getting away from the fact
>>>>>>>> that you
>>>>>>>> still need to have the default provider loaded in order
>>>>>>>> to
>>>>>>>> have an
>>>>>>>> implementation of the PKCS12KDF itself - which will
>>>>>>>> obviously
>>>>>>>> be
>>>>>>>> outside the module boundary.
>>>>>>>>
>>>>>>>> There aren't any current plans to bring the
>>>>>>>> implementation of
>>>>>>>> PKCS12KDF inside the FIPS module. I don't know whether
>>>>>>>> that
>>>>>>>> is
>>>>>>>> feasible or not.
>>>>>>>
>>>>>>> IMO PKCS12KDF should not be in the FIPS module as this is
>>>>>>> not a
>>>>>>> FIPS
>>>>>>> approved KDF algorithm. Besides that KDF should not IMO be
>>>>>>> needed for
>>>>>>> "modern" PKCS12 files. I need to test that though.
>>>>>>>



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded