OpenSSL in RHEL: FIPS-140-3 certification
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61960 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Computer wormEnterprise architecturePublic key certificateComputer animation
00:26
Boom (sailing)SoftwareContext awarenessArchitectureRevision controlStandard deviationPhysical lawCodeProcess (computing)Software testingCryptographyKernel (computing)Run time (program lifecycle phase)Series (mathematics)Patch (Unix)Internet service providerData modelMassPressure volume diagramImplementationConfiguration spaceAlgorithmGoodness of fitPhysical systemBlogPatch (Unix)Scripting languageSlide rulePoint (geometry)Link (knot theory)MereologyView (database)Information securityLibrary (computing)Public key certificateEndliche ModelltheorieRun time (program lifecycle phase)Series (mathematics)Process (computing)AlgorithmAsynchronous Transfer ModeLimit (category theory)Set (mathematics)Revision controlSoftwareCodeInternet service providerMathematicsRoutingKernel (computing)Ocean currentSource codeInterpreter (computing)National Institute of Standards and TechnologySpacetimeStandard deviationDampingConfiguration spacePlug-in (computing)Computer architectureImplementationProjective planeIterationCartesian coordinate systemGroup actionDistribution (mathematics)MassComputer fileSoftware engineeringPresentation of a groupFlow separationPhysical lawComputer animation
09:16
Internet service providerConfiguration spaceAlgorithmCryptographyMilitary operationPressure volume diagramParameter (computer programming)ConsistencyStandard deviationPoint (geometry)ImplementationCurveBitStandard deviationCombinational logicMathematicsSlide ruleFunctional (mathematics)View (database)Price indexCategory of beingHash functionInformation securityAlgorithmEndliche ModelltheorieInternet service providerCartesian coordinate systemRevision controlSoftware testingConsistencyRSA (algorithm)Semiconductor memoryEncryptionCryptographySoftware developerPublic key certificateRandom number generationPatch (Unix)Electronic signatureAsynchronous Transfer ModeLibrary (computing)Computer filePublic-key cryptographySoftware maintenanceKey (cryptography)PredictabilityDerivation (linguistics)Computer animation
18:06
TwitterCartesian coordinate systemPublic key certificateDistribution (mathematics)Patch (Unix)Internet service providerSeries (mathematics)Revision controlSoftware maintenanceComputer animation
21:44
Computer animationProgram flowchart
Transcript: English(auto-generated)
00:12
Hello, welcome to the Security Lab room. Next speaker is Dmitry Belyavsky. He is talking about open-cell in RAL.
00:22
FIPS 140-3 certification. Hello, do you hear me well? Yeah, looks like that. First, who am I? My name is Dmitry Belyavsky. I work in Red Hat as a senior software engineer. I also am open-cell committee since the year 2019.
00:46
And since the year 2021, I am a member of open-cell technical committee. It's a group of people that manage the project, the open-cell project from the technical point of view.
01:02
My beloved pet project is also related to open-cell. It's a Russian ghost script 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,
01:25
what are certified for FIPS in Red Hat, and the brief introduction into open-cell 3.0 architecture changes.
01:41
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.
02:02
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.
02:23
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.
02:42
So on and so forth. FIPS certification process is done by some accredited labs that get the sources from some company that pretends that the code is certifiable.
03:05
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, this, and that.
03:20
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.
03:43
And again, it provides very good recommendation from security points of view. So 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.
04:08
We in Red Hat certify our distributions for FIPS. For several versions, we usually certify our kernel and several crucial libraries, such as NSS, libgcreep, ntls, and of course OpenSSC.
04:30
We have a nice blog post explaining what we certified for route 8.
04:43
And the approach for route 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.
05:07
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.
05:21
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 explained the original patches.
05:48
So FIPS support in OpenSSL 1.1.1 series in route 8 was basically a set of patches for libgcreep and libssl, with even more invasive runtime checks.
06:03
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.
06:24
All algorithms are implemented via 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
06:41
Let's build from the same sources with compile-time checks. It's individual library, so we also simplify only this library, not libgcreep, libssl as a whole. That also simplifies the process of applying some changes.
07:01
To be sure that you are FIPS-compatible, you should use only relevant API, and it caused a massive OpenSSL API deprecation in 3.0. So if you pretend that your application is FIPS-compatible, please don't use deprecated API.
07:27
If you are a software developer, just add a warning for using deprecated API. So now, let's talk about our patches.
07:42
Upstream FIPS provider was designed to match the previous version of FIPS 140-2, and we wanted to adjust it so it would match FIPS 140-3.
08:03
Let's begin with the initialization of the library. Upstream approach implies that FIPS provider is loaded via configuration file, and the checksum, which is necessary to be sure that the provider is the same we want to use,
08:30
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.
08:44
So when we see that Red Hat-based system is in FIPS mode, we automatically load and activate the FIPS provider. We also get rid of external checksum.
09:03
We embedded the checksum into the provider, and it significantly reduces the problem when this checksum is in a separate file, or in the configuration file it can be damaged or just forgotten to copy the file,
09:24
and it causes 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.
09:47
Well, I will speak about it some minutes later, some slides later. What is the next change we implemented in our FIPS provider is indicators.
10:04
Indicators is a new requirement of FIPS 140-3 standard. We have too many algorithms, they can be combined in too many ways,
10:20
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.
10:43
The implicit indicators implies that if you perform the crypto operation, succeeded, then you are on the safe side. Unfortunately, as I mentioned before, some combinations of permitted crypto algorithms,
11:06
crypto primitives, are not permitted by FIPS as a whole. So we had to partly switch to explicit indicators. The approach with explicit indicators is you try a crypto operation,
11:20
if you failed, assuming it was properly set up, then it wasn't approved. If it succeeded, then you probably, it's well-documented, should check the indicator and see if it's permitted from the FIPS point of view.
11:40
Well, this approach is better from several points of view. First, it covers the caveats when you have a legal combination, and second, well, in real-life software, you can use FIPS non-approved crypto algorithms
12:04
for non-cryptographical purposes, such as MD5 has a fast enough hash sum of files. So application knows better what is the purpose of the algorithm usage sometimes.
12:28
So we implemented some combination of explicit and implicit indicators. Some more implementation details. Well, we removed Edward's curves from our provider.
12:45
It was done because when we were tuning our provider, Edward's curves were not permitted for usage in FIPS, but, well, the news of yesterday, the standard that allowed using Edward's curves,
13:05
the curve 25519 and the curve AD448 are permitted, so we probably will have to consider if we switch these curves on or we'll switch it in some upcoming versions
13:22
because there is much interest to these curves. We also removed support of RSA-PCS1 encryption in FIPS provider, which is potentially breaking changes, and we are aware of some of our applications
13:40
that have had to change the RSA encryption model from PCS1 to OIP. Triple death support from FIPS provider. One more change we had to implement, also a requirement of new FIPS standard,
14:05
is switching to no-answer tests for ECDSA signatures. ECDSA signatures require using a random number, so every new signature has a different value if you properly implemented the algorithm.
14:28
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.
14:46
So we had to add a patch that allows in the test mode specifying a well-known, a hard-coded random value just for test purposes. We know that Upstream, in its upcoming version of the provider,
15:05
uses a different approach. They use the predictable random number generator, and probably it's a better approach.
15:21
We will think about it on summary spin of our certification. Also, a new standard implies some more strict changes for key derivation functions. It limits seeds. You should not use seeds shorter than 112 bits for most of the KDF functions.
15:47
And also, it specifies some requirements to accept the random number generators, which were not implemented in the upstream provider.
16:04
So only SHA-2 functions are basically allowed for the hash-based random number generators, and our providers support these requirements. One more change worth mentioning is that according to FIFS 140-3 requirements,
16:22
it's necessary to clean up memory not only after using private keys, but also for public keys, and there should be consistency checks for freshly generated public keys from private keys.
16:43
And the last two points are about other patches in RHEL that are not related directly to FIFS. They are about overall hardening. We have implemented so-called cryptopolicies in RHEL 8.
17:01
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 FIFS 140-3 standard allows using SHA-1 for signatures,
17:31
we removed the support of it in our FIFS provider because you can't really rely on security properties of SHA-1.
17:43
And it may cause problems to application developers, and some application developers have already complained about it, but please don't use SHA-1 for signatures.
18:03
It's just insecure. Thank you. Thank you for your invitation. Feel free to ask questions about the details.
18:24
Hey, so you said you're using the provider API for the FIFS stuff. Now, what I was wondering, not all of the OpenSSL API gets routed through the provider, right? So what are you doing about packages like SSH that are using old API?
18:41
Those don't work with FIFS, right? Well, yes, not all the applications use the new API. I correctly understand your question. Well, my question is, to use that, I need to use the new EVP underscore API, right? Well, yes, you need to use EVP underscore API,
19:04
but it's, well, I don't think that 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 OpenSSL.
19:22
We are writing OpenSSL downstream to use the new API to make it FIFS compatible. Oh, yeah, that's what I wanted to know. Thanks. In which of your Red Hat distribution are you supporting this?
19:41
And I guess you don't have backwards compatibility with older applications for OpenSSL. It only works with FIFS compliant applications, right? Sorry? Which of your Red Hat distribution supports the FIFS standard, one?
20:02
And two, how do you do with backwards compatibility because I guess applications that are not FIFS compliant won't run with your OpenSSL API? So, I'm talking now about RHEL 9 series,
20:21
but we have certificates for RHEL 8 series for previous version of the standard. About the applications that use old API, well, as I mentioned before, it's a common approach to provide downstream patches
20:42
and push these patches upstream to make the application use the new API. Is the only possible way? Well, I participated in pushing libFIDO2, for example. We have downstream patches for OpenSSL, but it also should be libres compatible and it adds problem.
21:08
But the general approach is implement a downstream patch and push it upstream. Okay, any other questions? Hands up, no one?
21:23
Okay, thank you very much. Feel free to contact me directly.