 My name is Tomas Mass and I'm a Principal Software Engineer and I work in Red Hat in the Crypto Team which is basically working on crypto for Red Hat and Brass Limits. So the topic is custom crypto policies by examples. I will first start with some motivation for crypto policies. I'll shortly talk about the crypto policies in general. Then I will talk about the custom crypto policies, especially I will show some examples almost in a kind of living demo. And I will also talk about future crypto policies. So the motivation, cryptography and cryptanalysis go hand in hand and the evolution of algorithms and crypto protocols is faster and faster. You can never think that the crypto system deployed in one year will be still good enough in the next year. We need to get used to the changes. I'm not going to go into details why is it like that because this time it's kind of obvious. What do you need to apply to the crypto-related configuration changes that are related to hundreds of machines, physical or virtual in heterogeneous environment? And you can complicate things even more because various machines might have various needs to communicate with legacy systems and devices and basically every machine cannot accommodate every change to the requirements. System crypto policies come to the rescue for this task because they are centrally managed on the system. There is a single command that controls all the core crypto libraries and applications using crypto. There are multiple pre-designed policy levels which allow you some flexibility. On the levels give you up-to-date security, but some of the levels give you communication with legacy systems and some preparation for future. The system-wide crypto policies also simplify FIPS enablement and give you a special policy for that. And where you can get them, you can get them in current TIDORAS and RANET and price levels. So centrally managed means that there is a single command that controls all the libraries. There is this command update crypto policies set and it controls all these libraries and all the applications. And the pre-designed policy levels are described here. We have legacy devices integrated with the default policy which is the default one. This list is actually for Fedora because on RANET and price levels 8, the next policy for Fedora is the default one on round 8. And we will probably do it for Fedora, for the next Fedora. The future policy is a kind of conservative policy which disables many things and you won't be probably using this level on normal system usage. But you can use it for testing whether your application is prepared for future changes. And there is a special policy FIPS which enables only FIPS to allow operators. By what to do, the predefined policy levels don't make sure that you're able to enable something that you don't want to enable or they don't enable something that you need. Custom crypto policies can help you with that. You can define your own crypto policies from scratch with a simple policy definition file format. Or you can modify even the existing predefined policy levels so you don't have to write all the policies from scratch. But you can modify existing policies by adding or removing disabled algorithms or protocols. And when are the configurations done? When actually the update crypto policies script is around. The policy can be fully defined from scratch. In this case it needs to be placed into UTC crypto policies policies or if it's in stock package it should be placed into user share crypto policies policies. The file needs to be named with name of the policy in uppercase. This is an important thing. The suffix is actually uppercase. So here is a short excerpt from user share crypto policies policies future poll which is the future policy. This is of course not the whole file. I can start with the demo. Here is just the future policy as a whole file. You can see it's like there are many different parameters and values that you can set. Most important things is that there are kind of like three types. It's a list or two types. There is a list value and simple single value. And the update crypto policies will generate the configuration file that is loaded by the libraries. And for each of the libraries it's of course different. This is how the openSSL configuration file format looks like. And for NSS it looks like this one. So this would be a kind of create the policy from scratch. If you didn't know anything about what are the values and so on. Of course you can study existing policies and update them. But there is also another possibility and that is to create the policy modifier module. These modules need to be placed into ETC crypto policies modules. And they have PMOD suffix in the name. Of course again the uppercase name for the base file name. And these modules allow you basically to depend on some base policy from the system. So I'm going to show you some examples of these modules for modifiers. This example is actually part of the crypto policies package. It disables sha1 hash and use of the hash in silencers. You can see in the format there is this minus which removes item from list. And you can see that you can disable the sha1 hash not only in general usage. But you can disable it in silencers and in separate settings. So here is the file and I'm setting it. You can see here, I'll talk about it later. But this is the syntax how you set the policy to be different with the no sha1 module. So here is the how it is called. Here is for OpenSSLConf and you can see that there is actually no difference. That's a limitation of the current backend for OpenSSL. The configuration does not really have a way to disable just sha1. You can disable it by going into higher sec level but not just by removing justice property. This is something that we are working on and fixed in future. But for NSS you can see that there is a difference because sha1 is here and sha1 has a good line. And this is for by where sha1 edit to disable lists. So it will be disabled. Another example at support for Camelia. Cypher which is off by default in all the policies that we ship. For TLS at least. This way by adding plus before the name of the algorithm, it will put the algorithm to the start of the list. And again, you can see no difference for OpenSSL because the configuration doesn't allow us enabling Camelia, the backend and NSS. Let's see Camelia here. But the NSS does not have a Camelia GCM support. Here this example differs only in that the Camelia is put as the last on the list, the last behind the name of the algorithm. You can see here, this is the previous example that the Camelia is the first, is even before as AS 256 here. And then here it will be behind AS as the last cypher. Another example is to disable all the LST protocol versions. Of course in the default policy in rail 8 or in the next policy on Fedora, this is already done. But we can do it, for example, for the default policy on Fedora or we can do it for legacy policy. You can see that this is legacy policy with no own TLS. And here you can see that the minimum protocol version is set to TLS 1.2 for OpenSSL. And for NSS similarly, TLS TLS 1.2, TLS TLS 1.2, and it was the original legacy policy configuration. Another example, we can make the future policies somewhat more usable on general internet because most of the certificates of the servers on general internet has 2K RSA keys only. And the default or the future policy has 3K minimum. So this is kind of useful if you want to try using future policy more. This is an interesting change for OpenSSL backend because it actually drops CEC level, which is free on normal future policy, but it has almost CEC level too. And this will not just allow shorter keys, but it will allow probably something else. But for NSS, which has more final grade, it will just change these minimum DH lengths. Also separate the ESA minimum, but actually in future policy the ESA is completely disabled. Another example is to allow only ECDH or ECDH with pre-shared keys for the exchange. There is a kind of missing feature that the current version doesn't allow completely overriding a particular list value in policy model. So you have to actually remove all the possible remaining values for the exchange, which are these. Again, applying it to the default policy, and it's finally useful change in the OpenSSL company, because it will definitely work like it will only enable ECDH and the other key exchanges are disabled here. So this would not work for policy modifier. This would basically just keep the existing list as is from the base policy and add these two key exchanges. This would not do what you expect. This is something that could work in future. Basically, first I set it to empty and then add back the ECDH and ECDHBS. I actually already committed this change. It's not anywhere else. So yeah, this is already summary how I can set the policy with the modifier. I can apply the modifier to any policy. There is no kind of saying that no SHA-1 can be applied only to this level. You can apply it to any policy, even to your own policy if you have some policy written from scratch. So this can be used. There will be no change because in future policy there is already no SHA-1. It would not be that useful. And you can apply multipleifiers such as here you have Kamelea is here and SHA-1 is here. So the backend configurations, as you can see, are generated when the update crypto policy script is being run. This allows good things because it allows modifying the crypto libraries and for the configuration generators in regards to the supported algorithms. And it will basically improve your configurations if you install improved crypto policies package. Even completely new backends can be added in future and the policy will be applied to them without the need to modify your policy or do some rebuilding or whatever. So example is that OpenSS backend could allow more fine grained configuration of TLS signature algorithms. It could allow different behavior in regards to SHA-1 signatures in TLS protocol versus certificate signatures. Future plans. The big item is SHA-1. We need to work on how to deprecate SHA-1 and crypto policies to do it. And we will need more fine grained backend configurations for OpenSS. TLS is already improved compared to state but was in real aid or old favor and OpenSS should fall. And there is a big item, crypto policies and data at rest because currently it applies only data in transit. I will be needing to think about this. All right, single command rule done all. Simple policy definition format. Policies are great. You can create policies from scratch or modify existing policy. And you can, the backend configurations are directly developed. So thank you. Any questions? A couple of quick ones. Are you utilizing some of the work for the FIPS kernel? There's the FIPS confined kernel. You can pass the grub option FIPS equals 1. FIPS equals 1 sets your system to FIPS mode and that's only slightly related to crypto policies. Those crypto policies allow you to actually set up the system so it changes the boot option and it will change your policy. But the policy applies to like the libraries that are FIPS validated don't necessarily have to disable the non-FIPS algorithms. For example, NSS is the example and you basically have to disable them in some configuration. On the other hand, for example, automatically disables non-FIPS algorithms in TLS if you are in FIPS mode. So just the other one I was going to ask as well is say I'm an application developer and I want to step up to the next level. So increase my crypto strength. Do you have like a, is it like a pre-sif or an audited mode where I can capture what's going on? The question is whether there is kind of like permissive mode for the crypto policies that very good like get some output. If some algorithm is violating the requirements for the set in the policy but allows it. No, there is nothing like that. That would require very good changes in the libraries. Last question. So it's hearing that everything is done properly through the tool. Is there any way to interrogate the system to get that? The question is whether there is way how to interrogate the system to find out whether the policy was like used or what was the policy used when something is using crypto. No, there is no use. One more. So is there any plan of, like the policies to present it are really nice but when your system may usually want like A plus or SSL up straight for your 10 TLS setup. So does it support, so do you have any plans to like update the, so you said like we have this compatibility default mode and all of these policies. So are you planning to also include the policies that would automatically set up the system in such a way that it behaves like very good or it supports, let's say, Windows 8 and newer or stuff like that? I can summarize the question that is there any plan for like having like more fine grained policies or whatever. Or like pretty fine, more pretty fine policies. No, there is no plans for that because it would be like very nice marriage to support. Okay, so thank you.