Hello, welcome to the security lab room.
Next speaker is Dimitri Beliapsky.
He is talking about Open cell in RAL, FIPS 140-3 certification.
Hello, do you hear me well? Yeah, looks like that.
First, who am I? My name is Dimitri Beliapsky.
I work in Red Hat as a senior software engineer.
I also am Open cell committer since year 2019 and since year 2021.
I am a member of Open cell technical committee.
It's a group of people that manage the Open cell project from the technical point of view.
My beloved pet project is also related to Open cell.
It's Russian ghost-crypt implementation.
Okay, let's go to the topic.
First, what we shall speak in the first part is
what's FIPS? What's FIPS certification?
What certified for FIPS in Red Hat?
And the brief introduction into Open cell 3.0 architecture changes.
So, FIPS is a set of standards, American national standards
requiring which cryptography and in which limitations should be used.
It consists of a series of documents.
Some documents are available public.
Some should be bought in the NIST.
Some should be bought in the ESO.
These documents are permanently updated.
So, you should consider the FIPS set of documents well as a code of laws.
It is as consistent as code of laws.
It leaves some space for interpretation.
Nobody knows it all, so there are always discussions
how to interpret this or that point of the document.
So, FIPS certification process is done by some accredited labs
that get the sources from some company that pretends that the code is certifiable.
They do quite comprehensive tests.
Some of them are public, some of them are not.
Then they return back to us with notes like you should fix this and that.
Then we go to the next iteration.
And at the end of the process, if we are lucky, we get the FIPS certificate.
FIPS certificate is necessary for using system in many American government institutes
for many big customers.
And again, it provides very good recommendation from security points of view.
If you use FIPS certified software, it means that you are on the safe side from the security point of view.
Current version of the standard is FIPS 140-3.
We in Red Hat certify our distributions for FIPS for several versions.
We usually certify our kernel and several crucial libraries such as NSS, LibreCrypt,
NUTLS and, of course, OpenSSL.
We have a nice blog post explaining what we certified for Rallot 8
and the approach for Rallot 9 will be basically the same.
It's still ongoing process.
So sorry, it's always a problem how to properly add a link in the presentation.
I believe that you can download the presentation from the slide or just find the blog post by the title.
The support of FIPS in OpenSSL has a long history.
It has native support in 1.0 series of OpenSSL, which is currently long out of support.
In 1.0 series, there was a set of invasive runtime checks if we are in FIPS mode,
then please do that.
This algorithm is allowed, this is not, and so on and so forth.
Upstream did not provide native support in 1.1.1 series,
but we in Red Hat expanded the original patches.
So FIPS support in OpenSSL 1.1.0 series in Rallot 8 was basically a set of patches
for LibreCrypt and LibreSSL with even more invasive runtime checks.
In OpenSSL 3.0, the upstream decided that the model with invasive checks is badly maintainable,
and they redesigned architecture from scratch and created so-called provider models.
All algorithms are implemented, they are separate plugins named provider,
and one of these providers, the most important for our purpose is the FIPS one
that contains only FIPS compatible algorithms that build from the same sources
with compile time checks, its individual library.
So we also certify only this library, not LibreCrypt, LibreSSL as a whole
that also simplifies the process of applying some changes.
And to be sure that you are FIPS compatible, you should use only relevant API,
and it costs a massive OpenSSL API deprecation in 3.2.
So if you pretend that your application is FIPS compatible, please don't use a deprecated API.
If you are a software developer, just add a warning for using a deprecated API.
So now let's talk about our patches.
Upstream FIPS provider was designed to match previous version of the FIPS 140-2,
and we wanted to adjust it so it would match FIPS 140-3.
Let's begin with the initialization of library.
Upstream approach implies that FIPS provider is loaded via configuration file,
and the checksum, which is necessary to check to be sure that provider is the same we want to use,
is a part of this configuration file.
This approach was found suboptimal for our purposes,
because we can detect that the system as a whole is in FIPS mode.
So when we see that Red Hat Base system is in FIPS mode,
we automatically load and activate the FIPS provider.
We also get rid of external checksum.
We embed the checksum into the provider,
and it significantly reduces the problem when the checksum is in a separate file or in a configuration file.
It can be damaged or just forgotten to copy the file,
because, well, unpredictable diagnostics.
So when you have checksum embedded into the provider,
everything is much simpler from a maintainability point of view.
And also we removed several algorithms from the FIPS provider.
Well, I will speak about it some minutes later.
What is the next change we implemented in our FIPS provider is indicators.
Indicators is a new requirement of FIPS-140-3.
Standard. We have too many algorithms.
They can be combined in too many ways,
and not all of the combinations are approved.
So we should use only approved combinations.
First, well, there are two possible approaches.
We call it implicit indicators and explicit indicators.
The implicit indicators implies that if you performed a crypto operation and it succeeded,
then you are on the safe side.
Unfortunately, as I mentioned before,
some combinations of permitted crypto algorithms,
which are not permitted by FIPS as a whole,
so we had to partially switch to explicit indicators.
The approach with explicit indicators is you try a crypto operation.
If you failed, assuming it was properly set up, then it wasn't approved.
If it succeeded, then you probably, it's well-documented,
so you should check the indicator and see if it's permitted from the FIPS point of view.
Well, this approach is better from several points of view.
First, it covers the caveats when you have a legal combination.
Second, well, in real life software,
you can use FIPS non-approved crypto algorithms for non-cryptographical purposes,
such as MD5 as fast enough hash sub-off files.
So application knows better what is the purpose of the algorithm usage sometimes.
So we implemented some combination of explicit and implicit indicators.
And some more implementation details.
Well, we removed the AdWords curves from our provider.
It was done because when we were tuning our provider,
AdWords curves were not permitted for usage in FIPS,
but, well, the use of yesterday,
the standard that allowed using AdWords curves,
two-five-five-nineteen-and-curves-cove-a-d-448, are permitted.
So we probably will have to consider if we add it,
if we switch these curves on or we'll switch it in some upcoming versions,
because there is much interest to these curves.
We also removed support of RSA-PXS1 encryption in FIPS provider,
which is potentially breaking changes,
and we are aware of some of our applications that have had to change the RSA encryption model
from PXS1 to OAP.
And we removed the triple-desk support from FIPS provider.
One more change we had to implement,
also a requirement of new FIPS standard,
is switching to no-nonset tests for ECDSA signatures.
ECDSA signatures require using a random number,
so every new signature has a different value
if you properly implement the algorithm.
If you use the same random values for the signature,
it means the attacker will be able to find out your private key,
so it's dangerous.
So we had to add a patch that allows in the test model
specifying a well-known hard-coded random value just for test purposes.
We know that upstream, in its upcoming version of the provider,
use a different approach.
They use the predictable random number generator,
and probably it's a better approach.
We will think about it on some respinoff of our certification.
Also, new standard implies some more strict changes
for key derivation functions.
It limits seeds.
You should not use the seeds shorter than 112 bits
for most of the key derivation functions.
Also, it specifies some requirements
to accept the random number generators,
which were not implemented in the upstream provider.
So only SHA2 functions are basically allowed
for the hash-based random number generators.
Our providers support these requirements.
One more change worth mentioning is that
according to 5th 140-3 requirements,
it's necessary to clean up memory not only after using private keys,
but also for public keys.
There should be consistency checks
for freshly generated public keys from private keys.
The last two points are about other patches in REL
that are not related directly to FIPS.
They are about overall hard-diving.
We have implemented so-called cryptopolicies in REL8.
It's a way to ensure that all the crypto libraries
and all the applications using these crypto libraries
are consistent from the point of view of algorithms
that are permitted to use.
Also, as FIPS 140-3 standard
formally allows using SHA1 for signatures,
we removed the support of it in our FIPS provider
because, well, you can't really rely
on security properties of SHA1.
And it may cause problems to application developers
and some application developers
have already complained about it.
But please don't use SHA1 for signatures.
It's just unsecure.
Okay, thank you. Thank you for your invitation.
Feel free to ask questions about the details.
APPLAUSE
Hey, so you said you're using the provider API
for the FIPS stuff.
I was wondering, not all of the OpenSSL API
gets routed through the provider, right?
It's why doing about packages like SSH
that are using old API?
Those don't work with FIPS, right?
Well, yes, not all the applications use the new API.
I correctly understand your question.
My question is, to use that,
I need to use the new EVP underscore API, right?
Well, yes, you need to use the EVP underscore API,
but it's, well, I don't think you should call it new
because it exists for more than 10 years.
That's right, but OpenSSL does not use that?
Yes, it's my pain as a maintainer of OpenSSH.
We are writing OpenSSL in downstream
to use the new API to make it FIPS-compatible.
Oh, yeah, that's what I wanted to know. Thanks.
In which of your Red Hat distribution are you supporting this?
And I guess you don't have
backwards compatibility with older applications
for OpenSSL.
It only works with FIPS-compliant applications, right?
Sorry? Again.
Yeah. Which of your Red Hat distribution
supports the FIPS-standard one?
And two, how do you do with backwards compatibility
because I guess applications that are not FIPS-compliant
won't run with your OpenSSL API?
So, I'm talking now about REL9 series,
but we have certificates for REL8 series
for previous version of the standard.
About the application that uses old API,
well, as I mentioned before,
it's a common approach to provide downstream patches
and pull these patches upstream
to make the application use the new API.
This is the only possible way.
Well, I participated in pushing libfido2, for example.
We have downstream patches for OpenSSH,
but it also should be libres compatible,
and it adds problem.
But the general approach is to implement a downstream patch
and push it upstream.
Any questions?
Hands up. No one?
Okay. Thank you very much.
Feel free to contact me directly.
Thank you.