PQC compliance is too late after shipment! Quantum-proofing measures considered from the perspective of secure boot and firmware updates (Japanese blog) Following the i.MX 94 and i.MX 95 , NXP has announced the MCX A5 family, which features a secure boot loader built into ROM that supports PQC ( Post-Quantum Cryptography) hybrid Secure Boot and Secure Firmware Update. NXP plans to continue expanding its range of PQC-compatible products.
NXP Announces New MCX A5 MCU to Simplify Secure Industrial Connectivity | NXP Semiconductors
Even though quantum computers are still under development and concrete attacks using quantum computers have not yet begun, adopting products with built-in PQC-compatible secure bootloaders now is extremely important, especially for equipment intended for long-term use, such as industrial equipment.
If you are considering addressing the issue later through a firmware update, in particular, you need to understand the significant limitations involved and what needs to be done at the time of product manufacturing to ensure PQC compliance.
Main reasons why PQC compliance is required
Here are three main reasons why PQC compliance is required from the product design stage.
Product lifecycles may overlap with the arrival of practical attacks by quantum computers . Industrial equipment, automotive equipment, medical equipment, etc., are sometimes used for more than 10 years. If these products have already been shipped by the time quantum computers become practical, countermeasures will be needed in the market afterward.
"Harvest Now, Decrypt Later" means that encrypted communication data obtained now could be decrypted in the future using future quantum computing capabilities. Especially for products requiring long-term confidentiality, responding after an attack has begun is too late.
Resource requirements can be very large and difficult to address later. Depending on the specific algorithm, PQC algorithms may have higher resource requirements (ROM, RAM, Flash, processing time, power) than conventional ECC/RSA algorithms, making later implementation difficult. If you plan to support PQC in the future, you need to ensure sufficient resources for PQC from the outset, in addition to meeting current product specifications.
The above are the commonly cited reasons, but based on the above alone, you might think, "If the data being handled doesn't pose much of a problem even if it's deciphered later, wouldn't it be better to design it with ample resources at the moment and then add PQC support later with a firmware update?"
However, in reality, there are significant constraints.
Issues with PQC support due to firmware update
The biggest constraint for later PQC compliance is,
"The 1st SBL (described later) must be made unrewritable."
"Firmware update images contain intellectual property (IP)."
That's the point.
The first SBL (First SBL) is related to Secure Boot.
Secure Boot is an essential security mechanism that verifies the integrity of the firmware (that it has not been damaged or tampered with) through signature verification before starting the firmware.
To do this, a Secure Bootloader (SBL) is required, which exists independently of the firmware being verified, runs before the firmware being verified starts, and performs signature verification.
In particular, the SBL that is executed first after system startup is referred to here as the 1st SBL, and this 1st SBL must be immutable. For the reason why, please refer to the section "The 1st SBL must not be overwritten" in the following article.
The basics of secure boot and secure (OTA) updates in MCUs (Japanese blog)
In other words, it is impossible to use ECC/RSA as the firmware verification algorithm by the 1st SBL at the time of product shipment, without a PQC-compatible algorithm, and then add support for a PQC-compatible algorithm later. If the firmware verification algorithm by the 1st SBL remains ECC/RSA, there is a risk that its signature will be forged and malicious firmware will be launched after quantum computers become practical.
The second point is that even if the data handled by the product itself is not a major problem when it is later deciphered, the product's firmware generally contains a lot of intellectual property (IP).
If the encryption algorithm of the firmware update image does not support PQC, there is a risk of IP leakage in the future due to the decryption of the contents of the firmware update image.
Furthermore, if the firmware update image's signature algorithm does not support PQC, there is a risk that the firmware update image's signature could be forged and malicious firmware could be loaded.
Based on the above, if we are considering future PQC support, it is reasonable to conclude that at a minimum, the firmware verification algorithm using the 1st SBL and the signing and encryption algorithms for the firmware update image must be PQC-compatible at the time of product manufacturing.
NXP products can solve the challenges of PQC compliance.
The MCX A5's Boot ROM integrates PQC-compatible secure boot functionality, allowing it to be used as the 1st SBL. Furthermore, this Boot ROM also includes support for PQC-compatible secure updates. Compared to placing the SBL on Flash, it also reduces the required Flash capacity.
Productizing PQC-compliant functionality requires verification of key management, signature infrastructure, manufacturing provisioning, OTA updates, authentication, performance evaluation, and standards compliance, necessitating a long preparation period. This is especially true for the 1st SBL, which, as mentioned earlier, cannot be updated, requiring even more rigorous verification.
As of the time of writing, the MCX A5 is not yet in mass production and is in the process of obtaining certification, but it is designed with the goal of obtaining PSA Level 3 and SESIP Level 3 third-party security certifications (NXP already has a track record of obtaining PSA/SESIP certifications for many products). After certification is obtained, documentation including the Security Target (a document that defines the evaluation target, security claims, requirements, scope, etc.) will be provided.
By utilizing the MCX A5's PQC-compatible secure boot integrated Boot ROM, along with NXP's toolset such as the MCUXpresso secure provisioning tool and MCUXpresso SDK , we can reduce the implementation and verification effort required for PQC-compatible secure boot and firmware updates.
Key points for selecting SESIP Level 3 certified products
One important point to note regarding SESIP certification is that even among products with the same SESIP Level 3 certification, the scope of functionality included in the certification can vary significantly from product to product. Therefore, it is crucial to check not only the SESIP certification level but also the contents of the Security Target document.
Documentation for certified products can be downloaded from the link below.
SESIP Certificates - TrustCB
For example, in NXP's SESIP Level 3 product, "MCX N94x / 54x / 23x SESIP Security Target Rev 1.1," Fig. 3 shows that the Certification Scope includes not only the SoC ROM, including Secure Boot, but also numerous security features, including the EdgeLock ® Secure Enclave (ELS S50) .
While some other companies' SESIP Level 3 certified products lack many of these security features , some logical scope products have obtained SESIP Level 3 certification with only lifecycle management and memory protection features.
Furthermore, NXP's SESIP Security Target includes mappings to security standards/regulations such as IEC 62443-4-2, which can be used to address these standards and similar requirements in future security standards/regulations.
As of the time of writing this article, the latest certified product, "i.MX RT700 SESIP Security Target Rev. 1.0," also includes mapping to the CRA's EU 2024/2847 Annex I Essential Cybersecurity Requirements.
Note: The document version names for Security Target mentioned above are current as of the time of writing and are subject to change. Furthermore, SESIP certification and mapping to security standards/regulations do not guarantee compliance with standards/regulations for the entire final product using NXP products. Integration at the final product level and additional measures as required may be necessary.
=========================
We are currently unable to respond to comments left in the "Comment" section of this post. We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us (Japanese Blog) " when making an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) Following the i.MX 94 and i.MX 95 , NXP has announced the MCX A5 family, which features a secure boot loader built into ROM that supports PQC ( Post-Quantum Cryptography) hybrid Secure Boot and Secure Firmware Update. NXP plans to continue expanding its range of PQC-compatible products.
NXP Announces New MCX A5 MCU to Simplify Secure Industrial Connectivity | NXP Semiconductors
Even though quantum computers are still under development and concrete attacks using quantum computers have not yet begun, adopting products with built-in PQC-compatible secure bootloaders now is extremely important, especially for equipment intended for long-term use, such as industrial equipment.
If you are considering addressing the issue later through a firmware update, in particular, you need to understand the significant limitations involved and what needs to be done at the time of product manufacturing to ensure PQC compliance.
(Reading time: 10 minutes)
i.MX RT Processors i.MX Processors MCX Security Japanese Blog
記事全体を表示
