Monday, January 25, 2021

On Software Supply Chains

by King Ables

The attack on the SolarWinds network management platform Orion allowed a bad actor to inject malware into the product prior to it being signed and deployed to customers during a regular software update. This highlights a largely underappreciated but universal truth of the Internet age--almost all businesses depend on a software supply chain they do not control. This attack affected many IT infrastructures across all industries.

Here at atsec, we do not use any of the tools involved, so we have no concerns about this attack related to our local network, our data, or the data we maintain for our customers. However, a number of other companies, like health insurance providers, possess some of our data in order to provide their services. We have asked all of our suppliers to provide what they can about their own assessment of whether they could have been affected and if any of our data might have been compromised.

We received quite the variety of responses.

Not everyone has a definitive answer yet. This is understandable as long as they are actively investigating. This is an evolving issue and even an initial assessment may change over time as new information is discovered.

Some responses were simply unhelpful, like a link to a web page describing the vendor's standard privacy and security policies. The page contained no information regarding this specific attack and therefore did not answer our question.

So far, only one vendor answered with enough detail that we are confident they have performed a substantive analysis. We will continue to query the others until we can have this same confidence in their answers.

Any organization using the SolarWinds Orion network management platform in the last 16 months should be actively performing an analysis to determine if and how their environment may have been affected. This would start with current network traffic monitoring and audit log analysis going back to at least October 2019, when the attack is currently believed to have started. These activities should continue until the software is updated and the backdoor is verified to have been eliminated.

Tuesday, January 19, 2021

atsec is recognized as a NESAS Security Test Laboratory to perform Security Evaluation of Telecommunication Equipment

The GSMA (Global System for Mobile Communications) organization recognizes atsec's ISO/IEC 17025 accreditation that now allows network product evaluations against NESAS Security Assurance Specifications (SCAS).

The NESAS scheme is a collaboration and jointly led by 3GPP and the GSMA, and is open to all vendors of network equipment products that support 3GPP defined functions. NESAS has been developed to strengthen the level of security in 5G and LTE networks following established best practices and schemes that provide security assurance.

NESAS defines security requirements and an assessment framework for secure product development and product lifecycle processes, as well as testing requirements using 3GPP defined security test cases for the security evaluation of network equipment.

atsec is the first laboratory that can perform security assessments of the development and product lifecycle processes, as well as security evaluations of network equipment.

“NESAS accreditation and GSMA recognition allows us to provide a one-stop shop service to our customers. We have performed numerous security assessments of the development and product lifecycle process, and we are now able to offer network product evaluations against NESAS SCAS. We are looking forward to start working with our existing and new customers on security evaluations of their network equipment”, says Rasma Araby, COO and Laboratory Director at atsec AB.

atsec’s ISO/IEC 17025 accreditation scope is unique and includes all NESAS Security Assurance Specification currently listed on GSMA NESAS website. It allows security evaluations of various 5G and LTE network components and functions.

atsec offers this service globally through atsec AB in Stockholm, Sweden.

atsec also offers other security assessment, testing and evaluation services. Information about our services is available in our service portfolio.

Monday, January 11, 2021

Happy Birthday atsec!

Today atsec celebrates its 21st Birthday!

We can finally get a pilot license, gamble at the casino and we won't be mad when we get carded at the ICMC! We are happy to look back on more than two interesting decades and would like to thank our customers, the government agencies, our colleagues and friends for their support on our journey!

Here's to the next 21 years!

Your atsec team


Friday, December 18, 2020

Holiday Greetings from atsec

Our colleagues from around the world wish you Happy and Healthy Holidays and a good start into 2021.

Tuesday, December 8, 2020

Biometric e-Passports

by Richard Fant

Figure 1:  e-Passports issued by different countries

In today’s climate of COVID-19, domestic travel has become difficult, and international travel almost impossible. Many US airlines  now require their passengers to submit to a COVID-19 test within 24-48 hours prior to travel to prove the traveler is not currently infected. Some countries have even closed their borders to international visitors because of the pandemic.

As vaccines become available, immigration officials at border crossings  will need some way to reliably determine if a traveler has been immunized against COVID-19. Different methods are currently used by health organizations to track a traveler’s immunization records such as the World Health Organization “yellow card”. The problem is, many of those records are handwritten on paper and subject to fraud and manipulation as well as wear and tear.

Figure 2:  WHO "yellow card"

Biometric technology could be used to develop a “proof of vaccine record” for COVID-19. This would enable travelers to prove they are immune to the virus, and so help national and global economies restart after the pandemic. One digital tool that could track such vital immunization information is already in place: the Biometric Passport (a.k.a. the e-Passport). With biometric technology, passport control authorities can easily differentiate between authorized travelers and those travelers who represent a potential threat either from infectious disease or illegal activities.

Figure 3: International symbol used  on passport  covers to indicate  e-Passport compliance
How does an e-Passport work?
When applying for an e-Passport, a legitimate traveler voluntarily enrolls in a verification program where their personal biometric data is recorded and stored.  When that traveler passes through passport control, their personal characteristics are captured real-time, and then compared with their stored personal data. If the two samples match, the traveler is recognized as the legitimate passport holder and can then be verified as having the necessary requirements to enter the country (e.g. a Visa). If the stored data and real-time data don’t match, the traveler may be “invited” to participate in additional screening. While immunization records are not yet part of the Biometric Passport, the digital data can be easily added which would make the use of paper immunization records obsolete.

The following types of biometric data are already in use for e-passports:

Finger print scans consist of recording multiple finger tips held in a variety of positions against a flat plane of glass. These typically do not change with age, though injuries or scars can cause change.

Typically facial scans consists of taking a high resolution digital photo and then measuring the distances and angles between prominent features such as eyes, nose, mouth and ears. Wigs, eye-wear, makeup and jewelry have no effect on these measurements. However, these measurements may change as the passport holder ages.

Retinal scans are made by taking a high-resolution mapping of the iris which contains thousands of blood vessels laid out in a pattern unique to the individual. Those patterns don’t change with age, or surgeries such as Lasik or lens replacement.
However, glasses and hard contact lenses might produce glare or partly obstruct the iris.

Digital Signatures
Conventional cryptography uses the same key to encrypt data as it uses to decrypt data. This symmetric cryptography means the single key used for both encryption and decryption must be kept secret. By contrast, e-Passports implement asymmetric cryptography by using a pair of keys to secure its data: one key (private) is used to encrypt while a different  key (public) is used to decrypt. The private encryption key must be kept secret while the public decryption key is widely distributed.

This encryption and decryption process is also known as digital signature generation and verification. The digital signature used in an e-Passport is designed to confirm the authenticity of the data and detect if the data stored on its chip has been modified. The modification of a single bit in the e-Passport data will cause the verification of the digital signature to fail.

To initially prepare the e-Passport for a digital signature, the passport authority will generate hash values for all the files contained within its chip: picture, fingerprints, facial scan, personal data, etc.  The hash values will then be digitally signed using that country’s private signing key. As new records are added such as a Visa or possibly COVID-19 immunizations, online lists would be updated associating this particular e-Passport with those online records. For example, Australia uses Electronic Travel Authority (ETA) to keep track of which foreign passports have the appropriate Visa to enter their country.

When the e-Passport is used at a border crossing, the digital signature of the e-Passport is verified using the public key of the issuing country. This verification process informs border authorities that the electronic data in the e-Passport is authentic, was issued by the appropriate country and has not been modified.

These digital signatures are unique to each country. Each country also shares its public keys in the Public Key Directory (PKD). The PKD is a global repository  where countries exchange their public keys with other countries.

What actually happens at a border crossing?
Any Border Control System needs to verify the following:

  1. Does the passport belong to the person providing it?
  2. Is the passport authentic or was it falsified in any way?
  3. Is the passport issued by the proper authority entitled to issue it?
  4. Does the traveler have the necessary requirements to enter the country? For example: Visa or immunizations.

An arriving passenger at an international border crossing would present their e-Passport to an optical scanner located at a gate or kiosk while an RFID system downloads all the data from the e-Passport.

The Border Control System would then verify the digital signature in the e-Passport using the issuing country’s public key. The Border Control System would also capture the traveler’s biometric data real-time (e.g. finger prints or facial scan) and compare that sample against the traveler’s template stored in the e-Passport.

Once the traveler’s identity is verified, and the validity of the e-Passport is confirmed, the Border Control System would compare the traveler’s name and data against a list of requirements to determine if entry into the country is permitted. The list could contain immunization requirements, or specific names of undesirable travelers.  

To demonstrate the accuracy of a biometric scanner, consider that an automated facial recognition system will correctly verify a traveler 95% of the time while a human passport control officer has a false acceptance rate of 1 face out of 7 faces or a FAR of 14%. This means that an automated facial matching system is more accurate than one which relies solely on human judgment. For example, three weeks after being installed at Dulles Airport in Washington, D.C., automated facial recognition caught two travelers trying to illegally enter the United States using someone else’s passport. These same travelers had successfully cleared the human screener before being caught by the automated system.

Security of the e-Passport system
Many countries have gone to great lengths to protect the security of their e-Passport system.  For example, to establish a secure RFID connection between the Border Control System and the e-Passport, a session key is mathematically derived using data from the bottom of the e-Passport’s front page such as passport number, date of birth and expiration date (see the red circle in Figure 4).

Figure 4: Machine Readable Data

This derived session key is then used to establish a secure RFID channel between the e-Passport and the Border Control System using protocols based on the Diffie-Hellman key agreement to generate a shared secret password.  The channel is then used to securely download the e-Passport data to the Border Control System. This helps mitigate RFID attacks such as skimming and eavesdropping.

Shortly after the introduction of the Canadian e-Passport, instances of  forgery and fraud were reported in the press. It was discovered that newly issued e-Passports could  be electronically altered if attackers used a commercially available chip programmer. Officials also had reports of discrepancies between information contained in the remote database and what actually appeared in the passport.  Most passport authorities now lock the chips in the e-Passport after programming.

This is an example of a cloning attack where the data on a chip is over-written in order to mirror someone else’s chip. Another variation of this attack is when the chip is physically removed from one passport and inserted into a different passport. These attacks can be mitigated by verifying the chip data matches the information on the e-Passport’s first page. Participants in the US Global Entry Program are familiar with this verification process since they must scan the first page of their e-Passport at a kiosk at US border crossings where the contents of their chip are compared against the data scanned by the OCR reader.

But, even if an attacker successfully modified the contents of the e-Passport data, the forged e-Passport would still be detected by the Border Control System since the digital signature would no longer match the stored information.

Privacy Concerns
Over time, more personal and biometric data could be added into the e-Passport which could give rise to commercial abuse. For example, a few months after the e-Passport was introduced in Germany, German companies began lobbying the government to sell e-Passport personal data such as name and age to companies for targeted marketing. After long discussions, the German government eventually declined to sell the data. This shows how the personal data on an e-Passport could be abused in the future. For example, if eye color or medical history were included in the e-Passport, this information could be sold to companies that could then target advertising and specific products to the e-Passport holder.

Another privacy concern e-Passports may face in the future is understanding how foreign governments might misuse the biometric data of an individual where the medical condition or history of the traveler is inferred from the biometric data: some fingerprint patterns are related to chromosomal diseases; iris patterns could reveal genetic sex; hand vein patterns could reveal vascular diseases. This causes major privacy concern, since a government could misuse this medical information by placing restrictions for certain categories of travelers. For example, there are over 18 countries which currently deny entry for travelers who are HIV-positive. While a COVID-19 immunization record might be desirable, what other health data should not be tracked?

Future Trends
It is clear that biometrics for e-Passports are here to stay. It is also likely that additional health records such as immunization data will be added in the near future. It is even reasonable to assume that as biometric scanning improves, a Border Control System could began monitoring travelers immediately upon leaving their aircraft to determine if the passenger was legitimate well before they even arrive at Passport Control.

Wednesday, November 18, 2020

atsec at the (virtual) International Common Criteria Conference (ICCC) 2020

by Michael Vogel

atsec participated in ICCC 2020 from November 16th through 18th, which for the first time had to be held fully virtualized due to the worldwide pandemic. The ICCC used the same conference platform as for the ICMC 2020. In addition to attending the ICCC 2020, a number of atsec consultants joined the virtual CCUF Workshop held a week prior to ICCC, including a joint session between the CCDB and the CCUF.

On the first day of the conference our colleague Michael Vogel was moderating the sessions about the new CC ISO Revision Update as well as updates from schemes and iTCs.

As a Gold Sponsor for the ICCC 2020, atsec hosted one of eight ICCC Sponsor Showcases. In the absence of a conference dinner and the traditional certificate handover ceremony, atsec put a lot of effort into this showcase to make it even more entertaining than usual. In case you missed it or didn't manage to sign up for the ICCC this year, we invite you to take a look at the presentation video:

Monday, September 21, 2020

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.

Tuesday, September 1, 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.

Friday, August 28, 2020

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.


Tuesday, August 11, 2020

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:

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:

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.