 I will talk about the Enterprise Linux Crypto Story. I'm part of Red Hat Crypto Team, so let's go. So this is the agenda. I will give some introduction and then talk about some challenge, what we provide for Red Hat Enterprise Linux, how we choose our core crypto libraries and give a summary in there. So the introduction. Let's start with a hypothetical statement. As an enterprise system vendor, I want to have my system to customers. It must be secure, interoperable, and have high quality. But it sounds reasonable, but how to fulfill those requirements? Fulfilling these requirements are not responsibility only for the crypto part of the system. It's a shared responsibility across all system components. The crypto can't guarantee the security of the system. So in this talk, I will restrict the scope only for the crypto point of view. The challenge. How to keep the system secure? For illustration, look this padlock. It was one secure, but with time, it got rusty and needs replacement. It's not different with crypto. The definition of securing crypto changes with time. Floods and algorithms are discovered, for example, RC4 and D5 and protocols, like SSLV3 can no longer be considered secure. The threat model changes. In the past, sharing the processor with other applications wouldn't be concerning, but now we have containers, and that became much more common. And we've seen a lot of attacks, which takes advantage of this situation, like timing attacks and cash-based attacks. The computational power increases with time, which means we have to use longer and longer keys to avoid having problems, and small keys became insecure. So the crypto algorithms using the system must be updated with time. And it is necessary to have control over all crypto using the system. For the crypto point of view, the system can't be considered secure if you use any insecure algorithms more, if you use secure algorithms, but in wrong ways. Now imagine if each application brought their own crypto, we would have to fix bugs and reveal every package or application in the system. That would take unreasonable time, effectively making it impossible to ensure that only secure algorithms are used in a secure way. So having a lot of crypto implementation in the system makes it difficult to maintain a test. It's a lot of code that we have to spark and reveal. Makes it hard to control used algorithms and keys. I mean, you have to have control on the configuration of the system to make sure that all applications use only secure algorithms in a secure way. It's hard to ensure secure crypto usage. Like I said, the protocols, the key size and algorithms, they have to be secure. And so we conclude that the applications must be consistent and rely on a small set of crypto components so that we can control everything and be sure that they are safe. So, instead of having a system like this, we would like to have a system like this where the applications rely on a small set of crypto components. So, and how to ensure interpretability. If we have one application dependent on a crypto library and another application relying on different library, how can we be sure that they will work together? That's only possible if both crypto libraries implement a well-defined standard and specification. Those standards are usually defined by ITF to RFCs, things like this. So, we can make sure that they work together. And how to ensure interpretability with a legacy system. So, the system must be flexible enough to allow a configuration of the system for a more permissive, in a more permissive way, to allow it to work with legacy systems. So that we can be sure that it interprets with legacy systems. So, for interpretability, we need compliance with standard and specifications and to allow conversion for legacy systems. And how about quality? From the ease of definition, the international organization for standardization, qualities, this sentence, the totality of features and characteristics of product or service that bear on its ability to satisfy stated or implied needs. In simple words, product has good quality if it complies with the requirements specified by the client. So, a customer provides a set of requirements and inside these requirements, they have requirements for security and crypto. And from these requirements are derived validation tests. So, we take these validation tests and a crypto component and we make it go through the validation process to get a validation crypto component, a certified crypto component. So, we can use this certification to prove the complies with the set of requirements stated by the client. Obviously, that is the oversimplification of the validation process, but it works for illustration. So, if all the crypto components in the system are certified and are used in an approved way, we can say that the whole system is compliant with those requirements. But in the other way, if part of the system is not certified or used in a non-approved way, we can't say that anymore. So, we lose this compliant state of the system. So, and that doesn't work for a customer because it doesn't meet the requirements. So, different customers have different requirements. For example, the U.S. government require FIPS, the financial sector require PCI DSS and others require common criteria. So, to sell the system to these customers, it's necessary to provide the certification for different standards. So, for some standards, certification is required to prove the system compliance. In other words, certification is a way to prove the quality of the system. So, what we're providing right. We provide a core crypto components, which is a small set of crypto components and having a small set of crypto components allow us to have consistency across applications because then the applications would rely on a small set of certified and verified crypto components. It makes the attack surface smaller, which means less probability of having a vulnerability or a security issue. It also gives us less code to maintain and test. Allows to the control of the system crypto configuration like the size of the keys, the algorithms used, the protocols allowed. And that allows us to prove the security claims we make, like that the system is compliant with some requirements. So, this is a set of core crypto components we provide. It may seem a lot, but it's really a small set of the crypto components available. And these do not include all crypto related packages in rail, but these are the core crypto components. For a developer who wanted to write a new application, I would recommend to check in these first. It's important to remind that the effort made to make it secure and comply with standards and certified are pushed upstream. So, the community can enjoy the benefits of this effort. So, we provide a quality assurance to integration testing to make sure the applications and the crypto libraries work with each other and also to make sure that different versions work with each other. We use regression testing to make sure that fixed bugs don't come back and that the behavior of the system doesn't change between versions. We have standards compliance testing that's to make sure that the system is compliant and that it's certifiable. So, for example, for testing the compliance with TOS, we use TOS Fuzzer. It's a tool by our teammate, Hubert Cario, and it tests for compliance with many several RFCs. It tries to test your library from the point of view of an attacker using more formal packages and stuff like this. It's interesting. If you click that link, it will lead you to the repository. And we do testing for certification requirements for our FIPS, Common Criteria, to make sure they are satisfiable. So, different countries have different laws and regulations. So, we have to make sure the crypto components we deliver, they follow the rules of each country where we want to sell the system. So, some algorithms are restricted in some countries and some algorithms have patents that we have to make sure that we don't ship those algorithms in our system. That is verified by extensive code review to all the applications in the system which require crypto. So, that also allows us, in this code review, we can check if non-allowed algorithms are shipped or if they're non-allowed protocols inside the libraries. We also provide a crypto policies which is new in Rally Beta and Fedora. I will not go deep in this component because there is one talk. I recommend you to attend the talk from our teammate, Tomas, about the crypto policies to get more details about this. But quickly, go into the valuable profiles. The default profile is modern, secure, it removed like insecure algorithms but still have SHA-1 for usability because the word's not ready yet for the disablement of SHA-1 in signatures. Legacy profile is intent to be used for legacy systems. It allows some kind of insecure algorithms with smaller keys and filter is a more restrictive profile which uses large keys and removes SHA-1, for example. And FIPS, which is the FIPS compliant profile. So, how do we choose our core crypto libraries? One of the aspects we consider when we are choosing our core crypto libraries is the community. Like the popularity is important because if a library is more popular, it means that we have more reach, like changing those libraries would affect more people and more applications. We also consider the active contributors. Like, it's necessary to have active contributors to allow us to fix bugs, fix security vulnerabilities more quickly, to implement new features. And we work really close to upstream, so it's interesting to have a friendly upstream so that we can cooperate and contribute to fixing bugs and adding new features. And also it's important to have a friendly upstream because then we can make the changes. We have to make the library certified, for example. Because for some testing like FIPS, you need to have specialized APIs which is using the testing. So, we have to have cooperation of the upstream to make this into their library or their project. Okay. We also consider the stability of the project. The project has to have a version control system like Git so that we can track all the changes that are made, in which version they were introduced. We also require API and API stability. That is really important for long-term Spark, because that allows us to update a library without breaking the applications. So, a simple version is a way to keep the API and the API stable and to make updates that won't break the applications. So, we can update the application. Okay. We also consider the quality of the project. We consider the methods used by the project to ensure their quality. Like continuous integration is one thing that we consider really important for a project to have. And even better if they run a CI test for every change made to the code, like every push. There are many CI platforms available and most of them are free for open-source projects. Probably, you heard about Travis and GitLab CI and there are others. We also consider if the project follow best practices. As a guideline, we recommend following the best practice defined by the Linux Foundation in the Core Infrastructure Initiative. So, I put there a link. If you click there, you can see what the project has to do to get the badge. We also require the libraries to be thread safe to be able to be used in a multi-thread scenario. We require there to have compliance with standards which means implementing the specifications in the right way. For example, like I said before, we use tools like Teos Fuzer to check if the implementation is correct, like if it returns the right alerts when the error occurs and things like this. Okay, so this is all. I will give a summary, what to remember. The definition of secure encrypted changes with time. So we have to update the algorithms used and the configuration of the system with time. It's not something that will be abused, absolutely securing the crypto point of view forever. Having a small set of supported crypto components is beneficial so that we can control all the crypto usage and the crypto configuration in the system. Certification is a way to prove compliance with a set of requirements. That means that if someone requires some specification, some standard, you can provide a certified library to prove that you comply with those requirements. To prove the system compliance, the whole system must use only certified crypto and in approved ways. So if you use uncertified crypto or you use certified crypto but in the wrong way, then you can't say that your system is compliant. And various aspects are analyzed when selecting the core crypto libraries. We don't put like random stuff inside rail. We analyze and choose the most popular which have good quality and et cetera. Questions? I guess there are no questions. So thank you.