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