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

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.

King Ables Celebrates 8 Year Anniversary!

A Multi-Level Model for Common Criteria Certificate Maintenance

by Trang Huynh

I had the privilege of being on a discussion panel at the NIAP Validator Workshop this past June. The topic for the panel was “Continuous Software Update,” and the issue we were trying to tackle was Common Criteria (CC) evaluations for products with a high frequency of software updates, such as those for mobility products. From the discussion, I identified that the issue is two-fold:

1. updates occurring while the evaluation is in progress, and
2. updates after the evaluation is completed.

The case of updates after evaluation completion was the focal point of the panel discussion. Many ideas were brought up during the panel ranging from delta evaluations to requirements for regression testing, full evaluations, etc.

NIAP provides Publication #6 (Pub 6) describing the certificate maintenance / assurance continuity process offered by the scheme. This document contains definitions and examples of major changes and minor changes in addition to an outline of the necessary actions from the vendors and/or CCTLs pursuing certificate maintenance. Yet it is a great challenge for vendors/CCTLs and validation bodies alike to methodically determine whether an update constitutes a major or minor change. Changes in the extreme cases are easy to classify, but cases in the middle ground can be extremely fuzzy.

To solve this difficulty with classification, I raised an idea at the panel that the certificate maintenance process offer a predefined multi-level model similar to the one offered by FIPS 140-2. At a high-level FIPS 140-2 breaks down a change into several submission scenarios or SUB for short, (1SUB, 1ASUB, 1BSUB, 2SUB, 3SUB, 3ASUB, 4SUB, 5SUB, etc.) For example, 1SUB addresses administrative or non-security relevant changes that do not affect any FIPS 140-2 security-relevant items, such as updating vendor contact information or testing the module on additional platforms, that have little or no impact on the validated cryptographic module. The 3SUB scenario encompasses changes that would exceed 30% of the module's overall security functionality. Last but not least, 5SUB is for changes that do not meet 1SUB through 4SUB requirements. This model conceivably allows CST labs more "jurisdiction" to decide on the level of the change. Based on that decision the CST lab may proceed with the “game plan” described in section G.8 Re-validation Requirements of the Implementation Guidance which may involve the CST lab performing applicable testing on the changed cryptographic module and submitting the test results (along with other required materials) to the CMVP for re-validation.

I believe an introduction of gradation of changes in the certificate maintenance process would allow for a more systematic approach for performing impact analysis on product updates.

atsec’s ACVT service is operational

atsec is proud to announce that the Automated Cryptographic Validation Testing (ACVT) service is operational.

The atsec Cryptographic Security Testing (CST) laboratory is the first ever to achieve operational status with the Automated Cryptographic Validation Protocol (ACVP) production server operated by NIST. atsec's ACVP tools are fully implemented and functional. After the test results for all types of algorithm testing offered by the ACVP server were validated by NIST, atsec’s CST lab was granted access to the ACVP production server. atsec performed the algorithm testing on its SHA and HMAC implementations used in the atsec ACVP Proxy, which is the very first ACVT project to demonstrate that the NIST ACVP production server is now in business.

With this privileged access, the atsec new service uses the ACVP production server to automate the process of testing the implementation correctness of cryptographic algorithms and related functions, and offers a much more efficient and effective process in the awarding of certificates by NIST.

Certificates of implementation correctness are awarded by the cryptographic algorithm validation program; these certificates being required as a pre-requisite for cryptographic module validation as well as for Common Criteria evaluations in the U.S.

Mr. Stephan Mueller, one of atsec’s Principal Consultants, has worked closely in the development of the client program to test the NIST ACVP demo server, which has greatly helped NIST’s successful launch of the ACVP production server. He commented on this collaboration between atsec and NIST.

“NIST is to be congratulated on this important milestone in the development of the ACVT program. A program which provides assurances in the security of IT systems implementing cryptography as well as supporting developers by providing the capabilities to test in synch with modern development timescales.”

Dr. Yi Mao, atsec Laboratory Director, also commented.

“We applaud NIST’s initiative in launching the ACVT program and are proud of assisting them in achieving this historically significant milestone. Cryptography is the hard core that provides information security. Automated testing is the way forward to sustain the high demand of the much-needed assurance at the core of security. It’s an extremely exciting moment, and empowered with ACVT, we can immediately benefit our existing and new customers by taking their algorithm validation down a fast path.”

Find out more at:
atsec’s cryptographic algorithm testing service page.
NIST’s Automated Cryptographic Validation Testing (ACVT) project.