FIPS 140-2 certification status for .NET Core Crypto?

[SidShetye]

@bartonjs @karelz : what's the FIPS 140-2 certification status for .NET Core Cryptography? On Windows it would seem that the standard windows FIPS certificate would simply pass through just as it does with .NET Framework. Can this be confirmed?

Is there any guidance on Mac/Linux? On linux if the system's OpenSSL binary is swapped out for an FIPS 140-2 openssl variant, will .net simply pick that automatically?

Govt use case. Thanks.

[bartonjs]

That's the idea, yeah. It's why we use system crypto libraries and don't bundle anything. I can't speak authoritatively, but I can speak to the shape of things. @leecow Do we have anything official here?

---

Unofficial statements

For .NET Core 2.0+ we use Security.framework on macOS; on Linux we use a system provided libcrypto.so.1.0.0 (and libssl.so.1.0.0), which may or may not be a FIPS build, and may or may not be certified for the specific distro version and hardware.

On macOS using RSAOpenSsl / DSAOpenSsl / ECDsaOpenSsl / ECDiffieHellmanOpenSsl use OpenSSL, not Security.framework, and so those may not be valid for use even when RSA.Create() and friends are.

It's up to the caller applications to ensure that only FIPS-approved algorithms are being used (e.g. we don't throw in .NET Core when you want to use MD5, but maybe you're doing Content-MD5 and not something to which FIPS applies).

[adammulroy]

Are there any hooks in place in the runtimeconfig.json or another location to ignore FIPS policy if it's enabled like there was in the .NET Framework?

See below for example on how we could ignore it in the exe.config before.

<configuration>  
    <runtime>  
        <enforceFIPSPolicy enabled="false"/>  
    </runtime>  
</configuration>  

[bartonjs]

@adammulroy No, because FIPS policy enforcement doesn't exist at all in .NET Core.

[leecow]

Nothing 'official' that would add to what Jeremy has already described.

[SidShetye]

Thanks guys, that helps for initial planning. Currently Trust Center and a few other places point to this technet article. Is there a plan to formally publish FIPS information in collaboration with Mike Grimm (Microsoft FIPS program) or Trust Center folks? Given the documentation heavy slant to the certification and compliance processes, I think it'll eventually be needed.

[danmoseley]

@bartonjs seems no work here is planned for 3.0 and this should move to Future?

[bartonjs]

Since we've also gotten rid of FIPS enforcement in net48 (by default) we probably want to update any documentation that mentions the enforceFIPSPolicy setting from netfx.

We possibly also need to write somewhere that our FIPSiness is inherited by the system FIPSiness for Core.

So we can call it 3.0 documentation or Future documentation, whatever you like. (Now that I've fixed it to say it's documentation)

[SidShetye]

@bartonjs @danmosemsft : Is there now authoritative, documented guidance on this from Microsoft? This has to be covered somewhere ... we really can’t be the first US Govt project using .NET Core.

Anyway, we now need this guidance soon.

[danmoseley]

@blowdart do you have anything here?

[blowdart]

@SidShetye What exactly do you need? I can get a page on the docs site saying .NET Core has no FIPS checks because we rely on the underlying OS. Or does it need something in formal wording somewhere central?

[SidShetye]

@blowdart Basically two audiences.

Compliance folks

Need authoritative documentation from Microsoft that we can point them towards. Items like:

1. That .NET Core doesn't perform any crypto whatsoever within itself - all operations are delegated to the underlying native OS cryptographic providers.

2. Captures steps necessary to get OS + .NET Core + App combination aligned for FIPS 140-2 compliance. I think this is not a done deal because OpenSSL is FIPS compliant through a supplemental binary called the "FIPS canister" which calling apps (= .NET S.S.C. ) have to init in a particular way. Specifically, the OpenSSL FIPS' Security policy , it states

The calling application enables FIPS mode by calling the FIPS_mode_set() function

It's unclear if .NET Core System.Security.Cryptography is actually doing this on Linux.

Sysadmins, Dev-Ops

An actionable, technical walk-through we can point them towards so they can positively verify that the OS + .NET Core + App code combination is indeed valid. Windows Server and Linux are important production targets. Given the varying sysadmin procedures across Linux, a representative snapshot covering just RHEL/CentOS and Ubuntu would be sufficient.

[blowdart]

Certified documentation is asking me to prove a negative in a way that;s legally binding.

This is going to take some research and lawyers.

As an aside FIPS on OpenSSL can be OS wide with an environment variable, that's the approach we expect people to take. We don't pass anything down at all, we defer to the operating system configuration.

[SidShetye]

@blowdart I'm not a lawyer, but it's just an official statement (vs for e.g. assuming additional liability during a new contract). So as long as there was reasonable diligence (vs for e.g. speculative assumptions or intentional negligence), it should fall in line with standard business error-and-omissions disclaimers.

I went ahead and removed the work 'certified' from my prev comment for clarity since only "FIPS-140-2 certification" will arise from the crypto providers and their NIST FIPS compliance certificates; not .NET Core crypto if it's indeed all pass-through. So what we'd need from Microsoft is just authoritative guidance formally documenting that pass-thru blessing by saying

• "this is why .NET Core customers are in FIPS-140-2 certified mode" (for compliance folks) and
• "this is how .NET Core customers configure (whatever) to be in FIPS 140-2 certified mode" (for sysadmins/devops)

I think this info is sprinkled across github comments and source; as .net core customers we need your help to compile it into concise, cohesive document that we can point our own customers to.

[SidShetye]

Also, the OPENSSL_FIPS environment variable you pointed to does indeed toggle it, thanks. Here is the console result when I quickly audited FIPS mode on CentOS 7.6 (md5 vs sha256)

[sid@lab-linux22 ~]$ rpm -q centos-release
centos-release-7-6.1810.2.el7.centos.x86_64
[sid@lab-linux22 ~]$ export OPENSSL_FIPS=1
[sid@lab-linux22 ~]$ openssl md5 .bashrc
Error setting digest md5
139991007758224:error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips:digest.c:256:
[sid@lab-linux22 ~]$ openssl sha256 .bashrc
SHA256(.bashrc)= 898ed3bdcb749c665866ee2750ab50d7ac5da6b666546fcd952cfc4cbc0c33b4
[sid@lab-linux22 ~]$

[tomato42]

Speaking with my Red Hat fedora on:
The openssl package in CentOS is not FIPS certified. If a module is not listed on NIST CMVP page then it is not certified.

A correct use of FIPS module also requires for it to be used in Approved mode of operation, as specified in its Security Policy. For example, the certificate for RHEL-7 version of OpenSSL is 3538 and it's corresponding Security Policy. For this module, it's not sufficient to set the environment variable for it to considered to be working in Approved mode.

Also please note that the Security Policy specifies which interfaces are certified – not all interfaces have to be certified, and non-certified interfaces do not have to be disabled when the module is working in Approved mode. I'm noting that as the openssl md5 command does not use the approved interface in all versions of the library.