You Raise Me Up - ICMC 2020

It has become an atsec tradition to produce an animation with an FIPS-relevant topic for the ICMC. This year it has the transition from FIPS 140-2 to FIPS 140-3 as the subject - with a personal touch.
Yi Mao presented the animation during her opening speech at the virtual ICMC 2020.

CST Newsletter September 2020

We invite you to take a look at our current newsletter that contains information on algorithm transitions, updates to the FIPS IG and announcements for FIPS 140-2 and FIPS 140-3.

Transitioning to NIST SP 800-56A Rev3: what you need to know

by Swapneela Unkule

NIST SP 800-56A provides recommendations for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. Diffie-Hellman (DH), Elliptic Curve DH (ECDH) and Menezes-Qu-Vanstone (MQV) key-agreement schemes are specified in this standard. These Key-Agreement Schemes (KAS) are widely used in network protocols such as TLS.

The SP 800-56A has been revised twice since its initial publication in January 2007.  SP 800-56A Rev2 was published in May 2013 to allow the use of additional key derivation functions (KDF) documented in SP 800-135 and SP 800-56C. SP 800-56A Rev3 was published in April 2018, which introduced “safe-prime” groups and moved all of the key derivation functions to SP 800-56C.

The Cryptographic Module Validation Program (CMVP) have been encouraging the vendors to implement SP 800-56A compliant key-agreement schemes, but have not yet mandated the compliance. The long standing FIPS 140-2 Implementation Guidance (IG) D.8 permits six (6) different scenarios of key agreement, ranging from a fully SP800-56A compliant KAS, to a compliant component such as Shared Secret Computation (SSC) or KDF, or a totally non-compliant key agreement method. The CMVP have been generously allowing the use of all methods as described in the six scenarios in the FIPS mode of operation. It has been in discussion for years that this would change at a certain point. The questions of when to change and how to change have been the topic for the Cryptographic Security Testing (CST) lab managers’ meeting for years.

On August 12, the IG D.8 was updated with the transition plan to SP 800-56A Rev3. The recent CST lab managers’ meeting on August 26 confirmed the enforcement of SP 800-56A Rev3 compliance. The CMVP finally pulled the trigger to tighten up this loose end by a two-phase approach.

Starting January 1st 2021, all new and updated FIPS submissions will need to be NIST SP 800-56A Rev3 compliant, if KAS or SSC is claimed in the FIPS approved mode. Vendors will have one year to address the SP 800-56Ar3 compliance requirement for already validated FIPS modules. Vendors may update the module’s Security Policy by removing any claim about KAS or SSC from the FIPS approved mode, or get the required CAVP certificate(s) for KAS, SSC and KDF and add required self-tests. Please see the table at the end of this article for the summary of the required CAVP certificate(s) and self-tests in details. Note that submissions under FIPS 140-2 are only allowed up to September 2021.

On January 1st 2022, validated modules affected by IG D.8 that have not been updated to either reflect the SP 800-56Ar3 compliance or to remove all the claims of compliance to earlier versions of SP 800-56A in the FIPS approved mode, will be moved to the Historical List. Being listed on the Historical List implies that “the referenced cryptographic module should not be included by Federal Agencies in new procurements. Agencies may make a risk determination on whether to continue using this module based on their own assessment of where and how it is used.”

FIPS 140-2 IG D.8 specifies two scenarios (X1 and X2) that can be claimed as approved key agreement methods past December 31st 2021, apart from the RSA based key agreement scheme. Scenario X1 includes compliance to SP 800-56A Rev3 either by implementing just the shared secret computation or the complete key agreement scheme. Scenario X2 corresponds to the use of the ECC scheme based on non-NIST-recommended Elliptic Curves.

The new revision of IG D.8, published on August 12th 2020,  requires self-tests of the underlying security functions and the appropriate assurances, as required in section 5.6.2 of SP 800-56Ar3 as shown in the table below. The CAVP testing for SP 800-56A Rev3 SSC and KDF is currently available. The testing for the complete KAS is planned to be available by the end of September.

 FIPS 140-3 Annex D (NIST SP 800-140D) only recognizes SP 800-56A Rev3 as the standard for FIPS approved and NIST recommended Key-Establishment Schemes Using Discrete Logarithm (i.e. Key Agreement Schemes). FIPS 140-2 D.8 will be carried over to FIPS 140-3 IG as D.F Key Agreement Methods.

We urge vendors to start implementing the SP 800-56A Rev3 compliant KAS and the required self-tests in IG D.8 as soon as possible if they need KAS to be used in the FIPS mode.

For the details of the differences between different revisions of SP 800-56A, please read this white paper.

References:

• FIPS 140-2 Implementation Guidance 
• Special Publication 800-56Ar3

atsec's 20 Year Anniversary

 

It was the beginning of January when I first heard about the new virus causing severe flu-like symptoms, such as upper respiratory infection, spreading throughout China.  I started to worry about our China team.

Nevertheless, we continued to plan for the global celebration of atsec’s  20th anniversary, assuming the virus would go away by Spring.

By the Chinese New Year at the end of January, China had issued a stay-home order and forced a complete lockdown of the city of Wuhan. It was clear that we were dealing with something much more significant than the flu. The word pandemic, almost unheard-of until that time, entered our commonly spoken vocabulary.

Slowly, but inexorably, it became clear that all of our plans for the 20th anniversary celebration would need to be postponed. By the end of February, we canceled all of our participation in conferences and customer visits around the world.

In February, as the pandemic evolved and we learned more about the COVID-19 virus, I asked Yan Liu, head of atsec’s China operation, to write a blog about the experience of the team in China, which can be viewed at the link below:
https://atsec-information-security.blogspot.com/2020/02/my-experience-during-covid-19-outbreak.html

At that time, most of the world was still relatively "safe." By the end of February, Italy, where atsec has an operation in Rome, was experiencing the second-worst outbreak of COVID-19, after China. Slowly thereafter Germany was affected, and also Sweden.

By mid-March, I requested that the Austin team begin to work from home. One or two colleagues were as worried as I was, but the majority still thought it was an excessive measure. Austin, and Texas overall, was still mostly unaffected. The rate of infection was very low, with only one person reported as positive.

Learning first from the experience in China, and then Italy, I decided to take an overly-cautious approach.

As we all sheltered and worked at home, we did not want to travel to celebrate atsec’s 20th anniversary, as planned for the end of July to the middle of August. Instead, we chose a day a month before the first planned event in Europe, which coincided with one of our dear colleague's birthday on June 29th.

 

At 8:00 am CDT on June 29th, we kicked off atsec’s 20th anniversary celebration.

 

 

Each operation introduced our colleagues at that location. The most emotional part of the whole event was seeing everyone’s faces and hearing everyone's voices.  Meeting face to face would have been a completely different experience, but meeting everybody virtually was equally moving.
The meeting ended with a clip available on our media folder at our web site:
https://www.atsec.com/media/atsec-2020/

I want to thank everybody who has participated in growing atsec into what it is today. I would like to thank everyone who is presently with atsec, and also many colleagues who worked at atsec in the past. Each one has contributed, in their own way, to the incredible success story of atsec. Finally, pictured here are some of the gifts and items shared during that day.

Though not quite the same as being together in person, it was close enough to feel and share our global celebration.

 

 

 

atsec leading in Automated Cryptographic Validation Testing

With the sunset of the Cryptographic Algorithm Validation System (CAVS) at end of June 2020, algorithm testing for NIST and NIAP validations and evaluations must now be performed using the Automated Cryptographic Validation Testing System (ACVTS).

The list of issued CAVP certificates using ACVTS (i.e. the certificates prefixed with "A") illustrates that atsec is clearly in the leading position to help our customers obtain these certificates.

While 554 CAVP certificates prefixed with "A" have been issued [1], only 50 of those certificate requests have not been submitted by atsec. Thus more than 90% of all CAVP certificates resulting from ACVTS issued by NIST to date have been obtained by atsec on behalf of our customers. On top of that, NIST bundles multiple tests on different operational environments for the same module within one certificate. A large number of the certificates obtained by atsec demonstrates the complexity of having multiple different operational environments.

Therefore, when considering the amount of conducted testing, atsec is responsible for far more than 90% of all automated cryptographic algorithm testing.

With the full automation now in place, customers are able to receive new certificates or updates to existing ones - including new operational environments - in as little as one day. This ensures that the algorithm testing is less of a project risk.

[1] As of July 23 2020: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?searchMode=validation&family=1&productType=-1&ipp=25

Bye bye, CAVS tool, old friend...

Dear CAVS Tool,

we want to congratulate you on years and years of dedicated service. Without you, algorithm testing would not have been what it is today, and we salute you for staying with us for so long.

On June 30th you will finally get your well-deserved retirement. Rumors are you will relocate to a server farm in Iowa to work on your true passion: four-dimensional Mandelbaum topology.

But the CAVS Tool would be nothing without the people behind it; so we would like to give our thanks to Janet Jing and the whole CAVP team, for tirelessly processing mountains of submissions as well as update/change requests, and keeping the CAVS Tool running.

Dear CAVS Tool, now your replacement, the ACVTS, has been trained and is ready to step into your big shoes.

Good bye, old friend, we wish you all the best,
Your atsec CST team

CST Newsletter June 2020

We invite you to take a look at our current newsletter that contains information on algorithm transitions, updates to the FIPS IG and a breakdown of the changes in TEs from FIPS 140-2 to FIPS 140-3.

Congratulations to Qualcomm

One of the rewards of working in the evaluation and testing business is to see our customers succeed and show the results of their efforts. We are always happy to work with organizations who are committed to IT security and want to improve their products and processes for the benefit of their customers.

In that spirit we would like to congratulate Qualcomm for their recent successes in attaining FIPS 140-2 certificates for several of their cryptographic modules. We are honored to be a partner in Qualcomm's FIPS 140-2 endeavors.

Read Qualcomm's blog article here.

Rise & Fall of MD5

by Richard Fant

The Rise
MD5 (message digest version 5) was developed in 1991 and is still very popular today, with a wide range of commercial and government applications. MD5 is used to generate hash values of passwords stored on a system as opposed to storing the passwords in plain text. This password protection method was used by many popular commercial websites such as LinkedIn, eHarmony, and LastFM. In addition, many government agencies originally adopted MD5 for official use.

How it Works
If you take a large set of numbers and apply mathematical operations on it to reduce the large set to a much smaller value, those operations are collectively called a hashing function. Particularly, in Computer Sciences, a hash function is any function that can be used to map data of arbitrary size to fixed-size values. The values returned by a hash function are called hash values, hash codes, digests, or simply hashes.

A typical use of hashing functions is to verify the integrity of files after a file transfer. For example, a person wishing to transfer a document called File A over the internet would first hash the contents of File A into a value representing File A. At the destination, the newly arrived file, call it File A’, is similarly hashed into a value representing File A’. The two hash values are compared. If both values are the same, then File A’ is the same as File A which means the transfer was successful and no damage occurred.

As with all hashing functions, MD5 is designed to be a one-way function: it should be extremely difficult to reverse engineer the output to determine the input. One of the most common ways to attack a one-way function, is to run a brute-force search for all possible inputs to see if they generate something which matches the same specific output. This is known as finding a hash collision. The security strenght of a hash function is measured by how difficult it is to find a hash collision.

How is it Used
MD5 is frequently used as hashing function for passwords. For example, a user’s LinkedIn password such as “MyPasswordIsGood!” could be put into a hash function which would generate a 128-bit hash value starting with something like “7A07C” (the actual hash value would be longer, but shortened here for convenience). This hashed password could be stored on the LinkedIn website. Whenever the user logged into the website with their plain text password, it would be hashed and then compared with what was already stored there. If they matched, the user was authorized access. This process of hashing the password means that simply stealing hashed passwords from the website is insufficient to gain access. This also means that the user’s plain text password is never stored on the website itself which increases overall security. However, there is a weakness in the process, the previously mentioned hash collision.

A hash collision is when two different input values generate the same output value. In the above example, suppose that “MyPasswordIsGood!” generated “7A07C” as output. A hash collision is when another input such as “TqBfjO7#DB” actually hashes to the same value “7A07C”. This means an attacker would not have to know the original plain text password to gain access to a website. Instead, using brute force an attacker could run billions or trillions of random input values into the MD5 hash function until they saw the expected output “7A07C”. And thus, the attacker could access the website using the second input value “TqBfjO7#DB”.

With only 128 bits for the size of its hash value, the probability of having two MD5 hash values accidentally colliding is approximately 1.47*10-29. Given today’s computing power, an MD5 collision can be generated in a matter of seconds. This was the downfall of MD5.

The Fall
MD5 runs fairly quickly and has a simple algorithm which makes it easy to implement. The main weakness with MD5 is that it is relatively easy to generate hash collisions using today’s computer technologies.

In 2005, security researchers announced that MD5 should no longer be considered secure due to an experiment that showed by running a collision-generating brute-force algorithm on a standard PC notebook for 8 hours, a hash collision occurred in MD5. However, MD5 was so deeply embedded in applications and websites, many considered it too expensive to discontinue its use since that would necessitate rewriting code for thousands of applications.

That attitude began to change when several major corporations began reporting security breaches in their systems where MD5 was used. For example in June 2012, LinkedIn announced that 6.4 million hashed passwords had been leaked to a Russian website and that many of those MD5-hashed passwords had been reverse-engineered using brute force to find its matching input strings. In the same month, Microsoft reported that a new piece of malware, called Flame, was taking advantage of the hash collision security flaw in MD5 to generate a counterfeit digital certificate. This forged certificate convinced Windows Operating Systems, that the Flame malware was a legitimate Microsoft product and should be allowed through the firewall. This allowed the malware to bypass many anti-virus programs and install itself on Windows-based PC’s.

As recently as 2019, nearly 15 years after the publication of the flaws of MD5, one quarter of content management systems used in websites still use MD5 for password hashing.

Wrapping Up
Using Moore’s Law, the predicted computational power of a personal computer will double approximately every two years. This means the computer used in the brute-force attack of MD5 in 2005 was 2⁷ times as powerful as one built in 1991 when MD5 was released. A computer in 2020 is 2¹⁴ times as powerful as a 1991 model. This means when MD5 was released in 1991, the exponential increase of computing power was not taken into account by its users which lead to an overabundance of confidence in the security of MD5.

Final Thoughts
Using MD5 to verify a file hasn’t been corrupted or damaged is a reasonable use of this hash function. Using MD5 to generate the hash value of passwords is a security breach waiting to happen.

atsec China adds two PCI SSF Assessor Qualifications

atsec China has been qualified by the PCI SSC (Payment Card Industry Security Standards Council) as a Secure Software Lifecycle (SLC) Assessor and Secure Software Assessor company under the PCI Software Security Framework (SSF) program to evaluate a vendor's software lifecycle and/or validate a vendor's payment software.

The PCI SSF is a collection of standards and programs for the secure design and development of payment software. Security of payment software is a crucial part of the payment transaction flow and is essential to facilitate reliable and accurate payment transactions. The SSF replaces the Payment Application Data Security Standard (PA-DSS) with modern requirements that support a broader array of payment software types, technologies, and development methodologies. With its outcome-focused requirements, the SSF provides more agility for developers to incorporate payment application security with nimble development practices and frequent update cycles. The SSF enables accelerated provision of customization and features for payment applications for merchants without compromising security. It also improves consistency and transparency in testing payment applications, which elevates validation assurance for merchants, service providers, and acquirers that implement and manage the use of payment solutions.

As a qualified Secure Software Lifecycle (SLC) Assessor, atsec can perform Secure SLC Assessments according to the Secure Software Lifecyle (Secure SLC) Standard. The Secure SLC Standard is intended for validating the lifecycle practices for software vendors that develop software for the payments industry. This standard provides security requirements for payment software vendors to integrate security throughout the entire software lifecycle, which results in software that is secure by design and able to withstand attacks. Upon successful validation by atsec as one of the Secure SLC Assessors, software vendors will be recognized on the PCI SSC List of Secure SLC Qualified Vendors. Secure SLC Qualified Vendors are empowered to perform and self-attest to their own software “delta” assessments with reduced assessor involvement or oversight.

As a qualified Secure Software Assessor, atsec can perform Secure Software Assessments according to the Secure Software Standard. This standard provides security requirements for building secure payment software to protect the integrity and the confidentiality of sensitive data that is stored, processed, or transmitted in association with payment transactions. Upon successful evaluation by atsec as one of the Secure Software Assessors, validated payment software will be recognized on the PCI SSC List of Validated Payment Software, which will supersede the current List of Validated Payment Applications when PA-DSS is retired the end of October 2022.

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

In addition to SSF assessor, as an accredited PCI QSA, ASV, QPA, PA QSA, P2PE, 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 PCI services, please visit:
http://www.atsec.cn/it-security-services/pci/en/index.html