Thursday, April 1, 2021

New Cybersecurity Initiative will use Detection Dogs to spot Cyber Security Attacks to the US IT Infrastructure

Washington, DC—A new cybersecurity initiative dubbed PAWS (Puppy Assisted Warning Systems) has been introduced today by the US Department of Defense (DoD) to combat and deter the rising threat of cybersecurity attacks from countries who have vested interests to undermine US IT infrastructure and businesses. The 1.7 trillion dollar program will be entirely self-funded through the sales of NSA branded dog toys, and it is being rolled out and expected to be in operation by 2025.

Rowlf Hundsinger, the US DoD’s Chief Canine Asset Trainer, said during a press conference from a high security kennel facility in the backyard of the NSA complex at Fort Meade: “US cybersecurity programs have been lagging, but this program will give us a new leash on life. Dogs are excellent at sniffing out drugs, they can warn of impending dangers like strokes and earthquakes—why not use them for more critical tasks like protecting the US infra… wait, is that the mailman at the front door? What is he up to? Hey! HEY!!!”

Cyberattacks cost the US billions of dollars each year and put the Nation’s infrastructure in danger. Thanks to dedicated and focused canine agents, this will soon be a thing of the past:



Agent Fang “Rocket” Anklesnap during a routine inspection of a digital network in a secret ICBM facility in Montana. Agent Bronco “Butters” Bloodwolf on assignment at an NSA server farm in REDACTED, RD.

atsec’s Chief Non-Human Companion Resource Manager & Groomer Ryan Hill commented: “We have to rely on unusual solutions to complex problems. As in many other areas, we use the excellent solutions millions of years of evolution have come up with. This step towards a more holistic… what… yes? Oh, who’s a good boy? WHO’S A GOOD BOY! You are, yes, you are!”

Andreas Fabis, Head of Interspecies Relations at atsec, said, “At first the idea of canine cybersecurity agents gave me paws, but then I saw a trainee sniff out a buggy packet and I was impressed.” He then proceeded to stare at a door and growl.

Agent Titania “Ella” Ruffles observing the safe restart of a critical network router. Agent Butch “Spicey” Thunder conducting an interview with a sysadmin at Langley.

Research has shown that different breeds have different cybersecurity strengths. Bloodhounds can sniff out any attack. Herding dogs like the Border Collie can construct impenetrable firewalls. Companion dogs like the Pug are experts at resisting social engineering, unless doggy treats are involved, in which case, all bets are off.

The program does generate ethical concerns with some animal rights activists. “It’s cruel to make any animal stare at a screen for eight hours a day. What about fresh air, sunshine, fetch?” said one Brigette Barker, actress and activist.

atsec has prepared diligently to be accredited as a PAWS laboratory under the National Voluntary Lab Accreditation Program (NVLAP) and will debut its validation service in the coming weeks. atsec’s trained canine consultants will be ready to support our customers to achieve the coveted NIST-issued PAWS certificate, tied to a squeaky toy.

A similar project – involving cats - under the aegis of NIST’s Cryptographic Module Validation Program had to be cancelled due to the fact that cats do not care at all about IT security or following any standard.


Monday, March 8, 2021

Choose To Challenge

Quotes from our colleagues in Austin:

Viktoria:

It’s already March 2021 and today we are celebrating International Women’s Day! Growing up in a Russian family, International Women’s Day was one my favorite holidays. My dad would always bring flowers and small gifts for my mom and me. It was a peaceful celebration.

This year’s IWD is occurring during the Covid-19 pandemic, which has had a major impact on everyone around the world. The United Nations reports that globally, 70% of the healthcare workforce are female. I am grateful for the hard work these healthcare workers have been putting in during this difficult time.

International Women’s Day has been celebrated for over a century since it began in 1911. In 1996, the UN started announcing annual themes for this holiday. This year’s theme is “Choose to Challenge.” A call to challenge and call out gender bias, stereotypes, and inequality. While it is important to call out other people’s bias and stereotypes, I think it is also equally important to catch our own bias and perceived limitations.

As the newest female employee of the atsec US team, I am very grateful to be a part of such a wonderful company. I feel like an equal here and I am very impressed with the kind, helpful, and very knowledgeable female leaders and mentors at this company.

The (ICS)2 Cybersecurity Workforce Report showed that in 2017, only 11% of cybersecurity professionals were women. In 2019, a restructuring of the survey to better represent all cybersecurity professions revealed that women make up 24% of the global cybersecurity workforce.

I did not start my career in a technical field, but I am glad I challenged my own limitations and decided to pursue a technical career. I encourage other women and girls to not be afraid, challenge the limitations they and others have placed on them, and pursue careers in exciting technical fields such as cybersecurity.

Happy International Women’s Day!


Marylene:

Happy International women's day to you all!

It is so comfortable to work in a company where women have room to evolve and shine!

I cherish the atsec tradition of the yellow flowers that remember me the Mimosa blooming that time of year in the Mediterranean coast.

Have a good week!

Tuesday, March 2, 2021

The Impact of TLS 1.3 and ACVTS on FIPS Certification Testing

by Marcos Portnoi, Stephan Mueller, and Viktoria Meyerhoff

In 2018, the Internet Engineering Task Force (IETF) published RFC 8446, “Transport Layer Security (TLS) Protocol Version 1.3”, a new standard for the latest version of TLS. TLS is the successor of SSL (Secure Sockets Layer), which was developed by Netscape in 1995. In 2020, the Cryptographic Module Validation Program (CMVP) updated the algorithm testing process from the Cryptographic Algorithm Validation System (CAVS) to the Automated Cryptographic Validation Testing System (ACVTS). Companies pursuing certifications may wonder how TLS 1.3 and ACVTS affect the algorithm testing requirements needed for FIPS certification.

Full TLS 1.3 Handshake
Full TLS 1.3 Handshake
 

Transport Layer Security is a protocol utilized in encrypting data transferred over the internet. Information systems use the Hypertext Transfer Protocol (HTTP) to facilitate communication across the internet. HTTPS (Hypertext Transfer Protocol Security) enables encrypted communication by layering HTTP over a TLS channel. In order to utilize HTTPS, a TLS certificate must be installed on the origin server to permit server authentication to the client. The client may also use their own certificate, which allows for bi-directional authentication. The user’s browser and the server can communicate securely after a successful TLS handshake and establishment of the TLS encrypted channel. TLS 1.2 employs the RSA as well as elliptic-curve Diffie-Hellman (ECDH) / Diffie-Hellman (DH) algorithms in its handshake, among other options. The issues with forward secrecy and the several back-and-forth communications by the RSA key exchange posed a security risk in the process. In order to improve security and speed, the IETF decided to abandon use of the RSA key exchange as well as non-ephemeral Diffie-Hellman and only allow use of ephemeral ECDH/DH and RSA for authentication. Hence, TLS 1.3 allows using a pre-shared secret that is not transmitted through the channel or utilizing ECDHE for ephemeral session keys. Pre-shared keys can be used in conjunction with ECDHE to achieve forward secrecy. The updates to TLS 1.3 also include removal of MD5, an algorithm for key exchange that focuses on elliptic curve cryptography, and key exchange simplification using HKDF-based derivation including utilization of a parallel derivation process.

While TLS 1.3 supports (pre-shared key) PSK for establishment of the session, a method without forward secrecy, the forward secrecy process works in the following way: When the TLS 1.3 key exchange with forward secrecy process first starts, both parties do not have a shared key. Hence, the TLS handshake must include a method to create a shared key. For this to take place, six parameters are required. The initiator must send a key, an initialization vector, and a MAC key to the responder and vice versa. To generate the keys, the DH/ECDH process is conducted, so that both parties possess the same pre-master secret. The pre-master secret is then needed to create six keys, which is accomplished with a pseudorandom function (PRF). The PRF uses HMAC key derivation function (HKDF), a hash-based message authentication code (HMAC)-based key derivation function (KDF) as described in RFC 5869. HKDF implements two functions: an extract function and an expand function. During the extract function, a new keying material with a limited length is derived from an initial key. In the expand function, the initial key can be used to create keying material of various lengths from which cryptographic keys can be extracted. The function can be called upon numerous times.

The TLS 1.3 protocol described in RFC 8446, section 7.1, explains that the key schedule utilizes HKDF expand and extract functions. The various expand functions generate several different keys. Utilization of HKDF brings up some concerns when it comes to testing. Per the Implementation Guidance (IG) Section D.8 (Section D.F in the 140-3 IG), HKDF is only approved for use within SP800-56C Rev. 2 key agreement as a two-step KDF and must be tested using the ACVP tool. TLS KDF 1.3 is approved for use within SP800-56C Rev. 2 per IG D.8 and it is also approved as a component algorithm to be used by itself per IG G.20 (Section 2.4B in 140-3 IG). Many Implementations Under Test (IUTs) implement HKDF within their cryptographic module boundary, but the HKDF calling sequence is oftentimes outside of the boundary, such as in a TLS-stack. Furthermore, while KDF TLS 1.3 is based off HKDF, KDF TLS 1.3 and HKDF are different cryptographic algorithms with their distinct certificates. A KDF TLS 1.3 algorithm cannot be claimed using an HKDF certificate, but keys derived by a certified HKDF can be claimed as valid TLS 1.3 keys.

To ensure NIST cryptographic algorithm testing requirements are met for FIPS certification, either of the following scenarios must be tested.

  1. If the HKDF calling sequence is within the module boundary, the TLS 1.3 test as defined by ACVTS must be used. This test provides a pre-master secret and demands that all keys in the KDF TLS 1.3 key schedule are returned. The TLS 1.3 test vector provides either a DH shared secret or a pre-shared key along with the server hello random value, the client hello random value, the server finished random value, and the client finished random value. Per the key schedule in RFC 8446 section 7.1, the IUT is now expected to calculate all the following values: the client early traffic secret, the early exporter master secret, the client handshake traffic secret, the server handshake traffic secret, the client application traffic secret, the server application traffic secret, the exporter master secret, and the resumption master secret. This test approach requires the calculation of the different interleaved HKDF extract and expand steps.

  2. If the HKDF calling sequence is outside of the module boundary, the test for HKDF as defined by ACVTS must be utilized. This test provides a key for the extract function and checks the result of the expand function. The HKDF test contains two test approaches: In the first approach, the test vector provides the salt and input key material (IKM), which is equal to the shared secret computed by the DH/ECDH operation during the TLS handshake. Utilizing this, the extract operation is performed, and additional info is provided to perform the expand function, such as the calculation of the output keying material (OKM) as stated in RFC 5869. In the second approach, the test vector utilizes the same input parameters as in the first approach, but it also uses the result of the HKDF expand function. Now the IUT must return a Boolean operation to indicate whether the OKM calculated by the expand function matches the OKM of the test vector.

To summarize: If the calling sequence is inside of the module, utilize the TLS 1.3 test. If the calling sequence is outside of the module, utilize the HKDF test. NIST has approved both tests.

The publication of RFC 8446 “Transport Layer Security (TLS) Protocol Version 1.3” and the implementation of the Automated Cryptographic Validation Testing System (ACVTS) are major changes in the world of security and validation. atsec information security is an independent, privately-owned company that focuses on providing laboratory and consulting services for information security. If your company is interested in pursuing FIPS certification for your software, firmware, hybrid, or hardware products, please contact us at info@atsec.com.

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.