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-boun...@openssl.org> On
Behalf
Of
Dr Paul Dale
Sent: Tuesday, January 26, 2021 5:22 PM
To: openssl-users@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
