Meltdown Attack: 2 Years Later

by Richard Fant  

Meltdown Attack:  2 years later
In February 2017, independent security researchers discovered a catastrophic security flaw in the cache design for processors developed by Intel Corporation. After embargoing the information for almost a year while working on a fix, Intel publicly announced in January 2018 the security flaw known as the Meltdown Attack.

At a high level, the Meltdown Attack allows a user application to read data stored inside kernel level memory. In other words, it “melted down” the security boundary between the user and the kernel.

How can a user program read data stored in restricted memory?
To reduce execution time, most modern processors implement a strategy called speculative execution (a.k.a. Out of Order Execution). While the details are proprietary, the basic idea is that by looking at the history of the most recently executed CPU instructions, the processor can “speculate” what the user’s code will do in the future. In the anticipation that its prediction will be true, the processor will pre-fetch data from memory and have it ready in cache and registers for those future instructions.

If the processor correctly predicts what data an instruction will need, the data can be fetched from the cache instead of main memory. And since cache access is orders of magnitude faster than memory accesses, the overall execution time is greatly reduced. On the other hand, if a processor’s predictions about future instructions turns out to be false, the processor will simply clean up any registers and memory used in the speculation and continue execution.

This is the source of the vulnerability: the designers neglected to also clean up the “dirty” cache left behind after a failed speculation.

To illustrate this, consider the pseudo code below:

for i=1 to 100
    if (i==99) then
        break;
    else
        array [i] += array [i] * 2;

In this snippet, the processor notices that for the first 98 iterations, the “else” branch has been taken. It would be reasonable for the processor to predict that for the 99th iteration, the “else” branch will be taken once again. Because of this, the processor will pre-fetch the data at array [99] from memory and store it in cache. However, in this example, the 99th iteration in fact causes the for-loop to break out. However, the data stored in array [99] has already been stored in cache. Since the processor didn’t flush the cache after its failed speculation, the cache is now “dirty” with data that should have been removed.

How is this flaw exploited?
A sophisticated attacker could set up a program where a user level request to kernel memory could be speculatively executed by the processor. Even though the kernel would eventually reject such a request, it has been publicly demonstrated that the user program can still read the “dirty” cache even after the speculation failed and the kernel rejected the access request. This is the basis for an ongoing race-condition between the speculative execution and the rejection of the request: if the request is rejected first, then there will be no speculation. If the speculation happens first, then the cache will already be dirty by the time the rejection happens. There are several published algorithms that can speed up the speculation and delay the rejection. This leads to dirty caches happening more often.

This means a malicious programmer could read all of kernel memory by methodically exploiting this flaw, byte by byte, using a dirty cache. This attack is especially devastating because the victim wouldn’t even know the Meltdown Attack had occurred.

Who does this effect?
Speculative Execution was introduced on Intel processors in 1995. In December 2017, Intel and OEMs began releasing firmware & software fixes. The actual design flaw itself wasn’t addressed in hardware until October 2018. This means that potentially any Intel processor manufactured between 1995 and 2018 is at risk. In addition, any Intel CPU implemented in a virtual machine could also have this vulnerability.

Where are we now, 2 years later?
As of today, there have been no published reports of any successful Meltdown Attacks in the real world. This doesn’t mean these attacks haven’t happened, just that they weren’t reported (or possibly not even discovered by their victims). There have also been several variants of the Meltdown Attack discovered in the last two years which use the same flaw of a dirty cache with speculative execution.

Intel stated in October 2018 that their 9th-generation processor family would include additional protection against Meltdown. Of course, no details were provided since that could provide too much information for an attacker. Other companies like Apple and Microsoft have released applications that can determine if your processor is vulnerable to the Meltdown Attack.

Final Thoughts
Keep Calm and Carry On:  if you have an Intel processor built in 2018 or earlier, you’re probably at risk. Download any firmware or software updates that are recommended by your computer manufacturer. If your processor was built in 2019 or later, you should be safe from attacks of this kind.

International Women's Day

Happy International Women's Day to all our wonderful atsec colleagues in Europe, US and Asia.

Zen, or the Art of FIPS Certificate Maintenance

by Andreas Fabis

When we talk to our customers about FIPS 140-2 testing some questions regarding certificate maintenance frequently come up:

• “What happens to my certificate if I make changes to my module?”
• “Do I have to re-certify every single time I make a small change?”
• “What if we want to patch a vulnerability?”

There are many factors that can lead to module or platform changes: technical, business and marketing, to name a few. Navigating the rules and options of FIPS 140-2 re-certification can be challenging, and currently there are additional factors and deadlines to consider:

• The switch from FIPS 140-2 to FIPS 140-3 (mandatory after September 22nd 2021)
• The switch from the Cryptographic Algorithm Validation System (CAVS) to the Automated Cryptographic Validation Testing (ACVT) (mandatory after June 30th 2020)
• The switch from FIPS I40-2 IG 7.15 to SP 800-90B compliance (mandatory after November 8th 2020)

From a FIPS 140-2 point of view, the exact details of the re-certification process and the requirements for the different re-certification scenarios are explained in G.8 of the FIPS 140-2 Implementation Guidance (IG). This article is intended to help customers understand the practical implications of the different scenarios.

Non-security-relevant changes to the module or changes to the platform
Changes to hardware, software or firmware components that do not affect any security relevant items within the module are covered by scenario 1 (also known as a 1-SUB). Changing the module platform (for a software module) or adding a new platform to an existing module are also common scenarios for 1-SUBs. The laboratory will review the vendor’s documentation to make sure that no security relevant items are affected by either the change of module or the change of platform. In case of changing or adding a new platform, the module needs to be tested on the new platform. The lab then submits a package to the Cryptographic Module Validation Program (CMVP) that contains a letter explaining the nature of the change, the laboratory’s assessment and—depending on the changes—an updated Security Policy and/or draft certificate. Upon the approval of 1-SUB, the existing FIPS certificate will be updated to reflect the new version of the module or the new platform(s). The certificate expiration date remains the same.

Another option is to add the new platform as a vendor affirmed platform. These platforms will not be listed on the certificate itself, but in the Security Policy that is attached to the certificate listing. Vendor affirmation is not backed up by the CMVP and hence does not carry as much weight as laboratory testing and validation. It is up to the customer whether they accept a vendor’s claim that the module works as expected on the affirmed platforms.

Security relevant changes to the module
If there are security relevant changes to the module itself the submission scenario depends on the amount of changes. If the changes are relatively minor (less than 30%), scenario 3 (3-SUB) is applicable. This means that the laboratory will assess the amount and nature of the changes, then perform the applicable testing to make sure the affected security functions still work as expected. The laboratory will submit a test report to the CMVP and upon positive review a new certificate will be issued which is valid for 5 years.

Scenario 3A (3A-SUB) is specifically meant to address vulnerability patches if the vulnerability is on the official CVE list. In this case the CMVP waives the NIST fee as an incentive to vendors to patch vulnerabilities. The laboratory will perform the applicable regression testing and submit an updated test report. The CMVP will process the 3A-SUB at the speed of 1-SUB. In this case the existing certificate will be updated and the certificate expiration date remains the same.

If the amount of security-relevant change is above 30%, the module will be submitted under scenario 5 (5-SUB) which is equivalent to a new validation.

A quick summary of the most common re-certification scenarios:



What about FIPS 140-3?
Modules tested under FIPS 140-2, and their reports submitted before September 22nd 2021, once validated, will stay valid for 5 years. Once FIPS 140-3 has become mandatory, any re-validation of a module validated under FIPS 140-2 will automatically be a 5-SUB under FIPS 140-3.

Strategies
The best validation strategy depends on the business needs, development cycles and other variables and may include:

• Re-validation of major releases only
• Re-validation every 6 or 12 months (accumulate changes)
• Re-validation based on customer demand
• Re-validation to patch critical vulnerabilities

In the end the best course will be different for every organization. As a laboratory we can help you find the best solution for your particular needs.

My Experience During the COVID-19 Outbreak in China

by Yan Liu, Managing Director, atsec China

During the period of the novel coronavirus (COVID-19) outbreak in China, I, and many others, have cancelled parties with family, friends and colleagues—even during the traditional Chinese Lunar New Year. We have also decided to work remotely with atsec colleagues, customers, and partners. This gave me more time to think and learn, and I wanted to write something about my experience during this unique time.

I don’t believe that my education and knowledge can provide too much help for others regarding the current epidemic situation. The major contribution for changing the situation will be made by health organizations and centers for the control of disease.

Though there is a lot of information and many perspectives available through public media, I would like share my personal experience as well as the experience of the company just to keep a sort of public record of the event. This could also be regarded as a lesson-learned for our Business Continuity Plan, especially for other similar small professional service businesses like atsec.

1.     Safety and Health are the Only Priority
On January 26, 2020, the second day of Chinese Lunar New Year, we learned from the news of the breakout of COVID-19 in Wuhan, and that the situation was getting worse. After a conversation with a few colleagues, we informed the whole atsec China team that it would be better to work from home and reconvene after the Chinese New Year holiday, though we did not set a date when to come back to the office.

As of today, the whole atsec China team is still working from home.
We put the working-from-home plan into effect immediately, knowing that some of our colleagues still stay at their hometown in order to see their families during the Chinese new year, and it would not be safe to meet or take public transportation.

It was unknown at that moment, when life would go back to normal. At the same time we were putting our plan together, the government ordered a delay in returning to work after the New Year holiday and suggested that everyone stay home and avoid contact with others in order to better control the spread of the disease.

We are confident that the virus will be defeated, the problem is that nobody really knows how long it will take.

There were no traffic jams on the road, and no children playing in the park. Communication is mainly online.

On February 2, 2020, at 20:20 (note the sequence), a colleague suggested we take a group photo of the atsec China team in the cloud. As one colleague said, we looked serious but strong.

I then considered reporting the status of our safety to our other atsec colleagues outside China, as they might have been worried about us as well.

As I hesitated to start, we started to receive message and greetings from all our atsec colleagues around the world. The first message was from our CEO: “Please use all possible precautions. If you think you need to have all the people working from home and avoid using public transportation to come to work or customer meetings please do that.”

I assured him that our China team and families were safe at home. I also mentioned to my colleagues in other countries to please stay safe and take care, although the center of the virus outbreak was (at that time) far away from other countries.

As days go by, the team has had quite a few talks regarding the potential adjustment of scheduled
meetings.

2.     Home Office: Work remote, Work Smart!
Based on our experience and the nature of the business, working from home did not represent a major challenge. The team is used to working from home from time-to-time, though it meets regularly in the office for meetings or on-site testing.

Our policies and procedures for “working from home” needed just a slight update. All our security measures were already in place during normal operation including, but not limited to, account security management, VPN access to critical assets, encryption and decryption during communication, disk encryption, security of personal devices, and more.

No changes were required from all other colleagues from Shenzhen, Shanghai, and Guangzhou, who are already used to working remotely.

We did put off our regular face-to-face weekly and monthly meetings and moved to regular online meetings starting February 2, 2020.

During this time, we realized we miss each other.

Throughout the course of our online meetings, we shared our experiences on how to work from home more efficiently.

The following diagram, though it does not include details, represents the way we plan to work remotely.

A few members of the team would be open for video conferencing during online meetings, and even dress formally while video conferencing with customers.

An internal training server was established within atsec China in order to allow all employees to study the most recent information shared by other team members based on each person’s own schedule. We have also organized internal training and an exam for one of the recent security standards.

We used this situation as an opportunity to improve our internal methodology, tools, service level, and how we can provide assessment services to our customer efficiently (remote and/or on-site work). We have more time to improve our know-how and work on new qualifications.

From our colleagues’ reaction we all realize how confident the team is in working efficiently and securely from home, though at the same we are looking forward to being back in office soon.

3.     Industry impact
In the long term, we believe that this event will have very little impact on our industry and services. On the contrary, we think more attention will be given to security implementation, compliance, and assessment.

Public safety and security are different topics, though both use the same Chinese symbol “安全”. However, after this event, we think China and society overall will put more emphasis on topics such as: business continuity, incident (or emergency) response, compliance to regulation and standards, overall quality, and more.

In the short-term the outbreak might impact industries such as catering and tourism (hotels, airlines).
Cash flow might become an issue, especially for those small and mid-size companies which normally keep only a limited cash flow for running the business (e.g. less than three months). They might need loans in order to survive during this unique period. Things might be easier for companies which might have a better way to manage cash and have a long-term business plan. atsec China, has always managed to have a considerable cash flow and there will be not an issue.

Our business focuses only on independent security assessment and consulting services, and there will be no need for financial support from any organization. On the service side, most of our customers (e.g. payment service providers, merchants, banks, software vendors, etc.) have already started working with atsec remotely.

Although on-site work is necessary, most of our assessments and consulting services can also be provided remotely via interview, observation, and evidence examination. We have also improved our methods of working with customers via remote communications.

Normally from two to three days, up to a week, of on-site work is needed for a normal compliance assessment project. I expect a more efficient on-site communication practice could be considered after this period in order to save effort and cost for both the assessment team and assessed entities.

I have learned that most companies will probably consider reducing costs (e.g. their recruitment plan could be adjusted) in 2020. But so far few entities have considered reducing the budget for information security.

In addition, good habits of diligence and frugality are always a good thing.

4.    Face to face meetings vs Webinar
Face-to-face communication is always important in our business. atsec China planned to organize the 2020 China Payment Security Workshop in Chengdu on the 27th and 28th of March. Starting in November 2019, our team has set preparations for the event such as guest invitations, conference locations, hotel, transportation, presentations, and more.

In the middle of February, we cancelled the event and changed to an online event providing training free of charge. The first online training will be held on the 28th of February, 2020. We will provide an overview of the Payment Card Industry (PCI) security standards family, the Software Security Framework, and share our experience on PCI Data Security Standard (DSS) compliance. The next training will be on the 13th of March, 2020, with topics ranging from PCI 3DS, to PIN security and Point-to-Point Encryption (P2PE).

We have decided not to attend an industry meeting organized in Europe in the beginning of March. We are unsure whether a member of the atsec China team will be able to attend a conference later in April. I am looking forward to more face-to-face communication and meetings soon after this period.

Final Comments
We are expecting this uncomfortable situation to be resolved before summer so the atsec China team can celebrate the atsec 20th anniversary with the rest of our atsec colleagues in Europe.

Last and not least, I would like to express my appreciation for all of colleagues, family members, friends, customers, and partners who have given me support and courage during this difficult beginning of 2020. Last and most importantly, I want to take this opportunity to thank all the medical workers, who are currently helping patients, fighting the disease and protecting our health. To them I would like to express my heartfelt gratitude and highest respect.

Written by Yan Liu
Midnight, 24 February, 2020, in Beijing

New Service – eIDAS Trust Service Provider Assessments

atsec is happy to announce that we are now a licensed Conformity Assessment Body (CAB) under Electronic Identification, Authentication and Trust Services (eIDAS). eIDAS is an EU regulation on electronic identification and trust services for electronic transactions that applies as law within the whole of the EU.

Trust services include electronic signatures, electronic seals, time stamps, electronic delivery services and website authentication. Together with eID, these elements are essential for the establishment of legal certainty, trust and security in electronic transactions.

The eIDAS regulation also sets out what trust service providers need to do in order to gain qualified status, which entitles them to be listed on a trusted list and to use an EU trust mark.

In order to become a qualified trust service provide, the vendor needs to apply to a conformity assessment body (CAB) who will assess compliance against the eIDAS requirements for qualified trust service providers and qualified trust services. The CAB will then produce a conformity assessment report, demonstrating how the requirements are met and submit the resulting conformity assessment reports to the supervisory body. For example, Post and Telecom Authority (PTS) is responsible for carrying out supervisory activities under the eIDAS Regulation in Sweden.

For more information about atsec’s service for eIDAS, please visit:

https://www.atsec.se/service/eidas/index.html

“You’ve grown so much!” – atsec’s 20th Birthday

by Andreas Fabis

During my almost 20 years with the company (first as a freelancer, then as an employee) I have seen atsec grow from a small, determined group of IT professionals in a crammed room full of computers into an international company with a well-earned, excellent reputation in the IT security world.

Growing from the first baby steps to corporate adulthood comes with challenges, set-backs and opportunities to learn. I would like to share the personal lessons that have stuck with me during my time with atsec.

The atsec website from 2000-2020

1. Value your colleagues
This is maybe my biggest take-away: foster an environment where colleagues value, respect and help each other. The lack of silo mentality and the willingness to support each other makes working at atsec such a great experience. Of course, you are expected to find your own answers, but knowing that your colleagues will have your back is wonderful.

2. Value your customers
I often have the pleasure of taking the first call with a new customer. Sometimes they have little to no knowledge about the complex technical and regulatory challenges that come with a validation project. I think it pays off to take the time to explain the process and answer "dumb" questions. And I have witnessed the length we go to as a company to not just get the rubber stamp for a report, but to help the customer make their products and processes better beyond the scope of a particular project.

3. Embrace change
Our company’s work is closely tied to international standards and government bodies. Changes to standards can’t be avoided. New regulations and laws are passed, and validation bodies’ processes are updated. I learned first-hand that the way forward is for the company to change as well. Instead of trying to keep things the way they were, we adapt and work with government bodies and international communities and give our input to help shape the new way. You can’t swim against a river for long, but you can decide which shore you want to land on.

4. Stay focused
This is one of atsec’s founding principles and a lesson I learned early on. Stay focused on your core competencies and expertise - in this case IT security - even when you receive tempting offers to extend your business.

5. Grow slowly
I am generally an impatient person, so I was impressed by the patience and care atsec takes when it comes to investigating new business areas and new locations for additional offices. I learned that it pays off to be fast and agile when it comes to the daily business, but careful when it comes to company growth.

6. Be the change you want to see in the world
This lesson is good for your personal life as well. I enjoy seeing atsec do things instead of waiting for someone else to do them. From the first Common Criteria Linux evaluation to starting the International Cryptographic Module Conference: atsec often takes the step (and the risk) of trying something new or doing the thing that needs to be done.

Happy Birthday atsec!
Here's to the next 20 years (at least)!

Holiday Greetings from atsec!

(click on the image or follow this link for a special greeting from atsec)

To all of our valued customers, colleagues, friends and family we wish Happy Holidays and a Safe and Secure New Year. 

We are looking forward to working with you in the coming year. 

Regards,
your atsec team

A PCI WALK IN THE CLOUDS

November 21, 2019, Melbourne, Australia

atsec China participated in the PCI Security Standards Council’s 2019 Asia-Pacific Community Meeting held in Melbourne, Australia from the 20th to 21st of November, and also hosted a booth.

atsec’s principal consultants provided a presentation on “a PCI Walk in the Clouds.” atsec shared their experience in Payment Card Industry Data Security Standard (PCI DSS) assessment, especially the challenges and proposed solutions for assessments in a cloud environment. atsec also invited Tencent Cloud, as a cloud service provider, to share their compliance experience and data security model.

The presentation focused on two common cloud service models: cloud payment products (software as a service based) and cloud-based payment services (infrastructure as a service based). Challenges and opportunities for both models were discussed. In addition, atsec shared the “White Paper for Cloud Customer Data Security Standards Based on PCI DSS.” which was released by Tencent Cloud and atsec in July 2019, and related to shared responsibility between cloud service providers and cloud customers. The paper is a valuable resource for cloud customers selecting appropriate technical solutions to meet PCI DSS requirements.


In addition, a bamboo book (a condense version), titled “PCI Valuable Book” was demonstrated. It includes a checklist for critical security requirements in order to maintain compliance. atsec encouraged our customers to integrate their PCI DSS requirements into daily job activities. The information expressed in old books, such as the Art of Warfare written by Sun Wu in old China, could be simplified and summarized; however the impact of that short work can be huge. On the other hand, modern standards are complete and accurate in order to address all different types of situations applicable for the standard. No matter if it’s an old book or a modern standard like PCI DSS, a high quality implementation and validation assessment are always important.

Compliance and assessment processes could be viewed as “romantic dramas.” Although there could be challenges for entities doing remediation based on the security standards, finally the benefits of being compliant can be realized. Just as in “A Walk in the Clouds”, the characters in the movie are looking for true love; atsec hopes that the industry works together to get ready for changes that come with new technologies such as Cloud computing, IoT security, mobile payment, AI, etc., and seeks the true meaning of compliance and to improve overall information security.

The presentation can be downloaded at the following link:
http://www.atsec.cn/downloads/pdf/A_PCI_Walk_In_The_Clouds.pdf

atsec presented at InnoTech Austin 2019

atsec US Corporate Vice President and Lab Director, Yi Mao, presented “Crypto Testing Leading to Better Security” at InnoTech Austin 2019.

Through many examples, Dr. Mao showed the audience that cryptography is the hard core providing data confidentiality, integrity and authenticity. Cryptographic algorithms are used to encrypt sensitive data (e.g. password files), to authenticate users for physical or network access, and to digitally sign financial transactions. While the Internet of Things (IoT) gets integrated into our daily lives in an alarmingly influential way (e.g. remotely controlling home appliances) and gazillions of bytes of data are stored out of our control (e.g. cloud platforms), using cryptography for data protection is inevitable. It’s fair to say that information security can hardly exist without cryptography, but getting cryptography right is a very challenging task.

This presentation introduces the Cryptographic Algorithms Validation Program (CAVP) and the Cryptographic Module Validation Program (CMVP). The CAVP and CMVP play an important role in ensuring that cryptographic algorithms are correctly implemented and their keys are well protected within cryptographic modules through a rigorous validation process. Dr. Mao explains the U.S. NIST and ISO/IEC standards for approved cryptographic algorithms and modules to be tested against as well as the processes for getting CAVP and CMVP certificates. 

We’re currently at an exciting turning point where the CAVP will switch to an automated testing system and the CMVP will transition to ISO/IEC 19790 as the successor to FIPS 140-2—the standard used for cryptographic module validation since 2001. The presentation was concluded with a bright picture that the improvement made in the CAVP and CMVP will boost cryptographic testing, which in turn will lead to better security.

How can OpenSSL survive FIPS 140-2 validation in 2020?

by Stephan Mueller

The OpenSSL project outlined the development strategy pertaining to the Federal Information Processing Standard (FIPS) 140-2 code in the November 7^th, 2019 OpenSSL blog titled “Update on 3.0 Development, FIPS and 1.0.2 EOL.”[1] As a summary, the following relevant aspects for FIPS 140-2 are communicated.

·     The standard OpenSSL 1.0.2 will be End of Life at the end of 2019. The FIPS compliant version based on version 1.0.x is the OpenSSL FIPS Object Module 2.0.x, which is therefore also End of Life by the end of 2019.

·     The current version of the standard OpenSSL library is 1.1.1 and is considered the version with long-term support. The development team suggests that all users move to this version. The FIPS compliant version based on 1.1.1 will be the OpenSSL FIPS Object Module 3.0. However, although the standard OpenSSL version 1.1.1 has been available for some time already, the FIPS Object Module 3.0 will become available in Q4 2020 according to [1].

With this communication, there is a significant gap for users requiring a FIPS compliant OpenSSL code base between the end of 2019 and Q4 2020. This begs the question on how to bridge that gap. The following strategy outlines different approaches that could be applied to have continuous FIPS 140-2 coverage of even current versions of OpenSSL in 2020 and beyond.

One solution, which may be a challenge for a large number of customers, could be to maintain the OpenSSL 2.0.x code base further without the help of the upstream community. This would imply that at least security relevant patches added to version 1.1.1 would need to be backported. In addition, by following this approach, the Common Vulnerabilities and Exposures (CVE) list should be monitored and potentially new CVEs would need to be addressed by developing independent patches in-house. With such an approach, a user would basically create and maintain a fork of the existing OpenSSL code base. This would mean that such a user must have strong knowledge in cryptography to ensure changes do not weaken existing cipher implementations.

A more practical solution could be to switch to the OpenSSL versions made available by the Linux distributions Red Hat Enterprise Linux (RHEL) 8, SUSE Linux Enterprise Server (SLES) 15 or Ubuntu 18.04. These distributions took the OpenSSL 1.1.1 standard code base and forward-ported all FIPS 140-2 patches. The resulting OpenSSL 1.1.1 versions provided by the mentioned distributions attempt to be API (Application Program Interface) and ABI (Application Binary Interface) compatible to the standard OpenSSL 1.1.1 library and yet utlize FIPS 140-2 compliant cipher implementations. When using an OpenSSL version from these distributions, applications may hardly need any changes when they already link to the standard OpenSSL version 1.1.1. When switching to one of these distributions' OpenSSL code, the user also benefits from an active maintenance of the code base including addressing of any security-relevant or non-security-relevant bugs. Such an approach may require much less development effort than maintaining a fork of an older OpenSSL code base. Also, this approach may provide a more stable OpenSSL code base compared to maintaining a separate fork of OpenSSL.

atsec has been working with Red Hat, SUSE and Canonical for many years to have their major releases of cryptographic modules continuously covered under FIPS certification. When using the OpenSSL 1.1.1 code base provided by the mentioned Linux distributions, atsec is capable of providing Automated Cryptographic Validation Protocol (ACVP) testing out of the box since the atsec-maintained ACVP tool set covers all cipher implementations and utilizing all required APIs of these OpenSSL versions.

[1] https://www.openssl.org/blog/blog/2019/11/07/3.0-update/