PKCS12 APIs with fips 3.0

Thu Jan 28 09:46:20 UTC 2021

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
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]