Happy Valentine's Day!

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

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.

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.

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.

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

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.

 

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!

Cybersecurity Requirements for Medical Devices

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.