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

Data Recycling to Become Mandatory in 2022

According to sources in the DPA (Data Protection Agency) new guidelines will be issued soon that will make digital trash separation mandatory. Every year an estimated 240 zettabytes of re-usable bits are thrown into desktop trash cans.

The new guidelines require operating system manufacturers to implement a recycling bin next to the trash can on the desktop. On Linux systems the addition of /dev/green to the existing /dev/null is being discussed.

The collected data will be re-used in the production of cat videos and make-up tutorials and is hailed as an important step forward.

Ryan Hill, Quality Manager at atsec commented: “It always bugged me to just throw away obsolete meeting minutes and draft versions of reports. Now I have the chance to make a difference by being a responsible digital citizen.”

Security experts warn that data leakage could become an issue. ‘You have to be careful when you recycle bits and bytes. You don’t want to see an unboxing video – but it’s your quarterly report being unboxed.”

Further steps to reduce digital trash are currently field-tested, including an initiative to sort zeros and ones and store them separately for more efficiency.


In addition to recycling, some digital environmental groups are recommending data composting as well. Wilbur Sycamore, President of Save our Bits, said, “Recycling is great, but the DPA should also require a data compost bin. That way all that food data waste, such as pictures of meals and recipe blogs, can be made into data compost that will allow us to grow bigger and more robust data!” Scientists estimate that a single month of Instagram food photos could be used to create 50,000 Tik Tok videos.

As with any new initiative there are also skeptics. King Ables, Security Consultant at atsec information security corporation, said, “Unfortunately, these guidelines are unlikely to produce the desired results. Sure, you can reuse the raw data, but when the ones and zeros have been separated, all you can build are null strings and broadcast addresses. What's the point of that?"

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.