atsec IT security blog

Guiding the Way through the World of Cyber Security

2024-07-22T09:00:00.001-05:00

Roughly every five years, we refresh our website with a new appearance. As a precursor to our 25th anniversary in January 2025, we are thrilled to show the world our stylish, modern look.

It is atsec’s firm belief that effective security assurance can only truly be accomplished when the product developers proactively incorporate security requirements they thoroughly understand. Thus, it is our responsibility to guide our customers through the complex and changing world of security standards so they can feel confident in their understanding.

To that end, we refreshed our website with a new appearance to ensure it represents the current security standards landscape and that it is simple for anyone to navigate the relevant security requirements and find the services they need.

As we launch this new version of our website, we wanted to take a moment to reflect on the changes in and the demands of the cyber security industry with a piece from one of our co-founders, Staffan Persson:

The world of IT is constantly evolving, becoming more sophisticated, and covering more areas; cyber security is no exception. There are vanishingly few areas where cyber security is not crucial, as regulators usually demand some minimum level of security, and customers also increasingly understand how critical security is. We have all learned that cyber security is not entirely about features or functionality, it's about confidence in those security measures and their effectiveness; that confidence requires a set of criteria and an assessment showing that these criteria have been met.

When we started atsec almost 25 years ago, security requirements were limited and focused on specific types of products and types of users, so it was a niche market for users and developers of high-security products. Although the security area was not mature yet, it was still relatively easy to discuss and understand security problems within such a small community. Still, it was also not a “cool” business to be in, so it remained small for quite some time. This has now completely changed.

The current demand for security is huge: There are more security requirements than ever before, as well as different schemes to measure and certify security, both national and international. Sometimes, it is not even clear if a vendor has to comply with any security requirements, much less which specific requirements. In fact, the market is changing so fast that regulators also have a difficult time keeping up with these changes.

Good security cannot be achieved by assessment alone, since such verification can only assess what's already there, provided by the vendor. For real improvements in security, it is essential that product developers understand and endorse security, including endorsing the security criteria they must comply with.

Security criteria that have been available for decades have been updated, new aspects have been included, and - as confusing as they might be - it is important for vendors to understand these criteria. Clarity and transparency are an essential part of security, especially to the labs performing the security assessments, as they may be the first point of contact for vendors.

Given the importance of clarity in a complicated space, atsec has modernized its web site to help lead by example:

The website now comes with a modern design and covers all the services offered by every atsec office worldwide; this means no separate web site for each office.

One main menu, structured by the various service groups, presents each of the specific services provided by our offices in a way that shall help our customers find the best combination for their individual needs.

Along with each service, we also provide links where customers can download additional information, including authoritative links with references to the criteria and schemes. Informing our customers is of utmost importance to us, as we are convinced that customers who understand the criteria and their requirements can implement security profoundly better than those who are just impressed by some security expert witchcraft.

This focus on the services, rather than their location, addresses the quite common situation where customers may need several types of assessment services that require the cooperation of multiple atsec offices. This co-operation between our offices to serve our international customers has been a hallmark of atsec’s business since its foundation, so it made sense to unify everything on a single website.

We hope that this update will help you to better understand the different security criteria and whether they are useful for you. It may also be difficult to find out which security requirements are appropriate, what the requirement means, how big the effort will be, and who within atsec to talk to. If you need more information, just contact us for more information, as we’re always happy to help.

Please visit our new website at www.atsec.com.

First SP800-140Br1 Compliant FIPS 140-3 Certificates

2024-07-12T19:25:00.005-05:00

On July 11^th, 2024, the first three FIPS 140-3 certificates for NIST’s SP800-140Br1 pilot program were posted on the NIST website. atsec information security was one of the labs that took part in the pilot program. SP 800-140Br1 specifies modifications of the methods to be used by a Cryptographic and Security Testing Laboratory (CSTL) to demonstrate conformance to ISO/IEC 19790 Annex B requirements.

The project was led by David Hawes (CMVP Program Manager) who kicked off the project in June 2023 in preparation of the rollout of SP800-140Br1 with the intention that it will benefit in preparing for the new process. With regular group meetings and guidance form CMVP, atsec submitted their first pilot in September 2023. This resulted in certificate #4723 for AMD’s ASP Cryptographic Coprocessor ("Phoenix"). atsec would like to thank AMD for their willingness to be part of this project. Special thanks to David Hawes for all the guidance, prompt response and his dedication to this project.

As an outcome of this project, CMVP created MIS Verifier and Security Policy Builder tool which is an important step to facilitate automated verification and processing of the modules. Security Policy (SP) is one of the required documents for FIPS submission. Earlier the SP was written manually in its entirety leading to many consistency and human errors. In the new process, CMVP uses JSON as the submission format to provide a mechanism for receiving structured data. This data in the form of field and table information source is the Module Information Structure (MIS). The remaining information is entered by the vendor into a copy of the CMVP supplied Microsoft Word template document. This completed template is merged with the MIS fields and tables to produce the final Security Policy. The verifier part, parses the MIS fields and performs schema and rule validation that helps eliminate duplication of information and the need to verify multiple separate sources.

This is also accompanied with Br1 variation of the original Web Cryptik, a web-based application for the CSTLs to create and submit their FIPS report packages to CMVP.

This is not the only measure the CMVP is taking to shorten cryptographic module queue: recently Interim Validations were introduced as a way to deal with the current backlog and while it gives some much-needed relief, they come with a reduction in assurance and a shorter certificate lifetime of 2 years vs. the usual 5 years.

For a sustainable way to expedite the FIPS validation process in response to the increasingly high demand for the validated cryptographic modules, the National Cybersecurity Center of Excellence (NCCoE) launched the AMVP (Automated Module Validation Project) initiative and is making good progress. The upcoming ICMC in September will have a Panel on this project and demonstrate its latest development. atsec actively participates in the NCCoE AMVP alongside the CMVP, vendors, and other labs. We are optimistic that we will soon see the lights from the end of the lengthy review-pending tunnel.

Changes Coming to NIAP Entropy Assessment Reports in 2025

2024-06-14T13:02:00.002-05:00

“What do you say to a room full of DRBGs standing around you? Everyone, please be seeded.”
-Quin, atsec tester

When things change, it can help to approach that change with a light heart like this.

Recently, NIAP announced that Entropy Assessment Reports (EARs) must include a NIST Entropy Source Validation (ESV) certificate starting at the turn of the year on January 1st, 2025. This change will be most felt by vendors using third-party entropy sources, as it will be necessary for those third-party entropy sources to have an ESV certificate that can be used in the EAR; for vendors using their own software or hardware entropy sources, comprehensive documentation will be required for the ESV assessment, along with more stringent testing.

For the rest of the calendar year (CY24), EARs do not require an ESV certificate, and vendors using third-party entropy sources can provide clearly stated estimates of how much entropy their third-party solution provides. That said, getting a head start and going through an ESV assessment to get a certificate can help you prepare for both FIPS and NIAP CC evaluations, and can be used to strengthen your EAR for NIAP before the change goes into effect.

If you’re uncertain how to approach these changes, we’re always available to answer questions via phone or email, and Quin and our other testers have already taken training to understand how to navigate the road ahead. Rest assured, we’ll approach it with a light heart.

You can read NIAP’s announcement regarding the upcoming changes on their website in Labgram #118/Valgram #137, and a more detailed overview of the changes is available in NIAP’s Clarification to the Entropy Documentation and Assessment Annex document.

BSI NESAS CCS-GI Scheme Updates

2024-06-07T09:56:00.000-05:00

We'd like to inform our customers and partners that the German Federal Office for Information Security (BSI) recently published new documents approving the use of additional Security Assurance Specifications (SCAS) under the BSI 5G NESAS Certification and Evaluation Scheme (BSI NESAS CCS-GI).

We encourage our customers to fully review the newly published documents and explore how these additional approved SCAS might be useful in achieveing NESAS CCS-GI certification. The full update can be found on BSI’s website for NESAS CCS-GI (https://www.bsi.bund.de/dok/NESAS-Dokumente); for a quick summary, the following SCAS have now been approved:

TS 33.523 18.2.0
TS 33.526 18.1.0
TS 33.527 18.2.0
TS 33.528 18.0.0
TS 33.537 18.2.0

Note that, while BSI have not made any changes to the above SCAS, the refinements for TS 33.117 (as described in the AIS N2 document) are still applicable for SCAS that refer to TS 33.117, such as TS 33.526.

As always, our team is ready to assist with any questions or provide guidance regarding this update.

Get in Touch
For more information on the newly approved SCAS and how they relate to your product lines, please don't hesitate to reach out to us. These services are provided by atsec via the German office.

Email: info@atsec.com
Phone: +49-89-442-49-830
Website: www.atsec.com

Stay tuned for more updates as we continue to bring you the latest within 5G security evaluation and certification.

EUCC and Cybersecurity Certification in Europe

2024-04-23T09:47:00.007-05:00

The European Union Agency for Cybersecurity (ENISA) hosted a cybersecurity certification conference on April 18, 2024, in Brussels, Belgium. The conference very much focused on the implementation of the EUCC - European Cybersecurity Certification Scheme. This scheme, based on the established Common Criteria (CC), aims to harmonize cybersecurity assessments for Information and Communication Technology (ICT) products in Europe.

Transitioning phase
While the EUCC officially launched in February 2024, a transition period is in place to ensure a smooth shift from existing national schemes. Here's a breakdown of what to expect:

2024: This year serves as a grace period for national certifications. Existing certificates issued under national schemes remain valid until their expiration date.
2025 and beyond: It's anticipated that by 2025, the EUCC will become the dominant certification scheme across Europe. National schemes are expected to be phased out completely, making the EUCC the sole gateway for cybersecurity certification within the EU.

A Look Ahead: Embracing the EUCC
The EUCC signifies a positive step towards a more robust cybersecurity environment in Europe. As we move into the latter half of 2024 and beyond, here's what to keep in mind:

National Cybersecurity Certification Authorities (NCCAs) and Conformity Assessment Bodies (CABs): Establish the necessary certification structure; achieve required authorizations and accreditation.
Manufacturers: Familiarize yourself with the EUCC requirements and consider initiating the certification process for your products. Also, consider post-certification vulnerability handling requirements that will be enforced by the EUCC.
Consumers: Look for the EUCC mark when purchasing ICT products and cloud services, signifying their adherence to a rigorous cybersecurity standard.

Market uptake
Predicting the exact pace of market uptake of the EUCC is difficult, but global certificate recognition, well defined and streamlined certification processes would make the scheme attractive to the manufacturers of the ICT products. The future of the EUCC might also be impacted by broader European cybersecurity regulations that could potentially mandate the use of the scheme for certain types of products.
Rasma Araby, from atsec information security, participated in the panel discussion “How to handle vulnerabilities in certified solutions,” discussing vulnerability management and disclosure procedures compliance with the obligations outlined in the EUCC.

What can atsec do for you?
Since the start of the ENISA initiative in 2018, we have been actively contributing to the EUCC development. We regularly inform our customers of the progress to help them benefit from EUCC certification.
If you are interested in performing EUCC certification or have questions regarding our evaluation services, please do not hesitate to contact us (info@atsec.com). We look forward to working with you.

atsec Adds FIDO Evaluation Qualification

2024-04-10T09:34:00.011-05:00

atsec information security (branded as “atsec”) has been qualified by the FIDO Alliance as one of the FIDO Accredited Security Laboratories to evaluate the authenticator products. The accreditation has been listed on the official website of the FIDO Alliance: https://fidoalliance.org/certification/authenticator-certification-levels/accredited-security-laboratories/

In addition, atsec is also one of the FIDO members (https://fidoalliance.org/members/) and contributes to the industry.

Passwords are the root cause of over 80% of data breaches, making them the main problem of cybersecurity. With the average user having more than 90 online accounts, up to 51% of passwords are reused across those accounts. According to the research of FIDO Alliance, the average help desk labor cost for a single password reset is up to $70.

FIDO, short for “Fast IDentity Online”, is a series of authentication standards that help reduce reliance on passwords. As an accredited security laboratory by the FIDO Alliance,. atsec information security offers the following security evaluation services for your authenticator products:

FIDO2: FIDO2 is comprised of the W3C Web Authentication (WebAuthn) and corresponding Client-to-Authenticator Protocols (CTAP) from the FIDO Alliance.

WebAuthn: WebAuthn defines a standard web API that is being built into browsers and platforms to enable support for FIDO Authentication.
CTAP2: CTAP2 allows the use of external authenticators (FIDO Security Keys, mobile devices) for authentication on FIDO2-enabled browsers and operating systems over USB, NFC, or BLE for a passwordless, second-factor or multi-factor authentication experience.
CTAP1: Formerly known as “FIDO U2F”, CTAP1 allows the use of existing FIDO U2F devices (such as FIDO Security Keys) for authentication on FIDO2-enabled browsers and operating systems over USB, NFC, or BLE for a second-factor experience.

FIDO UAF: FIDO UAF supports a passwordless experience for online service on users’ own device with local authentication mechanisms such as swiping a finger, looking at the camera, speaking into the mic, entering a PIN, etc.

The FIDO2 and FIDO UAF protocols have been identified within the common specification authenticator security goals. There are 16 Security Goals (SG) identified by FIDO, and 29 Security Measures (SM) that can be implemented to cover the security goals for FIDO authenticators. Ten Security Requirements are derived to support the Security Measures:

Authenticator definition Derived Requirements
Key Management and Authenticator Security Parameters
Authenticator’s Test for User Presence and User Verification
Privacy
Physical Security, Side Channel Attack Resistance and Fault Injection Resistance
Attestation
Operating Environment
Self-Tests and Firmware Updates
Manufacturing and Development
Operational Guidance

Passwords and other forms of legacy authentication, such as SMS OTPs, are knowledge-based, a hassle to remember, and easy to phish, harvest, and replay. FIDO helps shift from this legacy, knowledge-based authentication scenario to a modern, possession-based and phishing-resistant authentication scenario.

The security testing of the authenticator products against FIDO standards allows vendors to integrate their authenticators into modern and FIDO-enabled online services and provides their users with a flawless authentication experience. This also reduces the risk of a password being forgotten or stolen.

atsec is ready to partner with you to help you understand the requirements of the standard, test your authenticator products, and achieve the FIDO certification.

The products being compliant with the FIDO UAF, FIDO U2F, and FIDO2 specifications and evaluated by a security laboratory (e.g. atsec) can be certified and listed by FIDO alliance on the official website: https://fidoalliance.org/certification/fido-certified-products/.

For more information about atsec, please visit: https://www.atsec.com.

atsec AB first IEEE 2621 Accredited Medical Device Testing Facility

2024-04-01T13:12:00.034-05:00

atsec AB Stockholm, Sweden is thrilled to announce: We are the first IEEE Authorized Testing Facility!

We've officially been approved as an IEEE Authorized Testing Facility, making atsec AB Stockholm, Sweden the first company able to provide testing of medical devices according to the IEEE 2621 standard. Additional locations include atsec corporation Austin TX, USA and atsec GmbH Munich, Germany.

The IEEE, or Institute of Electrical and Electronics Engineers, is a globally recognized leader in developing technical standards. Earning their authorization as a testing facility demonstrates our capability to conduct rigorous and reliable security evaluations of medical devices according to the IEEE 2621 standard.

Importantly, the IEEE 2621 standard is recognized by the Food and Drug Administration (FDA), the leading regulatory body for medical devices in the United States. This recognition signifies that the FDA considers the standard to be a valuable tool in ensuring medical device security.

Proven Expertise Through Pilot Projects
"We enthusiastically embraced the opportunity to become a player in this domain when IEEE first contacted atsec in July 2022," said Sal La Pietra, President and founder of atsec.
We're particularly proud of this achievement because it follows the successful completion of two pilot projects that used the IEEE 2621 standard for medical device testing. These projects allowed us to refine our processes and demonstrate our expertise in applying this standard," added Rasma Mozuraite Araby, Managing Director of atsec AB in Stockholm, Sweden.

Looking Ahead: Medical Device Testing
As an IEEE Authorized Testing Facility with laboratories in Sweden, the U.S., and Germany, atsec is now positioned to offer our clients a suite of testing services that ensure their medical devices meet the industry's security benchmarks. If you're looking for a reliable partner to verify the security of your medical devices, contact us today to discuss your specific needs.

BREAKING NEWS: c@tsec information security Unveils Revolutionary Quantum Computer

2024-04-01T00:44:00.000-05:00

April 1, 2024 – Austin, TX: In a groundbreaking announcement today, c@tsec information security, a subsidiary of atsec information security, and the leader in quantum computing technology, proudly unveils its latest innovation: the Quantum PurrProcessor™.

The Quantum PurrProcessor™ operates on a revolutionary principle, harnessing the power of Schrödinger's Cat to perform computations beyond the limitations of classical computers. By forming a matrix of 1024 by 1024 cardboard boxes, each containing a Schroedinger’s cat either alive or dead, we achieve a never before seen computing power of 1024² CuteBits.

"We are ecstatic to introduce the world to our feline-fueled quantum computing marvel," said Stephan Mueller, Principal Consultant and Chief Feline Officer at c@tsec. "Our approach not only pushes the boundaries of quantum mechanics but also provides a cozy home for these quantum kitties."

However, due to strict animal welfare regulations, c@tsec’s scientists had to make a few adjustments. Instead of furry felines who could be either alive or dead, our boxes are now filled with state-of-the-art RoboCats™ driven by the newest generation of AI, thus merging several cutting-edge technologies.

"Our RoboCats™ are programmed with the indecision of a real cat and the computational prowess of a quantum physicist," said Mueller. "And they don't shed – a win-win for both computing efficiency and office cleanliness!"

Once more atsec information security proves to the world that easy solutions to difficult problems are possible. The Quantum PurrProcessor™ will be available for purchase in the near future. Maybe 5 years from now. Or on April 1st 2025.

XDRGB - Random Bit Generator using any XOF

2024-03-27T12:02:00.001-05:00

Resulting from a joint collaboration between John Kelsey (NIST), Stefan Lucks (Bauhaus-Universität Weimar, Germany) and Stephan Müller (atsec information security), a new deterministic random bit generator (DRBG) is published. The XDRBG was publicly presented at the 30th Fast Software Encryption Conference 2024 in Leuven, Belgium.

The XDRBG uses an extensible output function (XOF) as primitive which allows the use of SHAKE algorithm (FIPS 202), as well as Ascon, the finalist in the NIST lightweight cryptographic algorithm competition. In addition, other XOF functions are allowed to be used with the XDRBG specification.

The DRBG is significantly smaller compared to the DRBGs defined in SP800-90A. The XDRBG specification not only defines the algorithmic part of the XDRBG, but also provides a mathematical proof of its design. The security proof applies to all usable XOFs. In the not too far future, the XDRBG specification will also be supplemented by an appendix mapping it to the German AIS 20/31 specification. The specification also maps to the model defined in the NIST SP800-90A standard.

A standalone reference implementation is available at Github.

Crypto Module Bootcamp 2024

2024-03-01T11:39:00.008-06:00

On Tuesday, February 27, 2024, atsec information security hosted a free day-long hybrid event on the Concordia University campus in Austin, TX. With 330 registered attendees, both in-person and remote, we have by far surpassed our original attendance estimate.

When atsec started the International Cryptographic Module Conference (ICMC) in 2013, we wanted to create a forum for the stakeholders in the crypto module world to come together. The ICMC has flourished over the last ten years and is now a well-established and highly regarded conference for IT security professionals. However, the cost involved in traveling and attending the conference has closed the door to students and attendees from academia.

It is important to us to make events like these easily available to college students. Those students will soon become laboratory testers, agency validators, and developers – the next generation of IT professionals. We have taken pride in educating and lifting up the IT security community, including those studying for the future.

The bootcamp is an event intended to carry out our idea of attracting a new group of attendees: the STEM students. We started with Concordia and UT Austin. We are pleased to have created the opportunity for students, who could be our future colleagues, to interact with industry and government leaders, as well as policy makers, without meeting and travel expenses.

The Crypto Module Bootcamp brought students together with experts from academia, industry, government, standards bodies and laboratories for an exchange on topics including artificial intelligence, quantum computers, cryptography, entropy and much more. We wanted to make sure the students got a glimpse of what the world of IT security entails and showcase the variety of ways it touches our lives.

The event opened with a welcome address by atsec president and co-founder Sal La Pietra, followed by an introduction of the first recipient of the Bertrand du Castel Memorial Scholarship. Keynote speaker Professor Scott Aaronson took the stage with a very informative and entertaining presentation about the use of cryptography for Safe AI.

This was followed by a panel discussion on Safe AI and Secure Cyberspace with Prof. Scott Aaronson; NIST Fellow Dr. Lily Chen; Eric Hibbard, Head of US INCITS delegation for ISO/IEC JTC1/SC27; and the Director of NIAP, Jon Rolf. Dr. Yi Mao, atsec US CEO, moderated the panel discussion.

The event was perceived as a combination of mini ICMC and mini ICCC, with topics ranging from AI safety to the connected car. An attendee commented, “Its significance is far beyond cryptographic modules. It touched on many aspects for the future cryptographic standards and validation program.” You can find the complete line-up of speakers and panelists, as well as a list of the presentations here at the event website.

After a full day of presentations and discussions, the day ended with a tour of the beautiful Concordia University nature preserve. The overwhelmingly positive feedback and questions about making this a recurring event showed us that we are on the right track. We would like to thank Concordia University, the guest speakers, and all of the participants for making the first bootcamp such a success.

This event was also put together in memory of our friend and colleague, Dr. Betrand du Castel. His wife, Christine, gave a heartfelt speech commemorating his life. We invite you to read our blog article on Bertrand du Castel and his exceptional contributions to the field of smart card security. We took the opportunity to collect some deeply touching stories and insightful quotes from a few of Bertrand’s former colleagues and friends.

On behalf of Concordia University, who generously opened their campus for this event, we invite you to donate to their STEM program.

Donations can be made online at www.concordia.edu/giving/
Please put “du Castel” in the comments.

Or you can mail a check to:
Concordia University Texas
11400 Concordia University Drive
Austin, Texas 78726

For more information, please contact
April Kerwin at april.kerwin@concordia.edu or 512-313-5101

Happy Valentine's Day!

2024-02-14T01:00:00.002-06:00

Happy Valentine's Day to our customers, our partners, colleagues and communities around the world that we work with.

Happy Birthday, atsec!

2024-01-11T02:33:00.001-06:00

As always on the 11th of January atsec celebrates its birthday.
This year it is the 24th! As they say: time flies when you're doing IT security!
Our best wishes and thanks to all of the contributors: our customers, our partners, and our colleagues.

Merry Christmas and a Happy New Year from atsec

2023-12-21T11:44:00.002-06:00

The whole atsec team wishes our colleagues, customers, partners and suppliers a Merry Christmas and a Happy New Year.

CST Newsletter December 2023

2023-12-21T11:44:00.001-06:00

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.

A FIPS 140-3 compliant hybrid KEM algorithm

2023-12-04T14:44:00.022-06:00

Hybrid KEM - Kyber & X25519

In addition to the sole use of Kyber KEM, a hybrid mechanism using X25519 can be devised that acts as a drop-in replacement for Kyber KEM. In this case, a PQC algorithm is merged with a classic key establishment algorithm. The basis is the enhancement of the Kyber KEM encapsulation and decapsulation algorithms as follows.

When using the hybrid KEX algorithm, instead of the sole KEM encapsulation and decapsulation operations, the hybrid variants that are outlined in the subsequent subsections are used. In addition, the Kyber KEX data along with the X25519 data is exchanged in the same manner as outlined for the standalone Kyber KEX. Thus, the KEX operation is not re-iterated here.

The presented algorithm ensures that even if one algorithm is compromised, the resulting shared secret is still cryptographically strong and compliant with the strength of the uncompromised algorithm. However, it is to be noted that Kyber may have a cryptographic strength of up to 256 bits when using Kyber 1024. On the other hand, the cryptographic strength of X25519 is significantly lower - between 80 and 128 bits - depending on the analysis approach.

Hybrid KEM Key Generation

As part of the hybrid KEM key generation, the following steps are performed:

Generation of the Kyber key pair yielding the Kyber pk_kyber and sk_kyber.
Generation of the X25519 key pair yielding the X25519 pk_x25519 and sk_x25519.

Both public keys and both secret keys are maintained together so that every time the hybrid KEM requires a public key, the Kyber and X25519 public keys are provided. The same applies to the secret keys.

Thus the following holds:

pk_hybrid = pk_kyber || pk_x25519
sk_hybrid = sk_kyber || sk_x25519

Both, pk_hybrid and sk_hybrid are the output of the hybrid KEM key generation operation.

Hybrid KEM Encapsulation

The hybrid KEM encapsulation applies the following steps using the input of the hybrid KEM public key pk_hybrid:

Invocation of the Kyber encapsulation operation to generate the Kyber shared secret ss_kyber and the Kyber ciphertext ct_kyber using the pk_kyber public key presented with pk_hybrid.
Generation of an ephemeral X25519 key pair pk_x25519_e and sk_x25519_e.
Invocation of the X25519 Diffie-Hellman operation with the X25519 public key pk_x25519 provided via pk_hybrid and the ephemeral secret key sk_x25519_e. This generates the shared secret ss_x25519.
Secure deletion of the sk_x25519_e ephemeral secret key.
The operation returns the following data:
- Public data: ct_hybrid = ct_kyber || pk_x25519_e
- Secret data: ss_hybrid = ss_kyber || ss_x25519

The data ct_hybrid is to be shared with the peer that performs the decapsulation operation.

On the other hand ss_hybrid is the raw shared secret obtained as part of the encapsulation operation and must remain secret. It is processed with a KDF as outlined in section Hybrid KEM Shared Secret Derivation below.

Hybrid KEM Decapsulation

The hybrid KEM decapsulation applies the following steps using the input of the hybrid KEM secret key sk_hybrid and the public data resulting from the hybrid KEM encapsulation operation ct_hybrid.

Invocation of the Kyber decapsulation operation to generate the Kyber shared secret ss_kyber by using ct_kyber present in ct_hybrid and the Kyber secret key sk_kyber found in sk_hybrid.
Invocation of the X25519 Diffie-Hellman operation with the X25519 secret key sk_x25519 provided via sk_hybrid and the ephemeral public key pk_x25519_e provided via ct_hybrid which returns the shared secret ss_x25519.

The operation returns the following data:

Secret data: ss_hybrid = ss_kyber || ss_x25519

The data of ss_hybrid is the raw shared secret obtained as part of the encapsulation operation and must remain secret - it is the same data as calculated during the encapsulation step. It is processed with a KDF as outlined in the section Hybrid KEM Shared Secret Derivation below.

Hybrid KEM Shared Secret Derivation

To obtain a shared secret of arbitrary length that can be used as key material, a key derivation function is used as allowed by SP800-56C rev 2 section 2:

The chosen and KDF is based on SP800-108 rev 1.
In addition, the input to the KDF is formatted such that the entire hybrid KEM construction is compliant with SP800-56C rev 2 assuming that Kyber KEM is the approved algorithm and X25519 provides an auxiliary key agreement mechanism. Thus, section 2 of SP800-56C rev 2 with its requirement Z' = Z || T is fulfilled by defining the "standard" shared secret Z is provided by Kyber and that the auxiliary shared secret T is provided by X25519.

Considering that Kyber uses SHAKE / SHA-3 in its internal processing, the selected KDF is KMAC256 as defined in SP800-108 rev 1. KMAC is invoked as follows:

        KMAC256(K = ss_hybrid,
                X = ct_hybrid,
                L = requested SS length,
                S = "Kyber X25519 KEM SS")

When considering the structure of ss_hybrid and ct_hybrid, the KDF operates on the following specific data:

        KMAC256(K = ss_kyber || ss_x25519,
                X = ct_kyber || pk_x25519_e,
                L = requested SS length,
                S = "Kyber X25519 KEM SS")

The KMAC customization string S is selected arbitrarily and can contain any string including the NULL string.

The result of the KDF is intended to be usable as key material for other cryptographic operations. That derived key material now contains the individual security strengths of both Kyber and X25519. Both algorithms are used such that any security break of either algorithm will not impact the strength of the resulting shared secret of the respective other. By concatenating the individual shared secret values as input into the KDF, the result of the KDF will have the security strength of one algorithm even if the respective other algorithm is broken.

Hybrid KEX Algorithm

Using the hybrid KEM algorithm outlined in the preceding subsections, the hybrid KEX algorithm as specified in the documentation of the secure connection approach can be obtained by the following considerations: use of the Kyber KEX approach outlined at the beginning, but apply the following changes:

Replace all occurrences of pk with pk_hybrid.
Replace all occurrences of sk with sk_hybrid.
Replace all occurrences of ss with ss_hybrid.
Replace all occurrences of ct with ct_hybrid.
Replace all invocations of the Kyber standalone functions (key generation, encapsulation, decapsulation) with their respective hybrid variants outlined above.

This implies that the hybrid KEM as well as the hybrid KEX algorithms are usable as a direct drop-in replacement for the standalone Kyber algorithm use case. The only difference is that the resulting data is larger as it contains the X25519 data as well.

You can download a PDF version of the process here.

An implementation of both hybrid KEM and hybrid KEX is provided here.

PQC: Kyber and Dilithium - State of the (Draft) Standards

2023-11-17T10:45:00.075-06:00

by Stephan Mueller

On August 24 2023 NIST published the first drafts of:

FIPS 203 specifying Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM) which is based on CRYSTALS Kyber;
FIPS 204 specifying Module-Lattice-Based Digital Signature (ML-DSA) which is based on CRYSTALS Dilithium; and
FIPS 205 specifying Stateless Hash-Based Digital Signature (SLH-DSA) which is based on SPHINCS+.

On November 15 2023 NIST announced that the three algorithms will be available for testing at the ACVP Demo service. During the course of the development of both Kyber and Dilithium reference implementations, NIST developers reached out to atsec to compare intermediate results of both algorithms with implementations available to atsec. This comparison covered all data calculated during the intermediate steps of the processing, including:

Kyber:

all steps of the key generation processing of ML-KEM.Keygen and K-PKE.KeyGen;
all steps of the key encapsulation processing of ML-KEM.Encaps and K-PKE.Encrypt;
all steps of the key decapsulation processing of ML-KEM.Decaps and K-PKE.Decrypt;
ensuring that all Kyber types of ML-KEM-512, ML-KEM-768, and ML-KEM-1024 are subject to the comparison work.

Dilithium:

all steps of the key generation processing of ML-DSA.Keygen;
all steps of the key encapsulation processing of ML-DSA.Sign;
all steps of the key decapsulation processing of ML-DSA.Verify;
ensuring that all Dilithium types of ML-DSA-44, ML-DSA-65, and ML-DSA-87 are covered by the comparison analysis.

The implementation used by atsec was leancrypto, which was based on the Round 3 submission for CRYSTALS Kyber and CRYSTALS Dilithium at the time the collaboration with NIST was conducted. The NIST team as well as atsec identified several issues in the FIPS 203 and FIPS 204 draft standards, which are listed in their entirety below. The NIST team acknowledged that the respective issues will be eliminated in updates to both standards. This implies that developers using the current draft standards should be aware of those issues and upcoming modifications when basing their implementation on the respective FIPS draft standards.

The list of issues also shows their resolution at the time of writing. Please note that these updates are neither specified by the current standards nor endorsed by NIST yet. These changes were implemented in leancrypto and lead to consistent results compared to the implementations developed by NIST that are likely to be used as the ACVP reference implementations.

Kyber:

Algorithm 12 step 19 shows the dot-multiplication of the final part of the key generation: t = As + e. Step 19 specifies that AHat has to be used for the operation. However, in this step, the transposed version of AHat has to be used. This modification brings the FIPS 203 specification in line with the Round 3 submission of the CRYSTALS Kyber algorithm.

Dilithium:

The size of the private key for Dilithium types is by 256 bits larger. This is due to the enlargement of the size of the hash of the public key referenced as tr, which was not taken into account by the draft FIPS 204.
The size of the signature for ML-DSA-65 is larger by 128 bits and for ML-DSA-87 is larger by 256 bits. This is due to increase of the size of c-tilde in FIPS 204, which was not considered for the calculation of the signature size.
Algorithm 2 specifies the size of the signature as output to be B^(32....) which needs actually is B^((lambda / 4)...) due to the increase of the c-tilde variable. Note, this change is already applied to the auxiliary algorithm specifications given in chapter 8 of FIPS 204.
Algorithm 3 requires the same change for the specification of the input signature as given for Algorithm 2 above.

An implementation that is compliant with the NIST implementation that includes all the mentioned fixes is provided with leancrypto. It allows developers to compile both Kyber and Dilithium in a debug mode where the calculation results of each step of the key generation, Kyber encapsulation and decapsulation, as well as the Dilithium signature generation and verification can be displayed. This allows other developers to compare their implementation to match with leancrypto. The following steps have to be taken to obtain the debug output after fetching the library from the provided link and making sure the meson build system is available:

Kyber:

Setup of the build directory: meson setup build
Configure Kyber debug mode: meson configure build -Dkyber_debug=enabled
Compile the code: meson compile -C build
Execute the test tool providing the output of Kyber, ML-KEM-1024: build/kem/tests/kyber_kem_tester_c
To obtain the output for ML-KEM-768, enable it: meson configure build -Dkyber_strength=3
Compile the code: meson compile -C build
Execute the test tool providing the output of Kyber, ML-KEM-768: build/kem/tests/kyber_kem_tester_c
To obtain the output for ML-KEM-512, enable it: meson configure build -Dkyber_strength=2
Compile the code: meson compile -C build
Execute the test tool providing the output of Kyber, ML-KEM-512: build/kem/tests/kyber_kem_tester_c

Dilithium

Setup of the build directory (if it was not already set up for the Kyber tests): meson setup build
Configure Dilithium debug mode: meson configure build -Ddilithium_debug=enabled
Compile the code: meson compile -C build
Execute the test tool providing the output of Dilithium, ML-DSA-87: build/signature/tests/dilithium_tester_c
To obtain the output for ML-DSA-65, enable it: meson configure build -Ddilithium_strength=3
Compile the code: meson compile -C build
Execute the test tool providing the output of Dilithium, ML-DSA-65: build/signature/tests/dilithium_tester_c
To obtain the output for ML-DSA-44, enable it: meson configure build -Ddilithium_strength=2
Compile the code: meson compile -C build
Execute the test tool providing the output of Dilithium, ML-DSA-44: build/signature/tests/dilithium_tester_c

The test tool outputs is segmented into the key generation steps, Dilithium signature generation and verification steps, as well as Kyber encapsulation and decapsulation steps. The output specifies the mathematical operation whose result is shown. When displaying the output of a vector, one line is used. When displaying a matrix, the output of one row of the matrix is displayed per line. This implies that as many lines are printed as rows are present in the matrix.

The debug logging information was used as a basis for the discussion with the NIST development team to verify that both implementations i.e. the NIST reference implementation as well as leancrypto, correspond.

Considering that the FIPS 203 draft also specifies a minimum input validation in sections 6.2 and 6.3, those checks are implemented with leancrypto in the function kyber_kem_iv_sk_modulus. The other checks requiring the size verification of the input data are implicit due to the used data types forcing the caller to provide exactly the required amount of data.

leancrypto can be found here: https://github.com/smuellerDD/leancrypto

atsec at the PCI Community Meeting 2023

2023-11-15T14:47:00.003-06:00

atsec participated in the PCI (Payment Card Industry) Security Standards Council 2023 Asia-Pacific Community Meeting held in Kuala Lumpur, Malaysia, on 15 and 16 November and hosted a booth.

atsec’s principal consultant Di Li provided a presentation on “Our 'Key' Experience in PIN Security / P2PE / FIPS 140-3.”

A short summary of the presentation is as follows:
Regarding key generation, the paper discusses the generation requirements and methods defined in each of the three standards, compares the differences, and provides a rationale for why each standard requires a different approach. The section on key distribution and key establishment explores the different methods of securely transferring a key from one party to another. The paper defines each of these methods and provides common scenarios where they apply. The paper also provides several methods for key destruction, such as physical destruction, and logical cryptographic zeroization.

atsec at the International Common Criteria Conference 2023

2023-10-31T09:29:00.002-05:00

As in previous years, atsec is attending the International Common Criteria Conference, this time in Washington DC from October 31st to November 2nd 2023.

We invite you to come and talk to us at our booth (#10) or attend our colleagues' contributions to the conference:

CC:2022 – How it Compares and Differs from CC3.1R5 (L21b) - Trang Huynh
Challenges in the Adoption of CC:2022 for Protection Profiles, PP Modules and Functional Packages (A22a) - Alejandro Masino
Panel Discussion: Evolution of the Cryptographic Standards Ecosystem (M22b) - Yi Mao et al.
MDM Server Certification Without NIAP’s MDM PP (D23b) - Michael Vogel

Happy Halloween!

2023-10-31T01:00:00.001-05:00

Cybersecurity Requirements for Medical Devices

2023-10-13T11:57:00.016-05:00

On September 26, 2023, The Food and Drug Administration (FDA) released their finalized Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions guidance document. This document provides general principles for device cybersecurity relevant to device manufacturers. It seeks to emphasize the importance of safeguarding medical devices throughout a product's life cycle. The guidelines are going beyond security risk management and cybersecurity testing; the guidance recommends that device manufacturers leverage security controls to achieve the outlined security objectives:

Authenticity, which includes integrity;
Authorization;
Availability;
Confidentiality; and
Secure and timely updatability and patchability.

It is expected that the premarket submissions would include information that describes how the above security objectives are addressed by and integrated into the device design.

The FDA guidelines clearly state that:
“While software development and cybersecurity are closely related disciplines, cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context to therefore demonstrate that the device has a reasonable assurance of safety and effectiveness.”

It is indeed expected that the security testing documentation should be submitted in the premarket submission and include:

Verification of the implemented security requirements
Effectiveness and adequacy of each cybersecurity risk control
Vulnerability testing, and
Penetration testing

Medical device security plays a crucial role in safeguarding people using these products and solutions as well as the healthcare organization. Specification of security requirements and provision of guidance to device manufacturers is welcome and very useful. However, it is important to have in mind that most medical devices are used in various geographic regions and must comply with multiple national regulations. FDA regulates medical devices in the U.S., whereas the European Medical Device Regulation (MDR) (EU) 2017/745 that entered into force in 2021 is applicable to any manufacturer seeking to market their medical devices in Europe. Therefore, harmonization of standards and requirements is very much welcome by the device manufacturers. On the other hand, there are initiatives to establish global standards and global certification schemes to assess cybersecurity of the medical devices.

The Institute of Electrical and Electronics Engineers (IEEE) has established a Medical Cybersecurity Certification Program that has been developed by the IEEE 2621 Conformity Assessment Committee (CAC), composed of stakeholders such as manufacturers, clinicians, FDA, test laboratories, cybersecurity solutions providers, and industry associations from around the world. The IEEE certification program is already applied to diabetes medical devices, and it will be extended to other devices. It provides:

Insights and adherence based on global, consensus-based industry standards
Knowledge of FDA submission criteria
Adherence to best practices
Identifying ways to mitigate cyber attacks

atsec is proud to be recognized as the first IEEE-recognized testing laboratory with a primary location in Stockholm, Sweden, and secondary locations in Munich, Germany, and Austin, Texas, U.S. The very first IEEE 2621 assessments of the medical devices are ongoing and planned to be finalized in Q4 2023.

“Over the years, atsec has been closely monitoring the development of security requirements in the medical device industry. When approached to become a lab for IEEE 2621, we enthusiastically. embraced the opportunity”, said Salvatore La Petra, President and Co-Founder of atsec information security.

If you are interested in performing evaluation of your medical device or have any questions regarding our evaluation services, please do not hesitate to contact us (info@atsec.com). We look forward to working with you.

IEEE corporate advisory group (CAG) members visiting atsec AB in Stockholm, Sweden, earlier in 2023.

The 11th International Cryptographic Module Conference

2023-09-20T10:40:00.007-05:00

The 11th International Cryptographic Module Conference (ICMC) started today. This year the conference is held from September 20th to 22nd 2023 at the Shaw Center in Ottawa Canada.

The conference itself kicked off with Yi Mao, CEO of atsec US, giving the opening speech. It featured our latest animation, which has become somewhat of a tradition for us:

Marcos Portnoi, Laboratory Director for atsec information security, wrote the welcome letter in this year's program:

Dear Participants,

It is my utmost honor to welcome you to the International Cryptographic Module Conference 2023 in the beautiful city of Ottawa. This edition of ICMC marks the 10th anniversary of the conference, which was launched by atsec in September 2013 with the goal of bringing the community involved in cryptographic modules together.

This year, we have over 90 presentations in nine tracks, including Certification Programs, Post-Quantum Cryptography, Random Bit Generators and Entropy, Crypto Technology, Payment Card Industry, Embedded/IoT, and Open-Source Cryptography. In this city founded on the power of trading and eventually becoming a technology hub, we will trade ideas and knowledge among members from industry, laboratories, government, academia: all of us who love a good talk about cryptography. And of course, since any sort of product this year needs to have a checkbox for Artificial Intelligence (AI)--and I mean any sort of product, from search engines to progressive corrective lenses to mattress softness regulators, and extra credit is granted if one can fit "generative AI" in the description--we also want to talk about it and we are bringing a panel with experts in AI to discuss the (hopefully concrete) applications of AI for our work.

It is always interesting to witness the evolution in the conference among the years. Last year at the ICMC for instance, the Entropy Source Validation (ESV) was newly launched and Stateful Hash-Based Signatures (HBS), even though approved, had incipient implementations, still not testable via ACVP. Today, the ESV is at full throttle and HBS has one of its algorithms, LMS, now fully testable via ACVP and recently awarded a CAVP algorithm certificate.

One topic that particularly excites me is Post-Quantum Cryptography (PQC), and this year's ICMC has many interesting presentations in the track dedicated to PQC. The understanding and use cases of HBS have evolved substantially and the industry is better equipped to propose optimizations in the form through which those alluring yet brittle algorithms may be reviewed and evaluated for compliance with the standards. We see these initiatives in the very active Cryptographic Module User Forum (CMUF) working groups.

Again, my warmest welcome and may we enjoy our time!

Marcos Portnoi, PhD.
Laboratory Director
atsec information security corporation

We are proud to work with the National Cybersecurity Center of Excellence (NCCoE) on shortening the FIPS queue through automation. Visit our colleagues at booth 200/202 to learn more.

This year, atsec colleagues are part of panel discussions and will be presenting on a variety of topics:

EFP/EFT Testing at Security Level 3 and 4 and Remote Testing Advocacy
Renaudt Nunez
Panel: Facing the Future: The Next ISO/IEC 19790
Yi Mao, et al.
Panel: Testing and Assessment for Quantum Safe Cryptography
Marcos Portnoi, et al.
Kyber and Dilithium Real Life Lessons
Stephan Mueller
Equivalence Classes in AES
David Cornwell
Filling the Gaps in FIPS Cryptography
Joachim Vandermissen
Panel: Bringing Crypto Compliance and Validation Testing Objectives
Together for FIPS 140-3
Yi Mao, Stephan Mueller, et al.
Attestation and FIPS: Past, Present and Future
Alessandro Fazio

Marcos Portnoi is also hosting the Post-Quantum Crypto track.

As always we are looking forward to interesting presentations, discussions and exchange between the vendors, labs, government entities and end users.

Artificial Intelligence in Evaluation, Validation, Testing and Certification

2023-09-11T15:28:00.039-05:00

by Gerald Krummeck, atsec information security GmbH

Everybody seems to jump on the AI bandwagon these days, “enhancing” their products and services with “AI.” It sounds, however, a bit like the IoT hype from the last decade when your coffee machine desperately needed Internet access. This time, though, there’s also some Armageddon undertone, claiming that AI would make our jobs obsolete and completely transform all sorts of businesses, including ours.
So, it comes as no surprise that atsec gets asked by customers, government agencies, and almost everybody communicating with us how we position ourselves on the use of AI in our work and how we deal with AI being used in the IT security environment of our customers and in all sorts of other areas as well.
First answer: Unfortunately, we don’t yet use it for authoring blog entries, so musing about the benefits and drawbacks of AI in our work still can ruin your weekend. 🙁
Second answer: For an excellent overview of how we deal with AI and what we expect from this technology, there is a brilliant interview with Rasma Araby, Managing Director of atsec AB Sweden:

Of course, AI is discussed within atsec frequently, as we are a tech company by nature. We analyze IT technologies for impacts on IT security and are eager to deploy new technologies for ourselves or introduce them to our customers if we believe they will be beneficial.

atsec’s AI policy foundation

Recently, we defined some basic policies on the use of AI within atsec. Those policies have two cornerstones:

First and foremost, we are committed to protecting all sensitive information we deal with, especially any information entrusted to us by our customers. We will not share such information and data with third parties and thus will not supply any such information in publicly available AI tools.
There are several reasons for this: Obviously, we would violate our NDAs with our customers if we send their information to a public server. Also, there is currently no robust way to establish trust in these tools, and nobody could tell you how such information would be dealt with. So, we must assume that we would push that information directly into the public domain. Even if we tried to “sanitize” some of the information, I would be skeptical that an AI engine would not be able to determine which customer and product our chat was about. The only way to find out would be to risk disaster, and we’re not in for that. Furthermore, sanitizing the information would probably require more effort than writing up the information ourselves.

The second cornerstone is not different from our use of any other technology: any technology is only a tool supporting our work. It won’t take any responsibility for the results.
We are using many tools to help our work, for example, to help us author our evaluation reports and to keep track of our work results, evidence database, etc. Such tools could be marketed easily as AI, but as the saying goes: “A fool with a tool is still a fool.” Our evaluators take responsibility for their work products, and our quality assurance will not accept errors being blamed on a tool. Tools are always treated with a good dose of mistrust. We always have humans to verify that our reports are correct and to assume responsibility for their contents. This will not be different with an AI tool. At atsec, our evaluators and testers will always be in ultimate control of our work.
With this framework, we are in a good position to embrace AI tools where they make sense and do not violate our policies. We are aware that we cannot completely avoid AI anyway, for example, when it “creeps” into standard software tools like word processors. AI-based tools helping our techies to re-phrase their texts for readability and better understanding might sometimes be an improvement cherished by our customers. 😀
We expect AI tools to help, for example, with code reviews and defining meaningful penetration tests in the foreseeable future . However, we currently do not encounter such tools that could be run in controlled, isolated environments to fulfill our AI policy requirements.

Correctness of AI, trust in AI engines

As already stated, we do not treat current AI engines as trusted tools we can blindly rely upon. This is based on the fact that the “intelligence” displayed in the communication by these engines comes mostly from their vast input, which is absorbed into a massive network with billions, even trillions of nodes. Most of the large language models used in the popular AI engines are fed by the Common Crawl database of Internet contents (refined into Google’s Colossal Clean Crawled Corpus), which increases by about 20 terabytes per month. This implies that input for the training of the engines cannot be fully curated (i.e., fact-checked) by humans, and it leaves lots of loopholes to inject disinformation into the models. I guess that every troll farm on the planet is busy doing exactly that.
The developers of these AI engines try to fight this, but filtering out documents containing “dirty naughty obscene and otherwise bad words” won’t do the trick. If your favorite AI engine doesn’t have quotes from Leslie Nielsen’s “The Naked Gun” handy, that’s probably why. Checking the AI’s “Ground Truths” against Wikipedia has its shortcomings, too.
Therefore, the AI engine companies use different benchmarks to test the AI engine output, with many of those outputs checked by humans. However, the work conditions of those “clickworkers” are often at a sweatshop level, which does not help to establish our trust in the accuracy and truthfulness of the results.
Therefore, if atsec would use such engines in its core business of assessing IT products and technology, we would not be able to put a reasonable amount of trust in the output obtained from these engines and it would require us to fact-check each statement made by the AI. This might easily result in more effort than writing the reports ourselves and trusting our own judgment.
Note that the accuracy of AI answers being between 60 and 80 percent depending on the subject tested in the benchmarks, together with the problems of poisoning the input, how to establish “truthfulness” of the AI, and ethical and philosophical questions about which information to provide are topics in the EU and US efforts to regulate and possibly certify AI engines. Unfortunately, while the problems are well known, their solutions are mostly not. AI researchers across the globe are busily working on those subjects, but my guess is that those issues may be intrinsic to today’s large language models and cannot be solved in the near future.

Offensive AI

A common Armageddon scenario pushed by AI skeptics is that big AI engines like the ones from OpenAI, Microsoft, Google, Meta, and others will help the evil guys find vulnerabilities and mount attacks against IT infrastructures much easier than ever. After almost 40 years in IT security, that doesn’t scare me anymore. IT security has been an arms race between the good and bad guys from the very beginning, with the bad guys having an advantage as they only need to find one hole in a product, while the good guys have the task of plugging all holes.

As history teaches us, the tools used by the bad guys can and will be used by the good guys too. Tools searching for flaws have been used by hackers and developers alike, although developers were at times more reluctant to adopt them. AI will be no different, and maybe it will help developers to write more robust code, for example, by taking on the tedious tasks of thorough input and error checking, which are still among the most prominent causes of software flaws. Will atsec deploy those tools as well for their evaluations and testing? While we will certainly familiarize ourselves with those tools and might add them to our arsenal, it will be much more beneficial for developers to integrate those tools in their development and test processes, subjecting all of their code to that scrutiny as soon as the code is written or modified, rather than having a lab like atsec deploying those tools when the product may already be in use by customers.
We have always advocated, in standards bodies and other organizations creating security criteria, that the search for flaws should be conducted within the developer’s processes and that the lab should verify that these searches for flaws and vulnerabilities are performed effectively in the development environment. This is also true for AI tools.

Summary

The hype about AI tools that started with the public availability of ChatGPT less than a year ago has already reached its “Peak of Inflated Expectations” (according to Gartner’s “hype cycle” model) and is on its way to the “Trough of Disillusionment.” The yet-to-come “Slope of Enlightenment” will lead to the “Plateau of Productivity,” when we finally have robust AI tools at our disposal, hopefully, combined with a certification that provides sufficient trust for their efficient deployment. In any case, atsec will monitor the development closely and offer to participate in the standardization and certification efforts. AI will become an integral part of our lives, and atsec is committed to helping make this experience as secure as possible.

Entropy Source Validation (ESV) Certificate Issued for the Intel DRNG

2023-08-18T13:51:00.003-05:00

by Marcos Portnoi

Recently the CMVP has granted ESV certificate #E57 to the Intel DRNG entropy source. The testing and submission was done by atsec and it marks the first ESV certificate granted to the Intel DRNG.

The Intel DRNG (Digital Random Number Generator) is a hardware Random Bit Generator (RBG) integrated into a multitude of Intel processors, and offers both an entropy source and an SP800-90A DRBG to users of the processors. The DRNG is commonly accessed through the well-known RDRAND and RDSEED processor instructions. There is massive use of those instructions, such as in the Linux kernel, and the ESV certificate is a key step in facilitating the use of the entropy source in FIPS 140-3 validated modules.

Intel Corporation commented: "Today's US Government Cyber Security standards are highly complex. With the increasingly critical urgency for better security for cryptographic products comes the need for greater technical expertise along with the ability to navigate government standards. Despite extremely complex designs, atsec collaborated with Intel Corporation to obtain Intel's first Entropy Source Validation certificate which can be viewed on the NIST website."

The design of the Intel DRNG includes compliance with SP800-90A, SP800-90B and the upcoming new version of SP800-90C.

The ESV certificate covers the components compliant with SP800-90B. The ESV program rolled out in April 2022 and facilitates validation through two key points: confering a certificate exclusively for the entropy source, allowing for the reuse of validated entropy sources by multiple module validations; and facilitating the validation process by providing an automated process and protocol, similar to the Automated Cryptographic Validation Protocol (ACVP). The CMVP has been reviewing the ESV submissions in a relatively quick cycle of about 6 weeks, including submission, review, comments and certification. The talented technical personnel of the CMVP are engaged in the review process, producing interesting comments, and in the dynamic evolution of the ESV program.

The certificate is available at https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/57.

First Post-Quantum Algorithm Certificate issued by CAVP

2023-07-20T08:02:00.001-05:00

By Joachim Vandersmissen

On July 14, atsec obtained the first validation certificate for a post-quantum cryptographic algorithm: A4204. We used the Automated Cryptographic Validation Protocol (ACVP) to verify the correctness of the LMS (Leighton-Micali Signature) key pair generation, signature generation, and signature verification implementations in the QASM Hardware Security Module, developed by Crypto4A Technologies. This milestone represents an important step in the ongoing transition from traditional public-key cryptography to quantum-resistant algorithms.

The LMS scheme is a digital signature scheme based on secure hash functions and Merkle trees. It was first published in 1995 by Leighton and Micali and is based on the famous one-time signature scheme proposed by Lamport in 1979. Among quantum-resistant public-key algorithms, these schemes provide a distinct advantage: the post-quantum security of the scheme relies exclusively on the security of the underlying hash function. No other number-theoretic hardness assumptions are required. This is very attractive, as all modern hash functions with an output size of more than 256 bits are believed to be quantum safe. However, there are also drawbacks. In particular, LMS is a stateful signature scheme. In other words, it maintains an internal state that must be protected in hardware. Still, the benefits of hash-based cryptography significantly outweigh the costs, which lead to LMS (and XMSS) being standardized by NIST in 2020 (SP 800-208).

In May 2022, SP 800-208 was added to SP 800-140C, which specifies the algorithms approved for usage in FIPS 140-3 cryptographic modules. This also paved the way for LMS and XMSS to be tested by the Cryptographic Algorithm Validation Program (CAVP). The CAVP verifies the correct implementation of cryptographic algorithms and their components. Initial support for the LMS scheme was added in March 2023 and made available for production usage in April. We would like to thank the CAVP for their diligent work and excellent support to make this achievement possible.

Quantum computers represent a significant risk to classical public-key cryptography, a risk which cannot be ignored. Last year, the Commercial National Security Algorithm (CNSA) Suite 2.0 was published, which envisions a complete transition to post-quantum cryptography by 2033. We applaud Crypto4A Technologies for its proactive approach to offer this quantum-resistant signature scheme to its customers well ahead of the deadline.

The IoT Security Global Certification Challenges

2023-07-17T11:35:00.002-05:00

by Rasma Araby

In today's interconnected world, the Internet of Things (IoT) has become an integral part of our daily lives. From smart homes to industrial automation, IoT devices are revolutionizing various industries. However, with this increased connectivity comes the need for robust security measures to protect sensitive data and ensure the integrity of these devices.

The Importance of IoT Security
As IoT devices continue to proliferate, the potential risks and vulnerabilities associated with them also increase. These devices collect and transmit vast amounts of data, making them attractive targets for cybercriminals. A breach in IoT security can have severe consequences, ranging from privacy breaches to physical harm.
Ensuring the security of IoT devices requires a comprehensive approach that includes both hardware and software security measures. One crucial aspect of IoT security is certification.

The Role of Certification in IoT Security
Certification plays a vital role in establishing trust and confidence in IoT devices. It provides assurance that a device meets specific security standards and has undergone rigorous testing to identify and mitigate potential vulnerabilities. However, achieving global certification for IoT devices poses several challenges.

Diverse Regulatory Landscape
The IoT industry operates on a global scale, and different countries have varying regulations and standards for IoT security. Obtaining certification that complies with multiple regulatory frameworks can be a complex and time-consuming process for manufacturers.
Rapidly Evolving Threat Landscape
Cyber threats are constantly evolving, and new vulnerabilities are discovered regularly. IoT devices need to be certified not only at the time of their release but also throughout their lifecycle to address emerging threats. This requires manufacturers to stay updated with the latest security standards and continuously update their devices accordingly.
Lack of Standardization
While there are existing security standards for IoT devices, there is still a lack of global standardization. Different certification bodies may have different criteria and processes, making it challenging for manufacturers to navigate the certification landscape.

Addressing the Challenges

To overcome the challenges associated with global certification for IoT security, collaboration between industry stakeholders, regulatory bodies, and certification organizations is crucial. Here are some steps that can be taken:

Harmonization of Standards: Efforts should be made to harmonize security standards across different regions to streamline the certification process.
Continuous Monitoring and Updates: Certification bodies should establish mechanisms to monitor and update certified devices to address emerging threats.
Education and Awareness: Manufacturers should be educated about the importance of certification and the steps involved in the process.
International Collaboration: Collaboration between regulatory bodies and certification organizations from different countries can help establish a unified approach to IoT security certification.

Conclusion
As the IoT continues to expand, ensuring the security of connected devices is of paramount importance. Global certification plays a crucial role in establishing trust and confidence in IoT devices. However, the challenges associated with certification need to be addressed through collaboration and standardization efforts.

IoT security was a pivotal discussion point covered at the GSMA M360 UK Mobile Security and Industries conference that took place on July 11-12, 2023. The GSMA M360 UK brought together industry security professionals to share best practice and industry corporation for enhanced security. Rasma Araby participated in the panel discussion “The security dynamics of the IoT ecosystems” and shared her insight on security requirements and certification of the IoT devices. Please see more information provided in the article published by Mobile World Live.