Architecture and method for agile migration to quantum computing-resistant cryptography

Abstract

Digital hardware architecture containing elements for the protection of confidentiality, authenticity and integrity against quantum attacks, for which the invention includes: (CPU) (101); hardware based on a Chain of Trust (CoT) comprising: a hardware RoT (110), and a reconfigurable section for hosting post-quantum cryptographic accelerators (103) related to PQ (post-quantum) security; a non-volatile memory (NVM) (104); on-chip SRAM (126) and Flash (127) memories; and peripherals (120, 121,122,123,124,125), wherein the hardware RoT (110) comprises the following modules: a Hash-Based Signature (HBS) block (111); a control unit (112) for managing the RoT functions; and an immutable storage (113), which stores the information required for integrity verification purposes. The hardware RoT starts two processes: secure boot and secure reconfiguration, and in addition neither the CPU (101) nor other architecture blocks interfere with the internal operations of the hardware RoT.

Description

[0001] ARCHITECTURE AND PROCEDURE FOR AN AGILE MIGRATION TO QUANTUM-RESISTANT CRYPTOGRAPHY

[0002] DESCRIPTION

[0003] OBJECT OF THE INVENTION

[0004] The object of the present invention, as the title of the invention establishes, is, on the one hand, the digital hardware architecture to provide a secure crypto-agile and quantum computing-resistant processing element intended for embedded or embedded systems applications, as well as the method implemented in said architecture. The term crypto-agile applied to this invention is related to the ability to securely reconfigure a set of dedicated classical and post-quantum (PQ) cryptographic accelerators that can be used by a Central Processing Unit (CPU) within the architecture.

[0005] As a secure processing element, the presented architecture contains the necessary elements to provide security-related services resistant to quantum computer attacks to the applications in which it is incorporated, such as confidentiality, authenticity, and integrity protection. To this end, the invention includes reconfigurable post-quantum hardware accelerators and symmetric cryptography modules. Furthermore, the digital hardware architecture contains an immutable hardware root of trust. This element is the basis for the reliability of the security-related operations that will be executed within the digital hardware architecture.

[0006] This invention includes proposals that facilitate the replacement of one post-quantum cryptographic implementation with another, and the methods necessary to reconfigure those implementations in a cryptographically secure manner. The objectives behind the presented method and the crypto-agile digital hardware architecture are:

[0007] - Facilitate the migration of embedded systems to post-quantum cryptographic schemes.

[0008] - Enable secure, long-term implementation of post-quantum cryptography in embedded systems.

[0009] - Establish a secure processing environment where potential security vulnerabilities can be discovered before running any software.

[0010] - Act as a Root of Trust to: o Detect vulnerabilities in reconfigurable software and hardware. o Protect the device against such vulnerabilities. o Initiate secure cryptographic coprocessor updates.

[0011] BACKGROUND OF THE INVENTION

[0012] Currently established public-key cryptosystems will be compromised when quantum computers become available, as demonstrated by the algorithm proposed by Peter Shor in 1994. At the time of writing, there is no existing quantum computer capable of breaking current asymmetric cryptographic algorithms. However, recent reports [1, 2] estimate that a cryptographically relevant quantum computer (capable of breaking the widespread asymmetric RSA algorithm in a matter of hours) will be possible within the next decade.

[0013] Post-quantum cryptography has emerged as a solution to the threat of quantum computing. It is a set of quantum-resistant public-key cryptographic algorithms based on mathematical primitives different from those of current asymmetric schemes, and these mathematical primitives cannot be broken by a currently known quantum algorithm. NIST has selected a set of post-quantum algorithms for standardization [3-5].

[0014] Considering that public-key cryptosystems have historically taken almost two decades to implement, migrating to post-quantum cryptographic schemes is a huge challenge. In the most recent literature, the ability to migrate traditional cryptographic infrastructure and replace it with post-quantum cryptography is referred to as “cryptoagility”. In [6], Grote et al. explain the concept of cryptoagility applied to post-quantum cryptography as “the ability to continue using existing cryptographic methods and security protocols with adaptation for PQC”. That definition mainly focuses on the challenging migration from classical cryptographic schemes to quantum-resistant cryptography. However, as Alnahawi et al. mention in [7], cryptagility is a notion that has existed for over twenty years and should not be treated solely as a migration from one type of cryptographic schemes to others.Revisiting the concept of cryptoagility in the post-quantum era would ideally allow not only migration to post-quantum cryptography but also facilitate changes to an already implemented quantum-resistant algorithm. This would ensure data confidentiality and authentication in the event an algorithm or implementation is attacked, or if recommended security parameters or an algorithm are found to be insecure.

[0015] Possible changes within new post-quantum algorithms are not a far-fetched scenario, since these are young algorithms in the process of standardization. An example of this is the Key Encapsulation Mechanism (KEM) selected for standardization, CRYSTALS-Kyber. In the presentation of the KEM algorithm, the authors define the use of four different hash functions (SHA3-256, SHA3-512, SHAKE-128, and SHAKE-256). However, the authors proposed replacing all hash functions with cSHAKE-256 and SHAKE-128 during the fourth NIST PQC (Post-Quantum Cryptography) standardization conference [8]. It is common practice found in secure cryptographic elements to accelerate algorithms in hardware as much as possible. This is done by dedicated coprocessors or hardware accelerators connected to a main processing unit.The most efficient accelerators or coprocessors are physical hardware modules that are not expected to change after their implementation in the device. Noseda et al. evaluated a set of secure cryptographic elements for IoT with dedicated hardware accelerators in [9].

[0016] A less efficient but more flexible approach is the implementation of accelerators within reconfigurable logic. However, this requires expert knowledge of both RTL (Register Transfer Level) (Digital Electronics Design) and secure design implementation. This is due to the importance of side-channel attacks in cryptographic implementation, which can potentially leak secret information through electromagnetic emissions or power consumption. There are a large number of implementations of cryptographic hardware accelerators in reconfigurable logic, such as the hardware accelerators for post-quantum cryptography presented by Dang et al. in

[0010] ,

[0017] A wide range of devices uses these accelerators, from small IoT devices at the edge to more capable systems hosted on servers. Of course, acceleration rates and capabilities vary depending on the application. When it comes to applying and implementing physical hardware accelerators for post-quantum cryptography, cryptoagility must be one of the most important requirements. For example, a hardware accelerator integrated circuit for a post-quantum scheme could become unused due to major changes in a particular algorithm. This would lead to inefficient use of available hardware, resulting in the only option for implementing an algorithm being exclusively software, which is significantly slower.Most common vendors of field-programmable gate array (FPGA) systems currently allow users to embed their own hardware accelerators and protect the confidentiality and integrity of their digital designs. This is primarily done through the presence of physical blocks that provide this type of protection to the bitstream. For example, AMD's 7-series FPGAs use an embedded message authentication code (HMAC) and a physically implemented Advanced Encryption Standard (AES) module

[0011] . However, there are known attacks on these mechanisms to protect the bitstream of programmable logic, such as the work of Jacob et al. in

[0012] .

[0018] In the field of flexible and reconfigurable architectures, the solution proposed by Schiavone et al. in

[0013] stands out. The architecture contains a RISC-V microcontroller unit and an embedded FPGA (eFPGA) to provide flexibility in terms of reprogrammability. The architecture design is focused on low-power applications. Although it can be applied to different applications due to its flexibility, no method is provided to securely reconfigure the hardware accelerators to be implemented in the eFPGA. Furthermore, no root of trust is included on which the reconfiguration of a cryptographic accelerator intended for secure applications can rely.

[0019] Another flexible architecture incorporating an eFPGA is presented in the invention described in

[0014] by Douzane et al. The invention aims at adding reconfigurability to a security subsystem while ensuring compliance with the security and / or real-time requirements of, for example, automotive applications. Compared to the invention presented here, no protected or secure method for hardware reconfiguration is proposed. Moreover, the mentioned architecture lacks a root of trust for security-related operations on which the system reconfiguration could depend. In post-quantum implementations, the current trend towards flexible deployment of post-quantum cryptography is based on accelerating the most common primitives shared between those algorithms and modifying the main processor software that uses the accelerators. This is the approach followed by Karl et al.in

[0015] , where a chip is presented that includes a processor and post-quantum accelerators. Although the objective of the chip is to be able to switch between two different post-quantum digital signatures, if the underlying post-quantum schemes undergo a significant modification or redefinition, the accelerators of this chip would be rendered unusable. This highlights one of the main concerns of this invention with respect to the implementation of post-quantum cryptography hardware accelerators: providing the ability to adapt the PQC hardware accelerators to any modification that may be included, even replacing one scheme with another, and ensuring that the method for performing this modification is protected.

[0020]

[0001] L. Chen, S. Jordan, Y.-K. Li, D. Moody, R. Peralta, R. Perlner, and D. Smith-Tone, "Report on Post-Quantum Cryptography," NIST Interagency / Internal Report (NISTIR) 8105, National Institute of Standards and Technology, April 28, 2016. [Online], Available:

[0021] [2] F.K. Wilhelm, R. Steinwandt, D. Zeuch, and J. Frey, "Status of Quantum Computer Development," Federal Office for Information Security (BSI) Report, August 2023, Version 2.0. [Online], Available: https: / / www.bsi.bund.de / SharedDocs / Downloads / DE / BSI / Publikationen / Studien / Quantencomputer / Entwicklungstand_QC_V_2_0.pdf? blob=publicationFile&v =2

[0022] [3] National Institute of Standards and Technology (NIST), "FIPS 203 (Initial Public Draft): Module-Lattice-Based Key-Encapsulation Mechanism Standard," Federal Information Processing Standards Publication 203, Information Technology Laboratory, National Institute of Standards and Technology, Aug. 24, 2023. [Online], Available: https: / / doi.org / 10.6028 / NIST.FIPS.203.ipd [4] National Institute of Standards and Technology (NIST), "FIPS 204 (Initial Public Draft): Module-Lattice-Based Digital Signature Standard," Federal Information Processing Standards Publication 204, Information Technology Laboratory, National Institute of Standards and Technology, Aug. 24, 2023. [Online], Available: https: / / doi.org / 10.6028 / NIST.FIPS.204.ipd

[0023] [5] National Institute of Standards and Technology (NIST), "FIPS 205 (Initial Public Draft): Stateless Hash-Based Digital Signature Standard," Federal Information Processing Standards Publication 205, Information Technology Laboratory, National Institute of Standards and Technology, Aug. 24, 2023. [Online], Available:

[0024] [6] 0. Grote, A.Ahrens, and C. Benavente-Peces. “Paradigm of Post-quantum Cryptography and ' Crypto-agility: Strategy Approach of Quantum-safe Techniques:” in: Proceedings of the 9th International Conference on Pervasive and Embedded Computing and Communication Systems. SCITEPRESS - Science and Technology Publications, 2019, pp. 91-98. DOI: 10.5220 / 0008162800910098.

[0025] [7] N. Alnahawi et al., "On the State of Crypto-Agility," Cryptology ePrint Archive, Paper 2023 / 487, 2023. [Online], Available: https: / / ephnt.iacr.org / 2023 / 487

[0026] [8] P. Schwabe et al., "CRYSTALS-Kyber," presented at the NIST 4th PQC

[0027] Standardization Conference, Nov. 29, 2022, [Online], Available: https: / / csrc.nist.gov / csrc / media / Presentations / 2022 / crystals-kyber- update / images-media / session-1 -schwabe-crystals-kyber-pqc2022.pdf

[0028] [9] M. Noseda, L. Zimmerli, T. Schlapfer, and A. Rüst, "Performance Analysis of Secure Elements for loT," loT, vol. 3, no. 1 , pp. 1-28, 2022. [Online], Available: https: / / www.mdpi.eom / 2624-831X / 3 / 1 / 1. DOI: 10.3390 / iot3010001

[0029]

[0010] V. B. Dang, K. Mohajerani and K. Gaj, "High-Speed Hardware Architectures and FPGA Benchmarking of CRYSTALS-Kyber, NTRU, and Saber," in IEEE Transactions on Computers, vol. 72, no. 2, pp. 306-320, 1 Feb. 2023, doi: 10.1109 / TC.2022.3222954.

[0030]

[0011] AMD, "Bootgen User Guide (UG1283)," AMD Documentation, Oct. 18, 2023. [Online], Available: https: / / docs.xjlinx.eom / r / en-US / uq1283~bootqen-user~

[0012] N. Jacob, J. Heyszl, A. Zankl, C. Rolfes, and G. Sigi, "How to Break Secure Boot on FPGA SoCs Through Malicious Hardware," Aug. 2017, pp. 425-442, ISBN: 978-3-319-66786-7, DOI: 10.1007 / 978-3-319-66787-4_21 .

[0031]

[0013] P. D. Schiavone et al., "Arnold: an eFPGA-Augmented RISC-V SoC for Flexible and Low-Power loT End-Nodes," CoRR, vol. abs / 2006.14256, 2020. [Online], Available: https: / / arxiv.orq / abs / 2006.14256

[0032]

[0014] K. Douzane, C. Chillie, A. Lebrun, "A Secure Hardware Programmable Architecture," EP Patent 4052163B1 , Sep. 7, 2022. Assignee: Silicon Mobility SAS.

[0033]

[0015] P. Karl, J. Schupp, T. Fhtzmann, and G. Sigi, "Post-Quantum Signatures on RISC-V with Hardware Acceleration," ACM Trans. Embed. Comput. Syst., Jan. 2023. [Online], Available: https: / / doi.org / 10.1145 / 3579092

[0034] DESCRIPCIÓN DE LA INVENCIÓN

[0035] The object of the present invention is set forth in its essence in the independent claim and the different embodiments are set forth in the dependent claims.

[0036] The present invention relates to a method and digital hardware architecture for a secure processing element containing quantum-resistant hardware accelerators that can be securely reconfigured by a trusted server. This invention applies to the field of embedded systems intended for implementation in applications requiring specific long-term security services.

[0037] The invention consists of a method for securely modifying a cryptographic circuit using a specific hardware architecture capable of supporting migration to different cryptographic schemes, both classical and post-quantum solutions. The elements comprising the crypto-agile digital hardware architecture of this invention are as follows:

[0038] - A main processing unit (CPU) with an optional direct coprocessing interface to hardware accelerators. The processing unit may be able to extend its instruction set using hardware accelerators connected to the dedicated coprocessing interface, if present.

[0039] - A hardware based on a Chain of Trust (CoT) with a minimum of two components:

[0040] • An immutable hardware Root of Trust (RoT) responsible for the following functions: o Authenticating the first CPU boot firmware. o Authenticating and authorizing firmware updates. o Authenticating and authorizing updates to cryptographic hardware accelerators. o An immutable in-memory storage, hosting the required cryptographic material.

[0041] • A reconfigurable section to host PQ (post-quantum) cryptographic accelerators related to secure applications. To enable cryptoagility and interchangeability between different PQ algorithms and implementations, this is implemented in an embedded field programmable gate array (eFPGA).

[0042] • The only possible access to the reconfiguration port of this eFPGA is through the hardware RoT, to ensure that security-related coprocessors are only updated through authenticated update mechanisms based on immutable hardware.

[0043] • This reconfigurable section is not expected to be accessed by an end user. Updates to PQ cryptographic hardware accelerators will be managed by a trusted third-party entity or server, also responsible for the development of such accelerators.

[0044] - A dedicated non-volatile memory (NVM) for storing data or configuration files related to the reconfigurable PQ accelerators and the first executable code of the CPU. This memory can only be accessed through the hardware RoT.

[0045] - On-chip SRAM and Flash memories, related to the main execution of the CPU.

[0046] - Peripherals. This set of peripherals must include symmetric cryptographic schemes designed to guarantee confidentiality. Further details are presented in the Preferred Implementation section.

[0047] Unit of

[0048] The main Processing Unit is an important element of the architecture, as it is the only element that could have access to the reconfigurable section, i.e., the post-quantum cryptographic accelerators once configured in the dedicated eFPGA. Furthermore, the CPU is the entity that executes the instructions of a specific user software application that will be programmed or loaded into the architecture.

[0049] One embodiment could select a CPU that can only access the PQC accelerators on the eFPGA via its system bus. In fact, this is the most typical situation when it comes to hardware accelerators that offload time-consuming tasks from the CPU. They are often called loosely coupled accelerators. The processing unit will communicate with the accelerators to command or request various operations, and the accelerators will perform the desired tasks autonomously. This is optimal when the amount of data used for the operations is high or when a certain level of parallelization can be achieved in hardware. However, the achievable acceleration rate is limited by the latency of memory accesses.

[0050] Another embodiment could choose a CPU that contains an interface compatible with tightly coupled accelerators. In this type of embodiment, the CPU leverages a direct interface that connects the PQC accelerators located on the eFPGA to the internal architecture of the processing unit. In this way, the accelerator can act as if it were integrated into the processing unit, accelerating instruction-level operations and moving data to and from the processor registers. When optimized, this may be the fastest way to accelerate operations. However, this approach may not be suitable for accelerating a significant amount of data because there would be an overhead in the instructions required to exchange data with the system memory.

[0051] There is also the possibility that an implementation could achieve the combined use of tightly coupled and loosely coupled accelerators. However, it should also be noted that the resources available on the eFPGA dedicated to PQC accelerators are limited. Thus, the number of accelerators dedicated to one type or another may be limited by the available area because they will share the same eFPGA.

[0052] Hardware RoT

[0053] The entire trust of the digital hardware architecture is based on the included immutable hardware RoT. In each startup process, the first block executed is the hardware RoT. Therefore, it is the block responsible for building a Chain of Trust by authenticating the reconfigurable hardware and the first executable software of the main CPU. Another key aspect that highlights the importance of this block is that it enables the main objective of the architecture, which is to achieve chip agility in the implementation of a secure processing element resistant to quantum attacks. The hardware RoT will be the only functional block with direct access to the on-chip non-volatile memory (NVM) dedicated to storing the configuration data necessary to configure the eFPGA that will host the post-quantum cryptography accelerators.Furthermore, it is the only entity with direct access to the reconfiguration port of that eFPGA, ensuring that there are no other means to reconfigure tightly and loosely coupled PQC accelerators.

[0054] The immutable hardware RoT contains the following three main blocks:

[0055] - Immutable storage, which will include the elements necessary for integrity verification.

[0056] - A physically implemented quantum-resistant digital signature verifier.

[0057] - A Control Unit (CU) responsible for performing the tasks necessary to verify the integrity of the data to be reconfigured.

[0058] The hardware RoT initiates two processes that ensure the integrity of the mutable hardware (eFPGA) and the platform's first mutable software: the secure boot process and the secure reconfiguration process.

[0059] It's important to note that neither the CPU nor other architecture blocks can interfere with the internal operations of the hardware RoT. At system startup, the RoT begins operations as the master of the on-chip bus to which it has access. It will only power on those other blocks it needs to use, while the main CPU will remain off. Furthermore, when a hardware reconfiguration is requested externally, the main CPU will transfer control to the hardware RoT, as it is the only block with direct access to this memory.

[0060] Post-quantum cryptographic accelerators (eFPGAs)

[0061] As mentioned above, one of the key aspects of the architecture is access to post-quantum cryptographic accelerators that can be reconfigured when necessary. This underlies the proposed concept of extended chptoagility, in terms of enabling long-term deployment of quantum-resistant cryptographic accelerators.

[0062] Therefore, to allow the modification or replacement of one PQC accelerator with another, they must be implemented in reconfigurable logic within the proposed architecture. This is achieved through the availability of an integrated FPGA (eFPGA) in the architecture, which provides the reconfigurable cells for the PQC accelerators.

[0063] As described in the architecture overview, the architecture can contain two reconfigurable sections. This means hosting two different eFPGA instances. In that case, the PQC accelerator eFPGA will be physically separated and isolated from the other eFPGA instance, represented as the user eFPGA.

[0064] The reconfiguration and implementation of the user-facing eFPGA section will be entirely managed by the architecture's end user. In contrast, the eFPGA instance for PQC accelerators will only be reconfigured through a secure hardware reconfiguration flow controlled by the architecture's hardware RoT.

[0065] After securely reconfiguring the eFPGA PQC accelerator unit and ensuring the integrity of the first boot instructions executed on the CPU via the secure boot flow, the processing unit will be granted access to the reconfigurable PQC accelerators. After this event, the processing unit can use the PQC accelerators through the aforementioned tightly or loosely coupled interfaces.

[0066] The reconfigurability of the eFPGA instance of PQC accelerators not only enables the desired chptoagility in terms of migrating from one algorithm to another, but also provides the ability to modify the internal architecture of quantum-resistant accelerators to add countermeasures against side-channel attacks. Side-channel attacks aim to reveal secret or sensitive data by acquiring time, power, or electromagnetic field measurements from a hardware or software implementation of a cryptographic function.

[0067] Therefore, protection against such attacks is also applicable to the field of post-quantum cryptography, as the algorithms themselves may be resistant to quantum attacks, but the implementation may unintentionally leak protected information. Although a thorough analysis of potential side-channel leaks is necessary before implementing any PQC accelerator in the architecture, the reconfigurability of the eFPGA instance for PQC accelerators allows for an additional countermeasure against a novel or undetected side-channel attack.

[0068] The method for using this architecture includes a secure boot flow for the architecture, as well as a secure reconfiguration process. Both procedures ensure the integrity of the hardware and software accelerators running on the platform.

[0069] Safe boot process

[0070] The Digital Hardware Architecture secure boot process has the following objectives:

[0071] - Verify the integrity of the configuration data associated with the PQC accelerators and configure them on the eFPGA.

[0072] - Ensure that the software running on the processing unit is legitimate from the first boot instructions to the end-user application. This process runs every time the platform is restarted or started and cannot be bypassed in any way. Process security is anchored in the hardware RoT embedded in the architecture. This ensures that the behavior described in this flow is always the same, regardless of the mutability of the PQC and software accelerators.

[0073] To enable the Secure Boot flow, one of the key aspects is performing code signing on-premises by the manufacturer or developer. Code signing refers to the process of digitally signing any software before installing it on a device.

[0074] In the context of the presented architecture, code signing must involve not only the software that will run on the processing unit but also the configuration data representing the PQC hardware accelerators. Optionally, the code signing process may include encryption of the signed data or payload. In addition to code signing the configuration data of the post-quantum cryptography hardware accelerators, the software developed to be installed on the architecture is also signed. This process may involve multiple public and private key pairs. In this case, a dependency structure would be established between the keys used in each verification phase, such that one key pair verifies the next key pair to be used (and the metadata), and so on.

[0075] Process of

[0076] One of the key aspects of the architecture is the secure reconfiguration flow, which in turn implements the desired cryptoagility in terms of reconfiguration of hardware accelerators and software applications. The invention highlights the importance of securely reconfiguring hardware accelerators rather than software applications. This section provides information on how this flow is achieved.

[0077] The hardware reconfiguration process is initiated by an authorized and trusted entity external to the platform architecture. This entity would be the platform provider, as it is the only agent capable of developing and providing the configuration data associated with reconfigurable post-quantum cryptographic accelerators.

[0078] On the architectural side, the immutable hardware that makes up the RoT enforces a Secure Reconfiguration process that involves authenticating the source requesting the reconfiguration. In fact, the architecture relies on an authenticated update mechanism to securely reconfigure hardware accelerators.

[0079] To ensure the confidentiality, authenticity, and integrity of the secure hardware reconfiguration process, the following aspects are taken into account:

[0080] - All data related to secure hardware reconfiguration must arrive encrypted to the device, with a symmetric secret key shared between the trusted entity and the digital hardware architecture.

[0081] - Additionally, a digital signature is added to the hardware reconfiguration data to demonstrate the authenticity of the source.

[0082] - After the hardware reconfiguration data is authenticated and decrypted by the architecture, a new secret key can be derived to store the data in the on-chip NVM configuration.

[0083] - Although it is part of the immutable storage in the hardware RoT, the public key or hash of the public key that will be used in the secure hardware reconfiguration is different from the one used during the secure boot flow.

[0084] - The PQC accelerator configuration bits and their associated metadata contain information about the implementation of hardware-accelerated security-related quantum-resistant features.

[0085] The hardware reconfiguration data will have a fixed format. It cannot be changed due to the immutable behavior of the hardware RoT responsible for decoding this data.

[0086] Unless otherwise indicated, all technical and scientific elements used herein have the meaning commonly understood by one of ordinary skill in the art to which this invention pertains. Methods and materials similar or equivalent to those described herein can be used in the practice of the present invention.

[0087] Throughout the description and claims, the word "comprises" and its variants are not intended to exclude other technical features, additives, components, or steps. For those skilled in the art, other objects, advantages, and features of the invention will be apparent in part from the description and in part from the practice of the invention.

[0088] EXPLANATION OF THE FIGURES

[0089] To complement the description being made and in order to help better understand the characteristics of the invention, in accordance with a preferred example of practical implementation thereof, a set of drawings is attached as an integral part of said description, in which the following has been represented for illustrative and non-limiting purposes.

[0090] Figure 1 shows the block diagram of the digital hardware architecture described, which represents the elements comprising the invention. Figure 2 shows the flowchart of the secure boot process for the digital hardware architecture.

[0091] In Figure 3 we can see the diagram of the steps performed during the secure hardware reconfiguration process of the presented invention.

[0092] PREFERRED EMBODIMENT OF THE INVENTION.

[0093] A preferred embodiment of the proposed invention is described below in view of the figures.

[0094] In Figure 1 we can see a block diagram of the digital architecture, which includes:

[0095] - A CPU (101 ),

[0096] - A hardware RoT (110) (Root of Trust) which is an intrinsically trustworthy physical element, constituting a base on which the security and trust of the architecture is built. It is connected to the CPU (101) through a dedicated communications bus.

[0097] - Post-Quantum cryptography accelerators PQC (103), which receive instructions from the RoT Hardware (110) and are connected to the CPU (101)

[0098] - An NVM memory (104) (Non-Volatile Memory)

[0099] - Peripherals connected to the central processing unit (101),

[0100] Where the RoT hardware (110) comprises the following modules:

[0101] - A Hash-Based Signature (HBS) block (111), which implements only the digital signature verification part. HBS signatures have been shown to be resistant to quantum attacks. In fact, NIST (National Institute of Standard Technologies) in its special publication SP 800-208 adds some recommendations to the already standardized stateful HBS schemes LMS and XMSS. As the security of these schemes depends on the security of the underlying hash functions, and it is believed that hash functions will not be threatened by the development of large-scale quantum computers, having an immutable HBS verifier is considered the best approach to compose the immutable RoT. To allow reconfiguration of post-quantum cryptographic accelerators, the configuration data of the hosting eFPGA and the CPU boot instructions must be digitally signed.This way, the authenticity and integrity of that data can be guaranteed when the digital signature verification process is successful.

[0102] - A control unit (112) to manage the functions of the RoT hardware.

[0103] - An immutable storage (113), which stores the information required for integrity verification purposes (e.g., the public key for digital signature verification or its hash value). It is important to note that, regardless of the physical cells used for immutable storage, the allocated memory size is very limited. There is no requirement to retain large amounts of data or information in immutable storage.

[0104] There are two possible options for implementing post-quantum cryptography accelerators (103) for the architecture: tightly coupled accelerators and loosely coupled accelerators.

[0105] - In this sense, a tightly coupled accelerator is one that has a direct interface connected to the CPU to extend the instruction set, thus achieving the highest possible acceleration rate. This type of accelerator is suitable when there is some dependence on the data exchanged with the CPU.

[0106] - A loosely coupled accelerator interacts with the main CPU via an on-chip bus, and therefore adds some latency to the acceleration rate. However, when there is a reasonable amount of data to be transferred and / or the operations applied by the accelerator can be parallelized with other CPU tasks, this is a useful approach.

[0107] The dedicated NVM non-volatile memory (104) for storing configuration data related to the post-quantum reconfigurable accelerators and the first executable code of the CPU is only accessible via the hardware RoT.

[0108] Other peripherals consist of:

[0109] - On-chip sensors (120) that provide a level of protection against manipulation by a physical attacker

[0110] - A True Random Number Generator (TRNG) (121 ) to support cryptographic algorithms. It is included in the architecture as an entropy source for the operation of various post-quantum algorithms. This is also useful for implementing countermeasures against side-channel attacks by masking data with random numbers. The ability to acquire randomness from physical phenomena in the architecture can be useful for various user applications running on the CPU.

[0111] - A SRAM (126) (Static Random Access Memory) memory unit, which means static random access memory (or static RAM),

[0112] - A Flash memory unit (127)

[0113] - A direct memory access (DMA) unit (122) to perform data movement tasks between memory and peripherals

[0114] - Symmetric cryptographic modules (123), which are physically implemented to accelerate various symmetric primitives, such as MAC and encryption / decryption. Symmetric encryption and decryption provide confidentiality to the data on which these operations are applied if the underlying secret key is protected. This feature is useful for ensuring the confidentiality of PQC accelerators' configuration data, which is a critical asset of the architecture. Hash modules are very common in classical and post-quantum cryptographic algorithms as a building block, so it is important to also accelerate hash operations in hardware.

[0115] - General Purpose Peripherals (124) accessible by the CPU to communicate externally with other devices or interfaces.

[0116] - An additional eFPGA for implementing user-reconfigurable logic (125). o The accelerators or logic implemented on this eFPGA can be referred to as loosely coupled because they do not have a direct interface to the CPU. o The primary goal is to allow users to use this architecture in a wide range of applications by allowing the implementation of custom logic. o This eFPGA instance is expected to have direct input / output connections to provide more flexibility.

[0117] Figure 2 shows the secure boot flow for this architecture. The steps represented are as follows: a. Reading the PQC accelerators configuration data (201 ): This is the process of finding and processing the first image to be verified, which is the configuration data representing the PQC accelerators. This image is stored in the non-volatile memory NVM (104) which is only accessible by the Control Unit (112). b. Verifying (202) the digital signature of the configuration data: The Control Unit (112) provides the configuration data to the HBS verifier (111 ) to perform the digital signature verification. In addition, it provides the public key required to perform the verification, which is located inside the immutable storage (113). This step may require the use of some symmetric cryptography modules (123) and the TRNG (121 ).o If the signature verification passes, the next step is reached, o If it fails, the Control Unit forces a restart of the process. c. Programming (203) of the eFPGA with PQC accelerators: Once the configuration data has been verified, the Control Unit loads it into the eFPGA dedicated to hosting the PQC accelerators. d. Reading the boot instructions (204): The Control Unit (112) then reads the first executable instructions for the main processing unit (101). e. Verification (205) of the digital signature of the boot instructions: This is the same process performed in step (b), but directed at the boot firmware. It is also commanded by the Control Unit (112) and verified by the HBS verifier (111). To perform the signature verification, the Control Unit provides a public key to the verification module. Presumably, this public key would be authorized by the public key used in step (b).Additionally, it might require access to symmetric cryptographic modules and TRNG. f. Releasing (206) the CPU reset state and executing the boot instructions: After the first boot instructions of the processing unit have been verified, they are stored in a location accessible to the main processing unit. The Control Unit, if necessary, could provide the processing unit with the address of the first instruction specifying the reset vector. It then releases the CPU reset, and this element will start executing the verified instructions. g. Performing (207) successive verifications of the following executable software: As the boot firmware itself is executable software and is already verified, it has enough capabilities and confidence to continue verifying the next boot stage from scratch to the end-user application.At each step, the trusted software running on the processing unit will verify the digital signature of the next one to be executed and so on, building a Chain of Trust (CoT). h. End-user application execution (208): After each executable software has been verified, the processing unit executes the final application and provides the services required by that application.

[0118] The secure reconfiguration flow is a main part of the method. It is detailed in Figure 3. The steps to follow are as follows: a. Establishment (301) of a session key with the server. The initial step to enable a secure hardware reconfiguration is to authenticate the initiator of the update (e.g., a trusted server) and establish a session key with it to encrypt all data exchanged between the architecture and the server. This will be achieved using an authenticated key exchange algorithm. It is important to achieve authentication on both sides. This means that not only the architecture needs to authenticate the trusted server, but also the server side must ensure that the client (i.e., the architecture) is legitimate. The session key agreed between the two parties will be updated each time the secure reconfiguration process is initiated. b.Processing the request on the CPU (302): After the hardware reconfiguration request reaches the architectural boundaries and a session key has been established, the CPU processes this request and stores the relevant data in memory, which is accessible by the hardware RoT. c. Decrypting (303) hardware reconfiguration data: The hardware RoT initiates secure reconfiguration operations by reading the encrypted update data from memory. From this point on, all platform operations are blocked and the hardware RoT takes control of the architecture. It then decrypts the hardware reconfiguration data using pre-provided symmetric keys and the available symmetric modules of the architecture. d. Verifying (304) the hardware reconfiguration data.In this step, the architecture performs all the required checks to ensure that it is safe to perform the hardware reconfiguration based on the data provided with the request. If an error is detected in any of the checks performed, the hardware reconfiguration request will be canceled. e. Configuration (305) of the non-volatile memory NVM: The non-volatile memory (NVM) is loaded with the new hardware reconfiguration data that has already been verified. Thus, upon a new boot of the architecture, the PQC accelerators will be programmed with the new contents of the Configuration NVM. f. Platform reset (306): After programming the NVM configuration, a restart of the platform operation is necessary for the hardware reconfiguration to take effect. Since the hardware RoT controls the reset signal for the rest of the architecture modules, it is the entity responsible for activating this signal. g.Executing (307) the Secure Boot Flow: The last step is to execute the secure boot process explained above, to ensure the architectural integrity state after the secure hardware reconfiguration flow.

[0119] Having sufficiently described the nature of the present invention, as well as the manner of putting it into practice, it is noted that, within its essence, it may be put into practice in other embodiments that differ in detail from the one indicated as an example, and to which the protection sought will also be achieved, provided that it does not alter, change or modify its fundamental principle.

Claims

CLAIMS 1.- Architecture for an agile migration to quantum computing-resistant cryptography characterized by comprising: - A main processing unit (CPU) (101 ) - A hardware based on a Chain of Trust (CoT) with a minimum of two components: • An immutable hardware RoT (110) (Root of Trust) responsible for the following functions: o Authenticating the first CPU boot firmware. o Authenticating and authorizing firmware updates. o Authenticating and authorizing updates to post-quantum cryptography hardware accelerators. o An immutable memory storage, hosting the required cryptographic material. • A reconfigurable section for hosting post-quantum cryptographic accelerators (103) related to PQ (post-quantum) security. To enable cryptoagility and interchange between different PQ algorithms and implementations, this is implemented in an embedded field programmable gate array (eFPGA), where, • The only possible access to the reconfiguration port of this eFPGA is through the hardware RoT, • Updates to PQ cryptographic hardware accelerators will be managed by an external entity or server. - A dedicated non-volatile memory (NVM) (104) for storing configuration data related to the PQ reconfigurable accelerators and the first executable code of the CPU. This memory can only be accessed by the hardware RoT (110), - On-chip SRAM (126) and Flash (127) memories, related to the main execution of the CPU. - Peripherals (120, 121, 122, 123, 124, 125), where this set of peripherals includes symmetric cryptographic modules to guarantee the confidentiality property. where the hardware RoT (110) comprises the following modules: - A Hash Based Signature (HBS) block (111), which implements only the digital signature verification part. - A control unit (112) to manage the functions of the RoT. - An immutable storage (113), which stores the information required for integrity verification purposes The Hardware RoT initiates two processes that guarantee the integrity of the mutable hardware and the first mutable software of the platform, which are the secure boot process and the secure reconfiguration process. In addition, neither the CPU (101) nor other architecture blocks interfere with the internal operations of the Hardware RoT, so that when starting the system, the Hardware RoT begins its operations as master of the on-chip bus to which only those other blocks that it requires to use have access. The main CPU will remain off and in addition, when a hardware reconfiguration is requested externally, the main CPU will pass control to the Hardware RoT, being the only block with direct access to the non-volatile memory that contains the configuration data. 2.- Architecture for an agile migration to quantum computing-resistant cryptography according to claim 1, characterized in that the CPU only accesses the PQC accelerators in the eFPGA through its system bus, that is, they are weakly coupled accelerators. 3.- Architecture for an agile migration to quantum computing resistant cryptography according to claim 1 characterized in that the CPU contains a interface compatible with tightly coupled accelerators by leveraging a direct interface that connects the PQC accelerators located on the eFPGA to the internal architecture of the processing unit. 4.- Architecture for an agile migration to quantum computing resistant cryptography according to claim 2 and 3 characterized in that the CPU (101) makes a combined use of tightly coupled and loosely coupled accelerators. 5.-Architecture for agile migration to quantum computing resistant cryptography according to any of the preceding claims, characterized in that it comprises other peripherals that are: - On-chip sensors (120) that provide a level of protection against manipulation by a physical attacker - A True Random Number Generator (TRNG) (121) to support cryptographic algorithms. This architecture can be useful for various user applications running on the CPU. - A SRAM (126) (Static Random Access Memory) memory unit, which means static random access memory (or static RAM), - A Flash memory unit (127) - A direct memory access (DMA) unit (122) to perform data movement tasks between memory and peripherals - Symmetric cryptographic modules (123), which are physically implemented to accelerate various symmetric primitives, such as MAC and encryption / decryption. - General Purpose Peripherals (124) accessible by the CPU to communicate externally with other devices or interfaces. - An additional eFPGA to implement user reconfigurable logic (125). 6.- Procedure for an agile migration of cryptography resistant to quantum computing using the system according to any of claims 1 to 5, wherein the secure boot process comprises the following steps: a. Reading the configuration data of the PQC accelerators (201) where the first image to be verified is searched for and processed, which corresponds to the configuration data contained in the PQC accelerators, where said image is stored in the non-volatile memory NVM (104) which can only be accessed by the Control Unit (112). b. Verification (202) of the digital signature of the configuration data where the Control Unit (112) provides the data to the HBS verifier (111) to carry out the verification of the digital signature, in addition, it provides the public key required to carry out the verification, which is located within the immutable storage (113). o If the signature verification passes, the next step proceeds.English: o If it fails, the Control Unit will force a restart of the process. c. Programming (203) of the eFPGA with PQC accelerators: once the configuration data has been verified, the Control Unit loads it into the eFPGA dedicated to hosting the PQC accelerators, d. Reading the boot instructions (204): Then, the Control Unit (112) reads the first executable instructions for the main processing unit (101 ), e. Verification (205) of the digital signature of the boot instructions: this is the same process performed in step (b), but targeted at the boot firmware. It is also commanded by the Control Unit (112) and verified by the HBS verifier (111 ), where in order to perform the signature verification, the Control Unit provides a public key to the verifier module, where this public key would be authorized by the public key used in step (b). f.Release (206) from the CPU reset state and execute the start instructions: after the first ones have been verified. English: processing unit startup instructions are stored in a location accessible to the main processing unit. g. Performing (207) successive verifications of the next executable software: As the boot firmware itself is executable software and is already verified, it has enough capabilities and trust to continue verifying the next boot step from scratch to the end-user application. At each step, the trusted software running on the processing unit will verify the digital signature of the next one to be executed and so on, building a Chain of Trust. h. Executing end-user application (208): After each executable software has been verified, the processing unit executes the final application and provides the intended services. 7.- Procedure for an agile migration to cryptography resistant to quantum computing according to claim 6, characterized in that the verification stage (202) of the digital signature of the configuration data of the PQC hardware accelerators requires the use of symmetric cryptography modules (123) and the TRNG (121). 8.- Procedure for an agile migration to quantum computing resistant cryptography according to claim 6 or 7, characterized in that the verification step (205) of the digital signature of the boot instructions requires access to symmetric cryptographic modules and TRNG. 9.- Procedure for an agile migration to cryptography resistant to quantum computing according to claim 6 or 7 or 8, characterized in that in the stage of releasing (206) the reset state of the CPU and executing the start instructions, the Control Unit provides the processing unit with the address of the first instruction specifying the reset vector, then releases the reset of the CPU, and this element will continue executing the verified instructions.

10. A method for agile migration to quantum-resistant cryptography using the system according to any one of claims 1 to 5, wherein the secure reconfiguration process comprises the following steps: a. Establishment (301) of a session key with the server, which is achieved by means of an authenticated key exchange algorithm, it being important to achieve authentication on both sides, and where the session key agreed between the two parties will be updated each time the secure reconfiguration process is started. b. Processing the request on the CPU (302): after the hardware reconfiguration request reaches the architectural limits and a session key has been established, the CPU processes this request and stores the relevant data in memory, which can be accessed by the RoT hardware. c.Decrypt (303) hardware reconfiguration data, where the hardware RoT initiates secure reconfiguration operations by reading the encrypted update data in memory. From this moment on, all platform operations are blocked and the hardware RoT takes control of the architecture, then, it decrypts the hardware reconfiguration data using previously provided symmetric keys and the available symmetric modules of the architecture. d. Verification (304) of the hardware reconfiguration data, in this step, the architecture performs all the required checks to ensure that it is safe to perform the hardware reconfiguration based on the data provided with the request and if an error is detected in any of the checks performed, the hardware reconfiguration request will be canceled. e. Configuration (305) of the non-volatile memory NVM: The non-volatile memory (NVM) is loaded with the new hardware reconfiguration data that has already been verified. Thus, on a new boot of the architecture, the PQC accelerators will be programmed with the new contents of the Configuration NVM. f. Reset (306) of the platform: After programming the NVM configuration, it is necessary to restart the platform operation for the hardware reconfiguration to take effect. Since the hardware RoT controls the reset signal for the rest of the architecture modules, it is the entity responsible for triggering this signal. g. Execution (307) of the secure boot flow: The last step is to execute the secure boot process explained above, to ensure the integrity state of the architecture after the secure hardware reconfiguration flow.

Images