atsec China adds PCI CPSA (Logical and Physical) Assessor Qualifications

Beijing, July 23 2021

atsec China has been qualified by PCI SSC (Payment Card Industry Security Standards Council) as a Card Production Security Assessor (CPSA) Company to validate an entity's adherence to the PCI Card Production and Provisioning Logical Security and  Physical Security Requirements (two separate security standards). Currently atsec provides the PCI Card Production Logical Security and Physical Security Standards assessment services in the CEMEA, Canada, Europe, LAC, USA and Asia Pacific markets.

The development, manufacture, transport, and personalization of payment cards and their components have a strong impact on the security structures of the payment systems, issuers, and vendors involved in their issuance. Data security is the primary focus of the standards.

The PCI Card Production and Provisioning Logical Security Requirements (“PCI Card Production Logical Security Standard”) addresses the logical security controls associated with card production and provisioning such as:

•  EMV data preparation
•  Pre-personalization
•  Card embossing
•  IC and magnetic-stripe personalization
•  PIN generation
•  PIN mailers
•  Card carriers
•  Distribution 
  

PCI Card Production and Provisioning Physical Security Requirements (“PCI Card Production Physical Security Standard”) define a comprehensive source of information for entities involved in card production and provisioning, which may include manufacturers, personalizers, pre-personalizers, chip embedders, data-preparation, and fulfillment. The standard specifies the physical security requirements and procedures that entities must follow before, during, and after the following processes:

• Card Manufacturing
• Chip embedding
• Personalization
• Storage
• Packaging
• Mailing
• Shipping or delivery
• Fulfillment

In addition to the card production activities above, the two standards describe the logical and physical security requirements for entities that:

• Perform cloud-based or secure element (SE) provisioning services;
• Manage over-the-air (OTA) personalization, lifecycle management, and preparation of personalization data;
• Manage associated cryptographic keys.

atsec’s CPSA assessors can work with you to confirm the assessment scope, perform the assessment on-site, complete PCI Card Production ROC (Report on Compliance) and AOC (Attestation of Compliance), submit them to applicable payment brands or cooperative entities, and re-validation can be further performed where applicable.

In addition to the assessment service, atsec offers a full range of consulting services to support your organization in achieving compliance with the PCI Card Production Logical and/or Physical Security Standards. atsec consultants have experience in each of the requirement areas (e.g. data security, network security, system security hardening and management, user management, key management, PIN distribution, personal security management, premises security protection, production procedures security control, security audit, secure packaging and delivery), and can help you develop appropriate measures in order to achieve your compliance.

The CPSA Assessors list can be found on the official website of PCI SSC, and atsec’s qualification is shown below: 

In addition to CPSA assessor, as an accredited PCI QSA, ASV, QPA, PA QSA, P2PE, 3DS assessor, SSF assessor and PFI, atsec 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

atsec has become an official GSMA member

atsec has become an official GSMA member. The GSMA represents the interests of mobile operators worldwide, uniting more than 750 operators with almost 400 companies in the broader mobile ecosystem, including handset and device makers, software companies, equipment providers and internet companies, as well as organizations in adjacent industry sectors.

atsec is a GSMA appointed laboratory to provide Network Equipment Security Assurance Scheme (NESAS) security audits and network product evaluations against NESAS Security Assurance Specifications (SCAS). atsec has been involved with and made significant contributions to the NESAS scheme development. Standardization and future development of the NESAS scheme will strengthen the level of security in 5G and LTE networks.

”As an official GSMA member atsec will be able to form long lasting relationships with other members in the GSMA community, contribute to standardization and boost our presence in the telecommunication ecosystem”, says Mrs Rasma Araby, COO and Laboratory Director at atsec information security AB. Mr. Staffan Persson, one of the founders of atsec, also states that “The GSMA membership only proves our global commitment to information security and assurance, and allows our new and existing Common Criteria, FIPS, and O-TTPS customers to rely on atsec for NESAS too.”

atsec offers NESAS related services to all our customers through atsec AB in Stockholm, Sweden. Together with our offices in the US, Germany, China and Italy atsec offers a range of security assessment, testing and evaluation services. Information about our services is available in our service portfolio.

Reflections on Security Assurance

by Staffan Persson

Some reflections on security assurance, how it can be achieved and verified, from the view of an evaluation lab.

Security assurance is usually hard to grasp and sometimes we have seen there is the misconception how it can be achieved. One of the early milestones in understanding assurance came with the vulnerability analysis of Multics operating system:

The internal controls of current computers repeatedly have been shown insecure though numerous penetration exercises on such systems as […]. This insecurity is a fundamental weakness of contemporary operating systems and cannot be corrected by “patches”, “fix-ups”, or “add-ons” to those systems.
Rather, a fundamental re-implementation using an integrated hardware/software design which considers security as a fundamental requirement is necessary. In particular, steps must be taken to ensure the correctness of the security related portions of the operating system.
It is not sufficient to use a team of experts to “test” the security controls of a system. Such a “tiger team” can only show the existence of vulnerabilities but cannot prove their non-existence.

– Paul Karger in the Multics Vulnerability Analysis 1974

It identified the need for secure development to achieve assurance and a systematic approach to very assurance. But what does secure development means approach and what would such an evaluation method look like? Of course these methods have to be practical, which means cost effective. They should also be mutually supportive, meaning that they should have the same interpretation of what assurance and security is and actually contribute so that any developer assurance measures are recognized and used when doing the evaluations. It sounds obvious, but not always the case when looking into the methods used today.

Secure development
We need to be able to specify what we mean with security, so that we know what type of security the product should provided. Products usually only protect against certain threats, under certain conditions and when using the product in a certain way.

A system without requirements cannot fail; it merely presents surprises.

– Young,  Boebert and Kain, “Proving a computer system secure”.
Scientific Honeyweller, 6(2):18–27, July 1985.

There are few standards for specifying security. The best known are the Protection Profiles and Security Targets in the CC. This has to do that CC cannot work without an ST since the CC standard by itself doesn’t state the specific requirements for a certain evaluation in the CC ISO/IEC 15408. It’s not easy do do, but there are also guides for this.

Even a big standard like ISO/IEC 15408 is not a substitute for thinking, and complex matters like IT security cannot be reduced to one sentence descriptions, no matter how hard you try.

– Mike Nash, “Guide for the production of Protection Profiles and Security Targets”
ISO/IEC TR 15446:2009(E)

So what are the secure development principles? There are design and architecture principles, such as those described as the Saltzer-Schroeder principles from 1975 that also grew directly out of the Multics experience. These and other principles are documented by Peter G. Neumann in his report “Principled Assuredly Trustworthy Composable Architectures” from 2004.

However, there is also a Technical Report from ISO ISO/IEC PDTS 19249 providing a good overview of Architectural Principle and Design Principles, stating:

Building a secure product, system, or application requires not only the implementation of functional requirements but also an architecture that allows for the effective enforcement of specific security properties the product, system, or application is supposed to enforce. The ability to withstand attacks the product, system, or application may be face in its intended operational environment is highly dependent on an architecture that prohibits those attacks or – if they cannot be prohibited – allows for detection of such attacks and/or limitation of the damage such an attack can cause.

– Helmut Kurth, Technical Report from ISO, ISO/IEC PDTS 19249

But there is more to secure development than just design principles. The importance of development processes, both for the initial development as well as for the maintenance is getting more attention. There are many different security standards that focuses on that such as GSMA NESAS and OpenSAMM (but not CC).

Note: There is a change in focus that largely has to do with the complexity of modern products, the frequent updates made to them (new features, bug fixes and security fixes) and of course the cost of evaluating the products.

Security evaluations
What about evaluations? What should an evaluation do to demonstrate that a product meets its security requirements? On a high level, there are two aspects that could (or should) be looked at. Assessment of the (1) secure development processes and (2) the assessment of the product itself, i.e. the result of these processes. The assessment of a product, may include a review of design (documentation), security (functional) testing and vulnerability analysis followed by penetration testing. It may give very high confidence for a certain version of the product, but may say very little about the future releases. On the other hand, the assessment of processes gives confidence that the developer has the security development processes under control, also for future products, but may say less about a specific product.

Then we have the aspect of security analysis vs compliance testing. Some standards, such as FIPS 140 used for crypto modules is focused on compliance testing, while other standard such as Common Criteria relies more on open-ended security analysis and search for potential vulnerabilities. All Common Criteria evaluations done in the US uses NIAP approved Protection Profiles that are more or less require to perform compliance testing only. Compliance testing is usually more objective than an open-ended analysis because of its nature. But this means that it is less flexible when it comes to product types and functionality. On the other hand, the open-ended analysis can also verify the absence of exploitable vulnerabilities, i.e. an active search for vulnerabilities and an analysis if they could be exploited. This approach provides more flexibility, but also requires more evidence from the vendor and more skills from the evaluator. There is just no no simple answers.

For every complex problem, there is a simple solution. And it’s always wrong.

– H.L. Mencken, US author and journalist

In summary, there is always a mixture between process and product assessment, and also between compliance and analysis. Unfortunately, many security assessment standards today have very little to do with secure development and almost none of them takes secure design principles into considerations. NESAS is here one exception.

atsec is an evaluation lab for FIPS-140 (with NIST), Common Criteria (in Germany, US, Sweden, Italy, Singapore). We are also NESAS auditors and a SCAS test lab. We are involved with national accreditation in Europe and have done audits according to OpenSAMM. We have seen benefits and drawbacks with all these different approaches, but we think that the assurance measures of developers should be better recognized and so assessments should promote development assurance.

References

1. Paul Karger in the Multics Vulnerability Analysis 1974.
   https://www.acsac.org/2002/papers/classic-multics-orig.pdf
2. J.H. Saltzer, M.D. Schroederer, “The Protection of Information in Computer Systems”, Proc. IEEE, vol. 63, no. 9, 1975, pp. 1278–1308. https://www.cs.virginia.edu/~evans/cs551/saltzer/
3. Young,  Boebert and Kain, “Proving a computer system secure”,
   Scientific Honeyweller, 6(2):18–27, July 1985.
4. ISO/IEC TR 15446:2009(E)
   “Guide for the production of Protection Profiles and Security Targets”.
5. Peter G. Neumann, “Principled Assuredly Trustworthy Composable Architectures”, 2004.
6. ISO ISO/IEC PDTS 19249, “Catalogue of architectural and design principles for secure products, systems, and applications”, Technical Specification, 2017.

The genesis of atsec’s name, logo, and websites

When atsec was about to be founded, one of the first questions the founders (a German, an Italian, and a Swede) had was which name would best represent the company's approach to information security, but more importantly, whether the domain would be available. 
   
Here is the list of all the available domain names in December 1999 that were possible candidates:

• attento
• atsec
• atcert
• atcrypto
  

atsec, atcert, and atcrypto were considered along with attento, which means "watch out" in Italian; attento was eliminated since it had meaning in Italian only and not much in the large Anglo-Saxon market where the company was about to appear.

Even though we bought the domains atcert.com and atcrypto.com, we decided that atcert and atcrypto did not fit our service portfolio because one would limit the perception of the company to a certificate authority and the other to cryptography.

The decision landed on atsec, which is a short version of "atsecurity." The choice of the "@" in the logo seemed the most logical thing to do at the time. In particular, the “@” sign would signal the company’s core commitment to IT security. Also, atsec was a new word that did not exist before then.

The first logo was plain and simple.

The color red symbolizes passion for the subject, and the italic font portrays speed and movement, like a Formula 1 race car.

The red line on the left represents the four guiding principles to be consistently followed.

- Know the business.	- Act with integrity.
- Stay focused.	- Be independent.

Finally, the reversal of the word "atsec" is the word "cesta," which means "basket" in Italian, and it is always associated with a basket of goodies.

Passion, speed, and a basket of goodies: atsec was born. It was January 11th, 2000. A brand-new word, logo, concept, and a basket of good IT Security experts.  We had a winner!

The second logo was a bit catchier but did not last long.

The word "key" was somehow limiting atsec to cryptography.

In 2001, during a consulting engagement at a prominent Internet Service Provider (ISP) in Germany, the motto was formed by playing with the acronymous “ISP” to make "atsec: the information security provider." 
The expression completely defines atsec's mission, dedication, and commitment to "Information Security."

The first full logo with the motto was born sometime in early 2001.

 

In 2005, the logo was restyled and has remained the same to this day.

This logo has been trademarked and copyrighted since 2006. The website design has changed several times but has always been kept simple, with no flash or pop-up windows.

For atsec, information security is a science. However, the cultural components were never to be underestimated.

Our first two websites were just plain and simple with the logo and language options.

The first relevant version of the atsec website came later in 2001. It was a simple design focused on content and news from our projects.

The first website’s transformation came in 2003 and stayed the same until 2010.

Teamwork and expansion were emphasized in the message by choosing a sailing boat as a symbol. Incidentally, from 2003 to 2010, atsec expanded in the US by establishing a branch in Austin, TX in 2003. This was followed, a few years later, by Stockholm, Sweden, and then Beijing, China.

It is worth noting that ours was probably among the first information security websites that was translated into 10 languages, one of them even being Latin!

By the way, the sailing boat theme is still used in some of our marketing material.

In 2010, the website changed and moved to a futuristic design.  Futurism was an artistic movement that originated in Italy in the early 20th century. Its emphasis was on action, speed, and technology.

The website would underline the "looking-forward" concept, as many changes were happening during that time in the Common Criteria standard used for security evaluations.

At the same time, atsec was slowly building its FIPS reputation as the founder of the International Cryptographic Module Conference (ICMC), and several other initiatives in the standards and technical communities.  

Surprisingly, the website's design confused many customers and visitors, so it was changed after five years.

In 2015, the website featured motifs echoing elements of Art Deco, a visual art, architecture, and design style of the early 20th century, which highlights a sleeker form style, curving shapes, and simple lines. As one of the first truly international styles, Art Deco could appropriately represent atsec's global status and service offerings.

 

The current website features a modern design, with simple forms and colors that add a sense of space and positive energy.  The blue sky represents the boundaries (the sky is the limit, pun intended), the golden globe represents the value of our services to customers worldwide.

 

The new web design continues to reflect atsec's dynamic team.  We continue to evolve, constantly searching, adapting, and creating opportunities for our colleagues, customers, and suppliers.

We remain one of the prominent validation and testing laboratories. Our services are appreciated by our customers, agencies, and even competitors.  After more than 21 years, atsec is a significant and independent player in the validation business.

It is a good story to tell.

As we launch the new website today, on the US operation’s 18th birthday, I encourage the new management team to continue the legacy imprinted in the four founding principles.
 

I want to thank all our colleagues within atsec today, and whoever has contributed to making this company a successful, independent, and enabling platform that allows information security and assurance practitioners to grow and prosper.

Once more.

...sal.

atsec scholarship connects logic and cryptography

 by Dr. Yi Mao

    

The two most repeated terms at the NIST Entropy Workshop held on April 27-29 are “mathematical model” and “justification.” That brought me back to my college days at Peking University where I first studied Mathematical Logic.

 

Logic is all about valid rules of inference. Mathematical logic applies the techniques of formal logic to mathematics and mathematical reasoning, and applies mathematical techniques to the representation and analysis of formal logic. It has four pillars: model theory, proof theory, set theory, and computability theory. While logic can be traced back to ancient Greek philosopher Aristotle, mathematical logic made great progress in the period from the 1930s through the 1970s. The exciting developments in mathematical logic in this period set the foundation for computer science. Alan Turing and John von Neumann are both world-renowned mathematical logicians and computer scientists. The strong connection between the two fields has continued with no sign of slowing down, which is demonstrated in the NIST Entropy Workshop last week.

 

The book “Foundations of Logic and Mathematics: Applications to Computer Science and Cryptography,” and its newer edition “Logic, Mathematics, and Computer Science: Modern Foundations with Practical Applications,” elaborate their interconnections through model theory, proof theory, set theory, and computability theory. My professor at UT-Austin, Robert L. Causey, explains Why Logic is Important for Computer Science and Mathematics on his class webpage (https://www.cs.utexas.edu/~rlc/whylog.htm) as follows.

 

“Logic is concerned with forms of reasoning. Since reasoning is involved in most intellectual activities, logic is relevant to a broad range of pursuits. The study of logic is essential for students of computer science. It is also very valuable for mathematics students, and others who make use of mathematical proofs, for instance, linguistics students.”

 

Holding a Ph.D. in mathematical logic from UT-Austin and being a lab director at atsec, I felt an enormous duty and responsibility to promote the tie between logic and computer science, which can be narrowed down to cryptography in particular or even just entropy source assessment in our daily work. atsec has been recruiting crypto experts with strong mathematical logic and computer science backgrounds. atsec has also established a scholarship at Peking University in memory of professor Song Wenjian to reward students who excel in logic.

 

Professor Song dedicated his entire life to teaching and researching logic till his passing in 2020. One of his biggest achievements is the creation of a logic major for undergraduates at Peking University in 1987. I was one of the first class of students who majored in logic and found this program had a profound influence on my pursuit of doctoral study and the security profession. 

 

The establishment of a scholarship in the name of Professor Song through the atsec donation is highly appreciated by Peking University and Professor Song’s family. The scholarship will inspire more students to study logic and its interconnected areas of Mathematics and Computer Science.

 

Peking University, nicknamed “Harvard of China,” is a prestigious university in Beijing that celebrated its 123rd birthday on the 4th of May. Adding to the celebration, Peking University held a scholarship launching ceremony on that memorable day. My colleagues Haiwei and Yan from our atsec China office attended the ceremony (first and third from the right in the front row of the picture below). 

 

For more information about this event in Chinese, see the news posted by Peking University at http://www.phil.pku.edu.cn/xwgg/xnxw/514154.htm

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.

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!

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
 

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.

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.

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.