|
I find this conversation very interesting and insightful. I really do!… Kinda sick, I know. :-). I pretty much agree with Dr. Paul Dale, “I suggest discussing the details with your FIPS lab. Like most things FIPS: it's murky, nuanced and awash
with pitfalls.”…
What does the FIPS certificate security policy say in regards to the use of algs such as MD5? If you look at the FIPS Security policy for boring crypto (cert# 4407) Section 9.2 for example, it specifically states that MD5 is allowed for TLS1.0
and 1.1 although non-approved for FIPS140-2. Additionally, I find it extremely interesting that the table directly below that in Section 9.3, states MD5 is non-Approved and if you do use it you are in “non-Approved mode”. There is no FIPS enforcement by
the module. This puts the responsibility on application developer. The crypto module doesn’t claim to have knowledge of the use of the algorithm.
Another interesting security policy is AWS. With this problem they take a similar approach. Their policy (cert# 3553) states in Section 4.3.2 that there are algorithms that are non-approved but allowed. MD5 in the table listed here for use
in TLS only. In section 4.3.3 there is a table of all the non-approved/non-allowed algs. The interesting part is the statement above this table… “Table 8 lists the cryptographic algorithms that are not allowed to be used in the FIPS mode of operation.
Use of any of these algorithms (and corresponding services in Table 5) will
implicitly switch the module to the non-Approved mode. “ Again, the crypto module is not doing any FIPS enforcement and punting to the application.
This said there are some modules that do (or have done) enforcement. Then you get into the whole FIPS “distro” side…… see fun stuff!
So as Dr. Paul Dale and Hebert have both said, it is best to discuss with your FIPS labs and auditors.
thx,
-jj
On Thursday, 2 February 2023 16:31:20 CET, Matthew Heimlich wrote:
The question of whether or not non-FIPS-compliant algorithms should be allowed for non-cryptographic use is moot if you're deploying to environments requiring FIPS validation where the FIPS requirement is configured at the system
level. A full audit of every line of code of every application present on the system(s) is completely infeasible. There is no reasonable way to ensure that people are using insecure algorithms "the right way" in cases where security is a primary concern. A
blanket ban is the much more palatable option. And I can't think of a single case where one couldn't just as easily hash files using a compliant algorithm outside of support of legacy systems, in which case you'd have to go through the POAM/waiver process
anyway. You'll have a hard time convincing anyone that an application under active development will undergo enough inconvenience by switching to a compliant hashing algorithm that they'd waiver you these days.
What's compliant and what's not is between you and your auditor.
I'm just mentioning the technical means how to use those algorithms
with some older FIPS certified modules without getting the whole system out
of FIPS mode.
On Thu, Feb 2, 2023 at 7:00 AM Hubert Kario <hkario@xxxxxxxxxx> wrote:
On Thursday, 2 February 2023 01:45:00 CET, Sands, Daniel via openssl-users wrote:
-----Original Message-----
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Dr
Paul Dale
Sent: Wednesday, February 1, 2023 2:33 PM
To: openssl-users@xxxxxxxxxxx
Subject: [EXTERNAL] Re: MD5 and FIPS
If you are using OpenSSL 1.0.2 and the old FOM, you're out of luck.
If you are using OpenSSL 3.0 with the FIPS provider, you can still access MD5 by
loading appropriate providers and specifying a property query. See the
migration or FIPS guides.
This sounds like an acceptable workaround. So if I load the legacy provider, then request MD5 (or SHA1) explicitly through that provider, it should provide a working context?
For some old FIPS modules you can also re-enable the md5 hash by using
EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);
Looking how Python handles the usedforsecurity keyword argument in hashlib
module is a usually a good idea.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
|
