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).

CST Newsletter and FIPS 140-3 Change Summary

We invite you to take a look at our CST Newsletter.

This newsletter is intended to inform our customers about recent changes within the Implementation Guidance and NIST's Cryptographic Module Validation Program (CMVP).

We also included a high-level summary of changes to the testing and documentation that FIPS 140-3 will introduce.

atsec adds Singaporean Common Criteria Scheme accreditation

atsec is pleased to announce that it has been licensed by CSA to be a Common Criteria Testing lab (CCTL) under the Singapore Common Criteria Scheme (SCCS).

Please check the Common Criteria Portal:

https://www.commoncriteriaportal.org/labs/

as well the Singapore Common Criteria Scheme:

https://www.csa.gov.sg/programmes/csa-common-criteria/cc-atl

atsec is already operating Common Criteria labs under BSI Germany, US NIAP, CSEC Sweden and OCSI Italy.

Adding Singapore to the list of Common Criteria laboratories offers our customers an opportunity to identify and satisfy requirements coming from the region, and also be closer to customers already present and operating in the region.

Evaluations under the Singaporean Scheme will be Protection Profile based as well as using EAL1 to EAL5 assurance levels.