Secure hardware programmable architecture
By defining specific security subsystems within the FPCU component and leveraging flexible logic units and hardware accelerators to extend security capabilities, the conflict between security function upgrades and real-time requirements in long-life products is resolved, achieving forward-looking protection against future security challenges.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SILICON MOBILITY SAS
- Filing Date
- 2020-10-28
- Publication Date
- 2026-06-05
AI Technical Summary
Existing technologies struggle to effectively upgrade security features in long-life products, and encryption algorithms demand high processing resources, leading to a conflict between real-time and security requirements and failing to effectively address complex security challenges.
By defining specific security subsystems within the FPCU component, leveraging flexible logic units and hardware accelerators to extend the capabilities of these subsystems, state-of-the-art encryption and anti-hacking features are achieved. Virtual boundaries and protection units ensure a balance between security and real-time performance.
It provides forward-looking solutions to future security challenges, ensuring that the security subsystem is synchronized with the real-time system, preventing hacking, and improving the security and functional security of components.
Smart Images
Figure CN114616566B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of digital control of power systems, and more specifically, to (but not limited to) the control of powertrain components (such as motors, and also including DC / DC converters) in the electrical systems of pure electric or hybrid vehicles that require hard real-time and secure control. This invention relates to providing the highest level of security features to address current and future security challenges, applicable to the aforementioned application areas with the highest levels of functional safety standards. This invention combines state-of-the-art encryption and anti-hacking capabilities with on-chip programmable hardware and accelerators. Background Technology
[0002] This invention applies to an electrical arrangement (also known as an FPCU), comprising: multiple functional modules, and an interconnect architecture that connects the functional modules and provides communication between them, wherein one or more of the functional modules are hardware programmable units, which are programmable logic matrices.
[0003] This invention relates to providing security by enabling the (long-term) use (as a functional module) of a specific security subsystem characterized by state-of-the-art encryption and anti-hacking capabilities in this type of FPCU component, which is essentially characterized (as other functional modules):
[0004] • Several CPU cores, with standard on-chip program and data memory.
[0005] A subsystem is characterized by multiple peripheral devices surrounding one or more flexible logical units, which may optionally be capable of task switching and spatial isolation.
[0006] In the emerging context of connected vehicles, these types of applications are increasingly affected by security issues related to the following:
[0007] • Preventing hackers from taking control of vehicles
[0008] • Protect the firmware update process when using "wireless" update scenarios
[0009] • Protect the software IP running on the FPCU
[0010] • Check firmware integrity (to prevent hacking and electrical damage)
[0011] Until recently, security management was conducted through a central "bridge," which was the only system directly connected to the outside world (e.g., a connection to the cloud). This bridge was responsible for all security scenarios. Consequently, all other electronic systems were hidden behind it.
[0012] Currently, vehicle network architecture is shifting towards a more decentralized approach. This means that any computing resources in a vehicle may be directly connected to external networks to some extent, and therefore more critical resources such as powertrain controllers may also be directly connected to external networks.
[0013] Therefore, the requirement for handling security scenarios becomes mandatory in any computing component.
[0014] As mentioned earlier, security is becoming increasingly critical in vehicle applications. Therefore, next-generation electronic components and architectures must provide the necessary functionality to handle security scenarios and countermeasures against security attacks.
[0015] Many commercial solutions cover these elements well, and these solutions properly handle currently known security features.
[0016] However, the security field is evolving very rapidly. Hacking techniques are becoming increasingly sophisticated, and encryption standards are constantly evolving. For example, some widely used encryption algorithms that theoretically require the equivalent of thousands of years of computation to crack by modern computers may be broken in minutes by future quantum computers. This is a critical issue in the automotive sector, where components have significantly longer lifespans than in other sectors (such as consumer electronics). This means that security subsystems must be able to meet new security challenges for 10 years or more.
[0017] This invention is particularly focused on FPCUs, primarily targeting hard real-time applications with the highest functional safety requirements (ASIC-D), and is designed to provide best-in-class levels of real-time and safety performance.
[0018] state-of-the-art solutions
[0019] Regarding the flexibility of security features, a typical answer to the previous challenges was to integrate the CPU core into the security subsystem. Therefore, security functions can be upgraded via software updates.
[0020] However, this strategy has the following limitations, making it unacceptable for the vehicle applications we are targeting:
[0021] This strategy is ineffective for long-lifecycle products because the required CPU power cannot be accurately predicted in advance. Therefore, we end up investing more CPU power than necessary, resulting in an unacceptable impact on equipment costs.
[0022] • Encryption algorithms require significant processing resources (hardware SHA processing time is 10 times longer than hardware processing time), and in the worst-case scenario, some future encryption algorithms may not be able to run on the processing resources already available.
[0023] This approach has very limited applicability to countermeasures, as these often depend on hardware resources.
[0024] Regarding balancing security and real-time aspects with security, common approaches include adding software stacks that can synchronize the activities of real-time and security systems and implement arbitration strategies that allow for security countermeasures while ensuring functional safety behavior.
[0025] Again, reaction time is an issue here.
[0026] In fact, necessary software should know the current real-time state of the system in order to make appropriate decisions at the appropriate time.
[0027] However, in the best-in-class FPCU systems targeted as the benchmark, hard real-time algorithms are executed within a real-time processing subsystem (characterized by some hardware-programmable flexible logic units) without any fine-grained synchronization with the CPU core. In any case, the CPU's speed is insufficient to synchronize with hardware activity.
[0028] The purpose of this invention
[0029] This invention aims to add a forward-looking security subsystem to the aforementioned architecture, while avoiding a situation where this security function conflicts with (best-in-class) real-time and / or security requirements, especially if the security subsystem might interpret security-related faults as security attacks (e.g., human intervention on the clock or power supply). Therefore, the security subsystem can apply countermeasures to prevent hacking (e.g., cutting off communication via the CAN port). This is clearly a very dangerous decision… Summary of the Invention
[0030] This invention relates to providing the highest level of security features for current and future security challenges at the highest level of functional safety standards by defining a specially adapted architecture within components of this type of FPCU.
[0031] Therefore, the present invention relates to providing security by enabling the (long-term) use (as a functional module) of a specific security subsystem characterized by state-of-the-art encryption and anti-hacking capabilities within such an FPCU type component, and more specifically, by means of efficiently extending the capabilities of the security subsystem so that the FPCU component is prepared for long-term security challenges.
[0032] In a first aspect, the present invention provides an electrical structure comprising: (a) a functional module capable of functioning as both a transaction initiator and a transaction target, such that the transaction initiating functional module may require the transaction target functional module to perform functions for and on its behalf; and (b) a first interconnect architecture connecting the functional modules and providing communication between them; wherein the (electrical) structure is arranged such that a selected transaction initiating functional module is capable of temporary exclusive access to one or more transaction target functional modules for and on its behalf to ensure that uncontrolled access to it is not possible by transaction initiating functional modules other than the selected transaction initiating functional module, wherein the selected transaction initiating functional module is a hardware security module.
[0033] In a second aspect, the present invention provides a secure transaction mechanism, wherein transaction initiation modules other than a selected transaction initiation module are accessible via a first interconnect architecture only after the other transaction initiation modules initiate a service request to the selected transaction initiation module to configure a protection unit connected to such other transaction initiation modules that are correspondingly approved by the selected transaction initiation module.
[0034] In a third aspect, the present invention provides various interconnection structures and considerations related to the foregoing. Attached Figure Description
[0035] Figure 1 (0100) illustrates a conventional FPCU architecture (without a flexible hardware security module).
[0036] Figure 2 (0200) provides an exemplary use of the concept of the present invention.
[0037] Figure 3 (0300) explains the trigger hardware management architecture within the FPCU component, which relates to specific security considerations to be ensured according to the present invention.
[0038] Figure 4 (0400) describes the relationship with Figure 3 (0300) Related use cases.
[0039] Figure 5 (0500) relative to Figure 3 (0300) and Figure 4 (0400) introduces the concept of virtual boundaries.
[0040] Figure 6 (0600) Explain the typical interconnection structure in the FPCU in relation to specific considerations for ensuring security according to the present invention.
[0041] Figure 7 (0700) describes another use case related to hardware security modules that utilize peripheral resources.
[0042] Figure 8 (0800) relative to Figure 7 (0700) introduced the concept of virtual boundaries.
[0043] Figure 9 (0900) This invention is explained in the context of matrix switching and appropriate mechanisms for achieving security. Detailed Implementation
[0044] The present invention relates to an (electrical) structure comprising: (a) functional modules that can function as both transaction initiators and transaction targets, such that the transaction initiating functional module may require the transaction target functional modules to perform functions for and on behalf of it; and (b) a first interconnect architecture connecting the functional modules and providing communication between them; wherein the (electrical) structure is arranged such that the selected transaction initiating functional module is capable of (temporary) exclusive access to (one or more) transaction target functional modules that perform functions for or on behalf of it, to ensure that transaction initiating functional modules other than the selected transaction initiating functional module cannot (via the interconnect architecture) obtain uncontrolled access to it.
[0045] Typically, the selected transaction initiation module is a hardware security module (e.g., with encryption capabilities).
[0046] The present invention specifically relates to an (electrical) structure comprising: (a) a functional module that can function as both a transaction initiator and a transaction target, such that the transaction initiating functional module may require the transaction target functional module to perform functions for and on its behalf; and (b) a first interconnect architecture that connects the functional modules and provides communication between them; characterized in that, in order to ensure that the selected transaction initiating functional module can have (temporary) exclusive access to (one or more) transaction target functional modules that perform functions for or on its behalf, protection means are provided to ensure that transaction initiating functional modules other than the selected transaction initiating functional module cannot (via the interconnect architecture) obtain uncontrolled access to it.
[0047] In an embodiment of the present invention, the protection means includes: one or more protection units provided for each of the transaction target functional modules (between the module and a portion of the first interconnection structure); thereby the configuration of the protection units is controlled (directly or indirectly) by the selected transaction initiation functional module (wherein the protection units provide transaction filtering).
[0048] In embodiments of the present invention, transaction initiation function modules other than the selected transaction initiation function module can only be accessed via the first interconnection structure (and thus access is controlled) after the other transaction initiation function modules initiate a service request to the selected transaction initiation function module to configure the relevant protection unit that is approved accordingly.
[0049] In an embodiment of the (electrical) structure of the present invention, one or more protection units are further connected by a second interconnect architecture for configuring these protection units, thereby providing additional protection units between the first and second interconnect architectures; and the configuration of the additional protection units is controlled (directly or indirectly) by the selected transaction initiation function module.
[0050] In an alternative embodiment of the (electrical) structure of the invention, one or more protection units are further connected via one or more second interconnect architectures for configuring these protection units, such that one or more additional protection units are provided between the first and second interconnect architectures; and the configuration of the additional protection units is controlled (directly or indirectly) by the selected transaction initiation function module.
[0051] In embodiments of the invention, an (electrical) structure is provided, wherein a first interconnect architecture connects functional modules and provides communication between these functional modules, the first interconnect architecture including a third interconnect architecture for exchanging task-specific trigger signals between the functional modules, the third interconnect architecture including a trigger router module capable of routing any input trigger to any output trigger, the trigger router module being adapted to ensure that transaction initiating functional modules other than selected transaction initiating functional modules cannot access them uncontrolled via the third interconnect architecture, preferably, the trigger router module being configurable via a second interconnect architecture (while for the other remaining portions of the first interconnect architecture, a protection unit is provided between the other remaining portions and the functional modules).
[0052] In embodiments of the invention, an (electrical) structure is provided, wherein a first interconnect architecture connects functional modules and provides communication between these functional modules, the first interconnect architecture including a fourth interconnect architecture that includes direct connections between (a portion of) the functional modules, thereby ensuring that transaction initiating functional modules other than selected transaction initiating functional modules cannot gain uncontrolled access to (one or more) modules performing functions for or on behalf of them via the fourth interconnect architecture (by accordingly configuring protection units associated with these transaction initiating functional modules).
[0053] Now based on Figure 1The present invention is illustrated by the conventional FPCU architecture shown in (0100) (without a flexible hardware security module), which includes:
[0054] (0101): One or more conventional processor cores. In this FPCU component, the processor cores are dedicated to the application portion that does not require hard real-time processing.
[0055] • (0102): One or more flexible logic unit matrices. Each of them is optionally capable of task switching.
[0056] ·(0103): Multiple sensor / actuator and hardware accelerator peripherals.
[0057] • (0104): "Hardware security module" (according to Evita terminology). This is a conventional security subsystem characterized by:
[0058] ο Local processor kernel and associated security firmware
[0059] Multiple encryption hardware accelerators.
[0060] Multiple protection agencies to prevent hacking attacks
[0061] (0105): This is the physical boundary of the security subsystem. This concept is important in that it clearly defines the communication channel between the security domain and the application domain. Within this boundary, all hardware content is strictly reserved for the secure computing unit (such as the CPU, but FLU is also possible) and cannot be accessed from other computing units (CPU or others) of the component.
[0062] (0106): An arbitrarily complex interconnected network that allows different types of communication between system elements (bus communication, interrupts, triggers, etc.).
[0063] As explained above, the latest software-based solutions do not properly address these issues.
[0064] Therefore, the inventive concept of this invention concerns extending the “boundaries” of the HSM module by utilizing existing flexible logic units and / or mathematical accelerators present in the (so-called AxEC) subsystem. This resource allocation is intended to be dynamically performed at runtime so that AxEC resource usage can adapt to any field conditions.
[0065] Figure 2 (0200) Explain this concept with examples.
[0066] In this example:
[0067] • The functionality of the conventional security module (0201) is extended by using a partition of the FLU (0202) and / or (preferably both) a hardware accelerator (0203).
[0068] • Due to the dedicated mechanism (0204) in the interconnect structure (explained further), the above elements are reserved for HSM use. This means that these resources are "invisible" to any host in the SOC except for the HSM itself.
[0069] Therefore, the effective physical boundary (0205) of the security subsystem is extended to incorporate some of the real-time computing capabilities of AxEC. This is the basic FHSM concept.
[0070] More generally, an electrical structure is provided that includes: (a) functional modules (such as HSM, CPU, FLU) such that such functional modules may require another functional module (FLU, peripheral device) to perform (safety) functions for them and (exclusively) on their behalf.
[0071] As described above, the FHSM concept involves virtually extending the security subsystem boundary toward AxEC computing resources (FLU, peripherals).
[0072] The further defined hardware architecture strictly guarantees that any resources allocated to the HSM will not be affected by other parts of the SOC. This means that any communication channel on which its resources act as "from resources" (not initiators of communication) should be restricted so that only components that are part of the FHSM boundary can initiate communication on that channel. This means that specific "isolation" hardware is required to achieve this goal.
[0073] Note: The communication channel whose resource is the "main resource" does not require special attention.
[0074] Depending on the type of communication channel, the isolation mechanism can vary, as explained further.
[0075] The different types of communication channels are:
[0076] • System bus: This type of channel relies on a bus transmission protocol (AXI, AHB, APB, OCP, ...). This channel is a collection of signals and vectors that work together sequentially according to a predefined protocol.
[0077] • Direct Data Bus: This channel is a simple data vector, optionally associated with the dataValid / dataAck validation protocol.
[0078] • Trigger: This type of channel is a single-bit line.
[0079] • Clock / Reset: This signal must be handled properly to avoid semi-intrusive security attacks.
[0080] As stated above, the present invention relates to providing security by enabling the (long-term) use (as a functional module) of a specific security subsystem characterized by state-of-the-art encryption and anti-hacking capabilities. The present invention is able to address new security challenges by defining a particularly suitable architecture within such FPCU-type components. More specifically, the present invention is able to make it forward-looking by allowing the security subsystem to (exclusively) depend on other resources in the architecture, in particular the communication architecture.
[0081] Essentially, since the present invention relates to an (electrical) structure comprising: (a) functional modules; and (b) an interconnection architecture connecting the functional modules and providing communication between these functional modules; therefore, for the purposes described above, the (electrical) structure must be arranged such that selected functional modules can have (temporary) exclusive access to another (some) functional modules that perform functions for them and on their behalf, but uncontrolled access to them is prevented (via the interconnection architecture) by means of protection (the protection means being attached to the communication architecture defined by the interconnection architecture).
[0082] The different possible communication mechanisms (which define the communication architecture) will now be described in more detail.
[0083] Triggering mechanism
[0084] Figure 3 (0300) Explain the trigger hardware management architecture within the FPCU component:
[0085] (0301) A collection of SOC modules can drive one or more triggers. In this context, a “module” can be an FLU partition, an AxEC peripheral, or an AxEC compute accelerator.
[0086] (0302) A collection of SOC modules can take one or more triggers as inputs. Note that some modules can have both input and output triggers.
[0087] • (0303) The central trigger routing function can route any input trigger to any output trigger based on a set of configuration registers, which are accessed via the system bus from the configuration interface (0304).
[0088] Now, let's consider the following situation, such as Figure 4 As shown in (0400), some of these modules are selected for exclusive access to the FHSM. In this case, it is important to ensure that:
[0089] The right module #1 (0402) can receive triggers from the left module #2 (0401). This is not a security vulnerability because both modules are within the FHSM virtual boundary.
[0090] The right module #1 (0402) cannot receive any triggers from any module other than the left module #2 (0401). Therefore, no trigger information can cross the FHSM virtual boundary.
[0091] like Figure 3 As mentioned in (0300), the trigger router configuration is completed via the system bus from the interface. As a result, the router must also be considered as being included in the FHSM virtual boundary, as... Figure 5 As conceptually illustrated in (0500), it must therefore be managed from the configuration interface to achieve this. Specific embodiments for implementing this are further described below.
[0092] With this new virtual boundary, the HSM module can determine the appropriate trigger route and then ensure that the above conditions are met.
[0093] A consequence of this edge effect is that the HSM subsystem is also responsible for configuring all triggers on the SOC, including those not part of the security activities. This is not a problem. The application CPU is always able to configure the necessary non-security triggers. The only constraint is that the application CPU cannot do this directly by writing to the trigger router register. Instead, it must send a specific request to the HSM. The HSM can then check the security aspects of this request and accept or reject the trigger routing request accordingly.
[0094] Generally, in an (electrical) architecture, the first interconnect architecture that connects functional modules and provides communication between these functional modules includes an (additional) third interconnect architecture for exchanging task-specific trigger signals between functional modules. The third interconnect architecture includes a trigger router module capable of routing any input trigger to any output trigger. The (electrical) architecture should ensure that the trigger router module is adapted to ensure that functional modules other than the selected functional modules cannot access them uncontrolled via the third interconnect architecture.
[0095] Clock and Reset Management
[0096] As mentioned earlier, an FPCU can have different available communication mechanisms, which can be combined. Another FPCU (internal) communication mechanism is the clock and reset mechanism. As previously mentioned, each communication mechanism requires adaptation to ensure that extending security functions to other modules does not lead to security and timing issues.
[0097] Fortunately, clock & reset management for FHSM is very similar to trigger management.
[0098] Therefore, the module(s) responsible for generating the clock and resetting must be under the exclusive control of the HSM module (similar to the trigger router in the previous section).
[0099] Therefore, the configuration interfaces of (one or more) clock & reset managers should be managed similarly, as described further. Furthermore, if the main CPU requires a clock & reset operation, it will send a request to the HSM module, which should check the security and validity of the request and ultimately execute the requested configuration.
[0100] As before, an (electrical) structure is thus provided, wherein the first interconnect architecture, which connects and provides communication between functional modules, includes an additional third interconnect architecture related to clock and reset, the third interconnect architecture including a clock & reset management module, and the (electrical) structure is adapted to ensure that functional modules other than the selected functional modules cannot have uncontrolled access to them via the third interconnect architecture.
[0101] From the interface
[0102] In a typical SOC architecture like that used in FPCU, all functional modules are connected to an arbitrarily complex interconnect architecture that allows bidirectional data transfer between transaction initiators and targets.
[0103] In the most general case, due to the memory mapping of the target resource, all initiators can access any target. However, for reasons of software execution robustness and functional safety, the preferred architecture according to the invention is characterized by a multi-layered MPU (Memory Protection Unit) structure, which allows for fine-grained filtering of interconnect memory mapping access permissions based on transaction characteristics.
[0104] • Identifier of the initiator module
[0105] • Access address
[0106] • Access direction (read / write)
[0107] • Security level of access
[0108] ·…
[0109] Therefore, as Figure 6 The typical interconnect structure in the FPCU shown in (0600) can be summarized as follows:
[0110] (0601): Multiple MPU components are inserted into the interconnect socket.
[0111] On the initiator's side, the functional safety requirement is that the request MPU be inserted unconditionally.
[0112] On the target side, the MPU is optional. If the granularity of the memory mapping regions on the initiator-side MPU is too large, then they can be included anyway. Having an MPU on the target side provides very fine-grained control over memory mapping protection.
[0113] • (0602): Each MPU is characterized by a configuration port, which is itself a target socket on a sub-part (0603) of the SOC interconnect structure.
[0114] • This interconnected part is itself protected by the MPU (0604).
[0115] Now, let's imagine that at runtime, the HSM module needs to use certain computing resources within AxEC, as this is a concept introduced in this invention, such as... Figure 7 As shown in (0700).
[0116] In the example above, the security requirement is that FLU-#1 and Periph-#2 cannot be accessed via interconnection by any initiator other than the HSM subsystem.
[0117] Therefore, this means that all MPUs on the interconnect sockets of these modules must be configured by the HSM module.
[0118] Therefore, this means that access to the configuration interfaces of these MPUs must be protected in the same way as the module interfaces.
[0119] Therefore, this means that the MPU that controls access to the secure configuration interconnect must also be controlled by the HSM.
[0120] Therefore, in this architecture, all MPUs of the SOC must only Configured by the HSM subsystem, thereby extending the virtual boundary, such as Figure 8 As shown in (0800).
[0121] If the main CPU requires a certain MPU configuration for non-security reasons, it will send a service request to the HSM module. The HSM module will then configure the MPU accordingly after checking the security and validity of the request.
[0122] In essence, for the above architecture, the aforementioned (communication) protection measures include: one or more protection units provided (between the module and a part of the first interconnect architecture); thereby the configuration of the protection units is controlled (directly or indirectly) by the selected transaction initiation function module.
[0123] Using flexible logic units in a flexible hardware security architecture
[0124] This concludes the discussion of the communication mechanism and the adaptation required for the Flexible Hardware Method (FSHM) in the SOC according to the present invention. For security purposes, the FHSM concept preferably utilizes the hardware computing resources of AxEC.
[0125] Now, let's address the FLU characteristics required to enable this concept.
[0126] First, address the fundamental situation in FLU where neither anticipation nor isolation nor task switching capabilities are used.
[0127] When the FPCU component is equipped with a single FLU matrix that does not provide task switching capabilities, we can imagine two scenarios:
[0128] Alternatively, the embedded FPGA can support partial field reconfiguration.
[0129] In this case, the HSM is able to reserve a region of the eFPGA for FHSM purposes and then fill it with a dedicated bitstream.
[0130] However, this solution is not secure enough because:
[0131] It is nearly impossible to prove that safe and unsafe parts of a matrix cannot interact.
[0132] • The management of the sub-bit streams is handled by software applications whose security level cannot be authenticated.
[0133] Alternatively, FLU may be exclusively and completely dedicated to FHSM or the application at any given time.
[0134] In terms of security, this is acceptable.
[0135] However, it makes FPCU components almost unusable in target application domains where real-time computing cannot be interrupted.
[0136] In summary, while technically feasible under full commitment, an FPCU with a single task FLU matrix is not a good candidate for implementing the FHSM concept.
[0137] There exists a concept where an FPCU component comprises at least two FLU matrices, which can optionally be used together as a large single matrix. In this case, the FHSM concept is highly relevant:
[0138] • Applications should use some of the FLU matrix for real-time algorithms.
[0139] • HSM can use the remaining free FLU matrix for security purposes (FHSM boundary management operation as described in the application).
[0140] • If needed, the FLU matrix can be assigned to the HSM or application at runtime.
[0141] The proof of the independence between the safe and unsafe FLU components becomes straightforward.
[0142] There is also the concept that the FPCU component contains at least one FLU matrix capable of performing task switching (which can be combined with the above concept).
[0143] In this context, the FHSM concept is also relevant, but its usage is somewhat complex:
[0144] The use of the FLU matrix should be divided into two periodic time windows:
[0145] Reserve a time window for real-time applications
[0146] Reserve a time window for HSM
[0147] FLU is configured to switch tasks between two contexts.
[0148] Due to the principles of microarchitecture, it is possible to prove the independence between the secure FLU component and the insecure component.
[0149] The difficulty here lies in properly handling the FHSM boundaries, as the matrix must switch between safe and unsafe boundaries. This makes the switching sequence more complex than switching between two application tasks. Organizations performing this operation include... Figure 9 As shown in (0900). Of course, for security reasons, all sequences must be exclusively managed by the HSM module. The preceding sequences are technically feasible. However, the latency between the two FLU execution windows due to MPU configuration must be verified for real-time applications.
[0150] Essentially, one or more of the aforementioned functional modules are hardware programmable units, programmable logic matrices adapted to sequentially execute at least two tasks and / or preferably comprise a flexible logic unit structure arranged side-by-side and adapted to be physically connected or isolated in pairs (at runtime), and the relational switching mechanism is described as being adapted to properly handle FHSM requirements.
[0151] FHSM use cases
[0152] Hardware accelerator
[0153] Using the FHSM concept, some eFPGA resources and math accelerators can be dedicated to the security subsystem, thereby enabling the implementation of new encryption algorithms.
[0154] Compared to simple software implementations of algorithms, this approach offers the following advantages:
[0155] • FPGA architecture is particularly efficient in executing cryptographic algorithms because it provides massively parallel computing capabilities.
[0156] The power perturbation signatures of FPGA activity are much noisier than those of CPU cores. Therefore, the algorithmic computation is more resilient to non-intrusive security attacks.
[0157] • Encryption algorithms perform better when implemented in hardware.
[0158] Essentially, the electrical structure according to the invention is now used, wherein one or more of the functional modules, as hardware programmable units (0202) and as programmable logic matrices, are configured to at least partially perform the encryption method.
[0159] Security
[0160] Let's take a simple FPCU architecture with two FLU matrices as an example:
[0161] • One allocated to real-time applications
[0162] The second one is assigned to FHSM
[0163] The content of the first FLU cannot access any information of the second FLU (the FHSM boundary explained above).
[0164] However, there is no security issue with the second FLU segment accessing any information within the first FLU section. Therefore, secure FLU content can contain real-time information about the activities of running applications.
[0165] This capability allows security activities to be strictly synchronized with application activities.
[0166] Encryption algorithms can also be implemented in the FLU matrix to replicate the hard portion of the FHSM or a reference algorithm implemented in software. This allows for lockstep implementations of secure algorithms, which allow for checking the correctness of repeated algorithm execution.
[0167] Several implementation methods are possible:
[0168] The algorithm used for replication in FLU is strictly identical to the reference algorithm (same RTL): it ensures both spatial and temporal redundancy.
[0169] The algorithm used for replication in FLU differs from the reference algorithm (the same function with different RTLs): it ensures spatial and temporal redundancy as well as the correctness of the results (the two different algorithms produce the same results).
[0170] Security attack detection (digital sensor)
[0171] eFPGA matrices like FLU can be configured in a way that allows them to detect invasive and semi-invasive attacks based on the physical effects on internal propagation delays.
[0172] countermeasures
[0173] The FLU matrix is well-intentioned for implementing new encryption algorithms, but in the same way, some hardware countermeasures can also be implemented in the FLU matrix of the FHSM to improve the security level of the components and thus counter new attack techniques.
[0174] As an example, some random noise can be generated by FLU to disrupt the power profile of the component, thereby increasing the component's resistance to side-channel attacks.
Claims
1. An electrical structure, comprising: The functional module includes a transaction initiation functional module and a transaction target functional module. The transaction initiation functional module requires the transaction target functional module to act as the transaction initiation functional module and to perform functions on behalf of the transaction initiation functional module. A first interconnect architecture connects functional modules and provides communication between these functional modules; wherein the electrical structure is arranged such that a selected transaction initiating functional module has temporary exclusive access to one or more transaction target functional modules that perform functions for and on behalf of the selected transaction initiating functional module, to ensure that other transaction initiating functional modules besides the selected transaction initiating functional module cannot access it uncontrolled, wherein the selected transaction initiating functional module is a hardware security module. The feature is that, in order to ensure that the selected transaction initiation function module has temporary exclusive access to one or more transaction target function modules that perform functions for and on behalf of the selected transaction initiation function module, hardware protection measures are provided to ensure that other transaction initiation function modules besides the selected transaction initiation function module cannot access it without control; and The hardware protection means includes: one or more protection units provided between the functional module and a portion of the first interconnect architecture of each transaction target functional module in the transaction target functional module; thereby, the configuration of the protection units is controlled by the selected transaction initiation functional module.
2. The electrical structure as described in claim 1, wherein, The protection unit provides transaction filtering.
3. The electrical structure as described in claim 1, wherein, Other transaction initiation modules besides the selected transaction initiation module can only be accessed via the first interconnect architecture after the other transaction initiation modules initiate a service request to the selected transaction initiation module to configure a protection unit connected to such other transaction initiation modules that are correspondingly approved by the selected transaction initiation module.
4. The electrical structure as described in claim 1, wherein, One or more protection units are also connected by one or more second interconnect architectures for configuring these protection units, such that one or more additional protection units are provided between the first and second interconnect architectures; and the configuration of the additional protection units is controlled by the selected transaction initiation function module.
5. The electrical structure as described in claim 1, wherein, The first interconnect architecture connects functional modules and provides communication between these functional modules. The first interconnect architecture includes a third interconnect architecture for exchanging task-dependent trigger signals between functional modules. The third interconnect architecture includes a trigger router module capable of routing any input trigger to any output trigger. The trigger router module is adapted to ensure that other transaction initiating functional modules, except for the selected transaction initiating functional module, cannot access it uncontrollably via the third interconnect architecture.
6. The electrical structure as described in claim 5, wherein, The trigger router module can be configured via a second interconnect architecture.
7. The electrical structure as described in claim 1, wherein, The first interconnect architecture connects functional modules and provides communication between these functional modules. The first interconnect architecture includes a fourth interconnect architecture, which includes direct connections between a portion of the functional modules. Thus, the protection means ensure that other transaction initiating functional modules, except for the selected transaction initiating functional module, cannot gain uncontrolled access to the one or more modules that perform functions for and on behalf of the selected transaction initiating functional module via the fourth interconnect architecture.
8. The electrical structure as described in claim 1, wherein, Access from the transaction initiation module to the transaction target module is partially arranged via the system bus and access units to filter access based on the characteristics of the transaction action. The access units support memory mapping.
9. The electrical structure as described in claim 8, wherein, The access unit serves as the protection unit.
10. The electrical structure as claimed in claim 1, wherein, One or more of the functional modules are hardware programmable units, which are programmable logic matrices adapted to sequentially execute at least two tasks and / or include a structure of multiple flexible logic units arranged side by side and adapted to be physically connected or isolated.
11. The electrical structure as claimed in claim 1, wherein, One or more of the functional modules are peripheral hardware units dedicated to electrical control unit hardware functions or mathematical accelerator functions.
12. The electrical structure as described in any one of claims 1 to 11, wherein, One or more of the functional modules are software programmable units.
13. The electrical structure as described in any one of claims 1 to 11, wherein, One or more of the functional modules are microprocessor cores or graphics processor cores.