PKCS12 APIs with fips 3.0

[Dr Paul Dale]

Of course OpenSSL 3.0 will support a strict FIPS mode and this will be 
the recommended set up.  By setting the default query to "fips=yes" or 
(better) setting up a library context that has no non-FIPS cryptographic 
implementations and you are in a strictly compliant FIPS mode.

If you want to use the PKCS #12 KDF, then you want something that 
*cannot* currently be FIPS validated --> you are not running in strict 
FIPS mode and need a solution that allows FIPS validated cryptographic 
implementations to be bypassed.


Pauli

On 28/1/21 8:08 pm, Jakob Bohm via openssl-users wrote:
> 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