“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/

SP800-90A and SP800-90B compliant Linux Random Number Generator

Stephan Mueller

With the enforcement of SP800-90B starting in November 2020, the noise sources behind the Linux /dev/random, /dev/urandom and the getrandom system call interfaces must comply with all requirements stipulated by SP800-90B. If this compliance is not achieved, all modules using Linux random number generator as entropy source from its operational environment will likely fail FIPS validation starting at that time due to the lack of an acceptable noise source.

The existing implementation has difficulties in meeting the SP800-90B requirements. Not only are the health tests missing, but also the current architecture does not comply with SP800-90B section 3.1.6 as multiple similar noise software sources are credited with entropy. The interrupt noise source as well as the derivatives of interrupts of human interface device events and block device events are equally credited to provide entropy.

Our colleague Stephan Mueller has developed an API and ABI compatible replacement for the Linux random number generator implementation that provides not only SP800-90B compliance but also provides random data generated by an SP800-90A DRBG. This implies that data out of /dev/random, /dev/urandom or getrandom system call will comply with all requirements mandated by FIPS 140-2 without even needing to be processed with an additional DRBG.

The Application Binary Interface (ABI) is one step beyond the application program interface (API), which defines the calls from the application to the operating system. The ABI defines the API plus the machine language for a particular CPU family. An API does not ensure runtime compatibility, but an ABI does, because it defines the machine format

As part of the publication of the source code of the Linux random number generator replacement implementation, the full test set for performing SP800-90B compliant tests are provided. In addition, a full SP800-90B compliance assessment is provided in the documentation covering the implementation.

The source code to the SP800-90B compliant Linux random number generator implementation has been sent to the upstream Linux kernel community for assessment.
Stephan made the source code available at [1]. The test code can be downloaded at [2] and the documentation including the SP800-90B compliance documentation can be accessed at [3].

[1] https://chronox.de/lrng/lrng-20191111.tar.xz
[2] https://chronox.de/lrng/lrng-tests-20191111.tar.xz
[3] https://www.chronox.de/lrng/doc/lrng.pdf

First Commercial ACVP Testing with Regular Three-party Setup Completed

The atsec Automated Cryptographic Validation Protocol (ACVP) tool set demonstrated that ACVT is fully production-ready with the completion of the ACVP test run of 3,529 test vector sets managed by 329 test sessions. The testing marks the first successful production test run of ACVT with the three-party approach commonly used during FIPS 140-2 testing. The three parties are the vendor of the cryptographic implementation executing the testing, NIST maintaining the ACVP server and awarding the certificates, as well as the lab, atsec, interfacing with the vendor and NIST.

The successful testing was executed on a large array of Apple devices including iPhones, iPads, macOS devices, Apple watches, Apple TV devices and the embedded Apple T2 security chip. By using ACVP, the entire test round, starting from obtaining the test vectors until receiving the certificate for all these devices, took about two weeks. The old CAVS test approach would’ve taken many more weeks. The full automation of the testing significantly paid off in faster turnaround times as well as consistency of the testing. By removing the human factor to a large degree the potential for errors was minimized.

The power and versatility of the atsec ACVP test tools supported the testing. With the ACVP Proxy capability of maintaining several thousand test vectors in an offline database, testing was conducted with test beds that were not connected to the Internet. In addition, the ACVP Parser was capable of delivering tests to even the tiniest of execution environments within the Apple Watch Series 1 and the Apple T2 security chip. The ACVP Parser’s versatility provided the seamless management of tests through integration with Apple’s tooling for the three target modules identified as the User Space module, Kernel Space module, and the Apple Secure Enclave Processor (hardware module).

The development of the atsec ACVP tool set, as well as the execution of the tool set with the ACVP production servers, also helped NIST to bring ACVP into a production-ready state and to identify shortcomings in handling such a massive volume of tests.

atsec would like to thank Apple engineer Shawn Geddis, who supported the ACVP testing. Also, atsec would like to thank the NIST ACVT team for fast and professional interaction to resolve issues during the development phase.

The atsec ACVP test tools allow an immediate integration with different cryptographic implementations including cryptographic hardware. atsec is therefore the partner for you to turn your ACVP testing into a success story requiring limited effort and offering fast turnaround times.

atsec China adds PCI QPA qualification

atsec China (with the official name – atsec (Beijing) Information Technology Co., Ltd) has been qualified by the PCI SSC (Payment Card Industry Security Standards Council) as a QPA (Qualified PIN Assessor) company to perform the PCI personal identification number (PIN) security assessments according to the PCI PIN Security standard. The recent version of the standard is "PCI PIN Security Requirements and Testing Procedures version 3.0", released by PCI SSC in August 2018.

The QPA list can be found on the official website of PCI SSC:
https://www.pcisecuritystandards.org/assessors_and_solutions/qpa_assessors

The PCI PIN security standard contains a complete set of requirements for the secure management, processing, and transmission of personal identification number (PIN) data during online and offline payment card transaction processing at ATMs and attended and unattended point-of-sale (POS) terminals. 

The PCI PIN standard is intended for use by all acquiring institutions and agents (e.g. acquiring banks, service providers, key-injection facilities and certificate processors) responsible for PIN transaction processing on the payment card accounts.

PCI PIN assessment and compliance can be a mandatory validation requirement defined by individual card brands and the organizations (e.g. banks, payment service providers) in the payment industry. The PIN security assessment programs previously managed by individual card brands (e.g. VISA) have migrated to the new PCI QPA program in 2019. According to the validation requirements from the card brand VISA, effective 1 January, 2020, all PIN assessments must be performed using PCI PIN v3 and the associated PCI reporting materials. As of this date PCI PIN v2 assessments will no longer be accepted. All Visa PIN assessments must be performed by a QPA that is listed on the PCI SSC assessor website.

In addition to PCI QPA, as an accredited PCI QSA, ASV, PA QSA, P2PE and 3DS assessor and PFI, atsec China offers a full range of services to support organizations in achieving PCI compliance.

For more information about atsec’s service on PCI PIN, please visit:
http://www.atsec.cn/it-security-services/pci/en/pci-pin-security/index.html

Stephan Mueller publishes SP800-90B compliant Linux implementation of CPU Jitter RNG

NIST’s Special Publication 800-90B “Recommendation for the Entropy Sources Used for Random Bit Generation” (SP800-90B) lays out the testing requirements for random bit generators. According to Implementation Guidance 7.18, compliance to SP800-90B will be mandatory for FIPS 140-2 validations starting November 8th 2020.

Our colleague Stephan Mueller recently published an updated, SP800-90B compliant version of his Jitter RNG suite for Linux to give our customers a head-start to achieve compliance before the transition date. While the SP800-90B compliance of the Jitter RNG was reviewed by NIST, official approval is only given when the Jitter RNG is used as part of an actual FIPS 140-2 validation.

In his documentation (Section 7.4) he explains the steps a user has to follow to claim SP800-90B compliance using the Jitter RNG, thus removing the need for them to prepare their own SP800-90B analysis.

Stephan Mueller made the Jitter RNG suite available for the public:

The code for the CPU Jitter RNG can be downloaded here:
https://github.com/smuellerDD/jitterentropy-rngd
https://github.com/smuellerDD/jitterentropy-library

The documentation can be downloaded here:
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf

The associated tests can be downloaded here:
http://www.chronox.de/jent.html

atsec at the International Common Criteria Conference (ICCC) 2019

atsec participated in ICCC 2019 held in Singapore from October 1st to 3rd in conjunction with Singapore International Cyber Week (SICW).



It was the perfect venue to celebrate the 20th anniversary of the Common Criteria standard with an increase of the Common Criteria Recognition Arrangement (CCRA) membership from 27 to 31 with the addition of Indonesia, Slovakia, Ethiopia and the Philippines.

The UK updated their CCRA status from a certificate issuing country to a certificate consuming country, with continuous commitment to both the CCRA and the International Technical Communities (iTC).

As a Silver Sponsor of the ICCC 2019, atsec hosted one of four ICCC booths on the exhibition floor among the other exhibitors participating in the SICW. In addition to attending ICCC 2019, some atsec consultants also participated at the CCUF a week prior to ICCC.

atsec gave the following three presentations at ICCC.

• Mr. Michael Vogel with Ms. Terry Diaz (Cisco): iTC: General Update and TLSv1.3 integration into NDcPP
• Mr. Di Li : The Chinese Commercial Cryptography Scheme and ISO/IEC 19790
• Dr. Andreas Hohenegger: The Common Criteria and IEC-62443

During the award ceremony two customers received certificates as successful results of atsec’s evaluation work: Oracle and Qualcomm. At the same time atsec was mentioned as one of the five labs that have been licensed by the Cyber Security Agency (CSA) to be a Common Criteria Testing lab (CCTL) under the Singapore Common Criteria Scheme (SCCS).