Identityserver4: DoD FIPS 140-2 compliance

[jasondavidcamp]

How can we enforce IdentityServer4 to use only FIPS 140-2 compliant crypto modules?

[leastprivilege]

That's a question for Microsoft @blowdart

[blowdart]

You configure the OS (for Windows) or OpenSSL (for Linux) for FIPS. There's nothing in .NET Core that is configurable, it will obey the OS configuration.

[jaredtait]

Is there a way we can prove the OS (Windows) is working? I have set HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaFipsAlgorithmPolicyEnabled to 1.
It is my understanding that all MD5 implementations have not been FIPS compliant for some time, so I fired up an .NET Core console the gets an MD5 hash of "Hello World" and it would calculate a hash without issue. Am I missing something? Incorrect registry entry?

I realize this example gets away from IndentityServer pretty quickly but for us to use IdentityServer (or .NET Core Crypto), we need to show some indication that we are using FIPS certified implementations in the OS.

[blowdart]

If you're targeting Core there is actually nothing in Core that does its own crypto, it passes everything through to the OS.

It was the managed code implementations in Framework that were non-compliant and would throw.

On the older framework implementations this should throw;

```c#
try
{
MD5 md5 = new MD5CryptoServiceProvider();
Console.WriteLine("Created algorithm");
}
catch(Exception e)
{
Console.WriteLine(e);
}

So I would have expected

```c#
try
{
    MD5 md5 = new MD5.Create();
    Console.WriteLine("Created algorithm");
}
catch(Exception e)
{
    Console.WriteLine(e);
}

to throw too. But it may be more subtle - @bartonjs for comments.

I assume you're doing something for government? Otherwise we simply don't advise FIPS compliance for anything and haven't for years.

[bartonjs]

.NET Core does not try enforcing "FIPS Approved", since that is always a context-specific concept (in particular, what date is your minimum secrecy/integrity requirement?). HTTP's Content-MD5 header isn't a FIPS concern (it's used like a CRC/parity check, not a cryptographic proof), but .NET Framework historically wouldn't let that work.

For applications .NET Framework 4.8 we changed it to match .NET Core: there's no enforcement of FIPS Approved, the FIPS bit just makes (e.g.) AesManaged skip the managed part and defer all the work to one of the native implementations.

That's not to say a library can't only use FIPS Approved algorithm combinations... but there's no systemic enforcement in the .NET Crypto stack.

[bartonjs]

we need to show some indication that we are using FIPS certified implementations in the OS.

All algorithms that .NET supports that can receive CAVP certification are implemented by system libraries. On Windows that's Windows CAPI (several libraries) or Windows CNG (ultimately bcryptprimitives.dll). On Linux we use OpenSSL... whether or not your Distro uses a FIPS Certified build of OpenSSL is up to the particular Distro and configuration thereof.

[jaredtait]

@blowdart for gov, of course :) while legitimate guidance has been around for years, it takes decades for this culture to change.

@bartonjs I only picked MD5 as it is usually what would bite us when the FIPS check was enabled. If understand you correctly, the way forward is strictly for the FIPS flag to pick the FIPS compliant implementations in a way that is not breaking. So is it true that this would not be run time testable?

Unfortunately, the "requirement" isn't for secrecy or integrity, just enforcement. Looking through IdentityServer4.Configuration.CryptoHelper, I believe there are FIPS compliant implmentations of each of the algorithms that IdentityServer is using, but what can I bring to my Information Assurance Compliance folks?

[bartonjs]

@jaredtait In .NET Framework you can ask CryptoConfig.AllowOnlyFipsAlgorithms. If it's set to true then AesManaged is backed by AesCryptoServiceProvider (https://referencesource.microsoft.com/#System.Core/System/Security/Cryptography/AesManaged.cs,cf9278a30e3e31cd). On .NET Core it's always the case that things are backed by the system implementation. There's nothing to query, it's just... always true.

[jasondavidcamp]

Can we safely say that IdentityServer4 is using only FIPS 140-2 compliant modules if hosted on a Windows server with the FIPS registry flag turned on? This seems to be the case but it would be nice to have confirmation from the security professionals that this is indeed the case.

[blowdart]

That would be for @leastprivilege to concern. .NET Core doesn't enforce anything in this regard.

[leastprivilege]

Well - not sure what to say. We are only use .NET Core provided algorithms.

SHA, RSA, ECDsa

[jasondavidcamp]

Please confirm if the following information is accurate:

• IdentityServer4 uses the following algorithms in .NET Core: SHA, RSA, ECDsa
• .NET Core defers to the platform operating system for crypto work
• If the FIPS bit is set on a Windows platform, a FIPS compliant algorithm implementation will be selected
• Windows OS contains FIPS compliant implementations for the following algorithms: SHA, RSA, ECDsa
• Therefore, IdentityServer4 only uses FIPS compliant algorithm implementations on a Windows platform if the FIPS bit is turned on

[leastprivilege]

IdentityServer4 uses the following algorithms in .NET Core: SHA, RSA, ECDsa

That's all I can confirm

[blowdart]

And I can confirm

• .NET Core defers to the platform operating system for crypto work
• If the FIPS bit is set on a Windows platform, a FIPS compliant algorithm implementation will be selected

I'm working on a docs page for this.

As for Windows OS contains FIPS compliant implementations for the following algorithms: SHA, RSA, ECDsa that's covered by https://docs.microsoft.com/en-us/windows/security/threat-protection/fips-140-validation

[jasondavidcamp]

Thank you very much! I think this is exactly what we need. I do appreciate all the help.

[blowdart]

https://github.com/dotnet/docs/pull/15870/ will be the core statement, eventually, when everyone gets what they want in there :)

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.