Friday, March 1, 2024

Crypto Module Bootcamp 2024

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

Wednesday, February 14, 2024

Happy Valentine's Day!

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

Thursday, January 11, 2024

Happy Birthday, atsec!

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.

Thursday, December 21, 2023

Merry Christmas and a Happy New Year from atsec

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

CST Newsletter December 2023


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.

Monday, December 4, 2023

A FIPS 140-3 compliant hybrid KEM algorithm


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:

  1. Generation of the Kyber key pair yielding the Kyber pk_kyber and sk_kyber.
  2. 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:

  1. 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.
  2. Generation of an ephemeral X25519 key pair pk_x25519_e and sk_x25519_e.
  3. 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.
  4. 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.

  1. 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.
  2. 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:

  1. Replace all occurrences of pk with pk_hybrid.
  2. Replace all occurrences of sk with sk_hybrid.
  3. Replace all occurrences of ss with ss_hybrid.
  4. Replace all occurrences of ct with ct_hybrid.
  5. 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.

Friday, November 17, 2023

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

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:

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

Dilithium

  1. Setup of the build directory (if it was not already set up for the Kyber tests): meson setup build
  2. Configure Dilithium debug mode: meson configure build -Ddilithium_debug=enabled
  3. Compile the code: meson compile -C build
  4. Execute the test tool providing the output of Dilithium, ML-DSA-87: build/signature/tests/dilithium_tester_c
  5. To obtain the output for ML-DSA-65, enable it: meson configure build -Ddilithium_strength=3
  6. Compile the code: meson compile -C build
  7. Execute the test tool providing the output of Dilithium, ML-DSA-65: build/signature/tests/dilithium_tester_c
  8. To obtain the output for ML-DSA-44, enable it: meson configure build -Ddilithium_strength=2
  9. Compile the code: meson compile -C build
  10. 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

Wednesday, November 15, 2023

atsec at the PCI Community Meeting 2023

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.


 

Tuesday, October 31, 2023

atsec at the International Common Criteria Conference 2023

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!