A SECURE HARDWARE PROGRAMMABLE ARCHITECTURE

Abstract

The invention relates to an electric arrangement, comprising: (a) functional modules, which can serve both as transaction initiators or transaction targets, whereby a transaction initiating functional module may need a transaction target functional module to execute a function for and on its behalf; (b) a first interconnect fabric connecting the functional modules and providing communication between those functional modules; wherein the (electric) arrangement being arranged in that a selected transaction initiation functional module has temporally exclusive access to transaction target functional module(s), executing a function for and on its behalf, to ensure that transaction initiating functional modules other than the selected transaction initiation functional module, have no uncontrolled access thereto, wherein said selected transaction initiation functional module being a hardware secure module.

Claims

1-15. (canceled)

16. An electric arrangement, comprising: functional modules, which can serve both as transaction initiators or transaction targets, whereby a transaction initiating functional module may need a transaction target functional module to execute a function for and on behalf of the transaction initiating functional module; and a first interconnect fabric connecting the functional modules and providing communication between the functional modules connected by the first interconnect fabric, wherein: the electric arrangement is arranged such that a selected transaction initiation functional module has temporally exclusive access to one or more transaction target functional modules executing a function for and on behalf of the selected transaction initiating functional module, to ensure that transaction initiating functional modules other than the selected transaction initiation functional module have no uncontrolled access to the one or more transaction target functional modules; the selected transaction initiation functional module is a hardware secure module; protection means are provided for ensuring that the selected transaction initiation functional module has the temporally exclusive access to the one or more transaction target functional modules executing the function for and on behalf of the selected transaction initiating functional module, to ensure that transaction initiating functional modules other than the selected transaction initiation functional module, have no uncontrolled access to the one or more transaction target functional modules; and the protection means comprises one or more protection units provided between the modules and part of the first interconnect fabric for each of the transaction target functional modules, the configuring of the protection units being controlled by the selected transaction initiation functional module.

17. The electric arrangement of claim 16, wherein the protection units provide transaction filtering.

18. The electric arrangement of claim 16, wherein transaction initiating functional modules other than the selected transaction initiation functional module have access only via the first interconnect fabric after initiating by the other transaction initiating functional modules a service request to the selected transaction initiation functional module to configure protection units connected to such other transaction initiating functional modules accordingly subject to approval of the selected transaction initiation functional module.

19. The electric arrangement of claim 16, wherein: one or more protection units are further connected by one or more second interconnect fabrics for configuring the one or more protection units, one or more further protection units are provided between the first and second interconnect fabrics; and the configuring of the further protection units is controlled by the selected transaction initiation functional module.

20. The electric arrangement of claim 19, further comprising a third interconnect fabric for exchanging task specific trigger signals between functional modules, the third interconnect fabric comprising a trigger router module that is able to route any input triggers to any output trigger, the trigger router module being adapted to ensure that transaction initiating functional modules other than the selected transaction initiation functional module have no uncontrolled access to the trigger router module via the third interconnect fabric.

21. The electric arrangement of claim 20, wherein trigger initiating functional modules transmit trigger routing requests to the hardware secure module.

22. The electric arrangement of claim 20, wherein the trigger router module is configurable via the second interconnect fabric.

23. The electric arrangement of claim 22, wherein trigger initiating functional modules transmit trigger routing requests to the hardware secure module.

24. The electric arrangement of claim 16, further comprising a fourth interconnect fabric, the fourth interconnect fabric comprising direct connections between part of the functional modules, whereby the protection means ensures that transaction initiating functional modules other than the selected transaction initiation functional module have no uncontrolled access to the one or more modules executing a function for and on behalf of selected transaction initiation functional module via the fourth interconnect fabric.

25. The electric arrangement of claim 16, wherein access for transaction initiating functional modules to a transaction target functional module is partly arranged via a system bus and an access unit to filter the access based on transaction action characteristics.

26. The electric arrangement as in claim 25, wherein the access unit acts as the protection units.

27. The electric arrangement of claim 16, wherein one or more of the functional modules is a hardware programmable unit, the hardware programmable unit being a programmable logic matrix adapted for sequentially executing at least two tasks and/or comprising a plurality of flexible logic unit arrangements arranged side-by-side and adapted for being either physically connected or isolated.

28. The electric arrangement of claim 16, wherein one or more of the functional modules is a peripheral hardware unit that is optionally dedicated to electric control unit hardware functions or mathematical accelerator functions.

29. The electric arrangement of claim 16, wherein one or more of the functional modules is a software programmable unit.

30. The electric arrangement of claim 27, wherein: one or more of the functional modules is a peripheral hardware unit that is optionally dedicated to electric control unit hardware functions or mathematical accelerator functions; and the electric arrangement is a heterogeneous hardware system.

31. The electric arrangement of claim 27, wherein: one or more of the functional modules is a software programmable unit; and the electric arrangement is a heterogeneous hardware system.

32. The electric arrangement of claim 27, wherein: one or more of the functional modules is a peripheral hardware unit that is optionally dedicated to electric control unit hardware functions or mathematical accelerator functions; one or more of the functional modules is a software programmable unit; and the electric arrangement is a heterogeneous hardware system.

33. The electric arrangement of claim 27, wherein at least one of the programmable logic matrix being used by the hardware secure module for security in that the programmable logic is configured at least in part for execution of a cryptographic algorithm.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0033] FIG. 1 (0100) illustrates a conventional FPCU architecture (without Flexible hardware secure module).

[0034] FIG. 2 (0200) provides an exemplary use of the invented concept.

[0035] FIG. 3 (0300) explains the triggers hardware management architecture within an FPCU component in relation to the specific considerations to be made to be secure in accordance with the invention.

[0036] FIG. 4 (0400) describes a use case in relation to FIG. 3 (0300).

[0037] FIG. 5 (0500) introduces the concept of virtual boundary in relation to FIGS. 3 (0300) and 4 (0400).

[0038] FIG. 6 (0600) explain a typical interconnect structure in FPCU in relation to the specific considerations to be made to be secure in accordance with the invention.

[0039] FIG. 7 (0700) describes a further use case in relation a hardware secure module exploiting peripheral resources.

[0040] FIG. 8 (0800) introduces the concept of virtual boundary in relation to FIG. 7 (0700).

[0041] FIG. 9 (0900) explains the invention in the context of matrix switching and an appropriate mechanism to achieve security.

DETAILED DESCRIPTION

[0042] The invention relates to an (electric) arrangement, comprising: (a) functional modules, which can serve both as transaction initiators or transaction targets, whereby a transaction initiating functional module may need a transaction target functional module to execute a function for and on its behalf; (b) a first interconnect fabric connecting the functional modules and providing communication between those functional modules; wherein the (electric) arrangement being arranged in that a selected transaction initiation functional module has (temporally) exclusive access to transaction target functional module(s), executing a function for and on its behalf, to ensure that transaction initiating functional modules other than the selected transaction have no uncontrolled access thereto (via the interconnect fabric).

[0043] Typically said selected transaction initiation functional module is a hardware secure module (for instance with cryptographic capabilities).

[0044] The invention in particular relates to an (electric) arrangement, comprising: (a) functional modules, which can serve both as transaction initiators or transaction targets, whereby a transaction initiating functional module may need a transaction target functional module to execute a function for and on its behalf; (b) a first interconnect fabric connecting the functional modules and providing communication between those functional modules; characterized in that, for ensuring that a selected transaction initiation functional module has (temporally) exclusive access to transaction target functional module(s) executing a function for and on its behalf, protection means are provided, to ensure that transaction initiating functional modules other than the selected transaction initiation functional module, have no uncontrolled access thereto (via the interconnect fabric).

[0045] In an embodiment of the invention said protection means comprises: one or more protection units provided (between said modules and part of said first interconnect fabric) for each of said transaction target functional modules; whereby the configuring of said protection units is (directly or indirectly) controlled by said selected transaction initiation functional module (wherein said protection units provide transaction filtering).

[0046] In an embodiment of the invention transaction initiating functional modules other than the selected transaction initiation functional module, have only access via the first interconnect fabric after initiating by said other transaction initiating functional modules a service request to said selected transaction initiation functional module to configure related protection units accordingly subject to its approval (hence controlled access).

[0047] In an embodiment of the invention in the (electric) arrangement, the one or more protection units are further connected by a second interconnect fabric for configuring those protection units, whereby a further protection unit, between said first and second interconnect fabric is provided; and the configuring of said further protection unit is (directly or indirectly) controlled by said selected transaction initiation functional module.

[0048] In alternative embodiment of the invention in the (electric) arrangement, wherein one or more protection units are further connected by one or more second interconnect fabrics for configuring those protection units, whereby further one or more protection units, between said first and second interconnect fabrics are provided; and the configuring of said further protection unit is (directly or indirectly) controlled by said selected transaction initiation functional module.

[0049] In an embodiment of the invention an (electric) arrangement is provided, wherein said first interconnect fabric connecting the functional modules and providing communication between those functional modules, comprising a third interconnect fabric, for exchanging task specific trigger signals between functional modules, said third interconnect fabric comprising a trigger router module, able to route any input triggers to any output trigger, said trigger router module, being adapted to ensure that transaction initiating functional modules other than the selected transaction initiation functional module, have no uncontrolled access thereto via the third interconnect fabric, preferably said trigger router module, being configurable via said second interconnect fabric (while for the other remaining part of said first interconnect fabric protection units are provide in between said other remaining part and the functional modules).

[0050] In an embodiment of the invention an (electric) arrangement is provided, wherein said first interconnect fabric connecting the functional modules and providing communication between those functional modules, comprising a fourth interconnect fabric, comprising direct connections between (part of) the functional modules, whereby said protection means ensures that transaction initiating functional modules, other than the selected transaction initiation functional module, have no uncontrolled access to module(s) executing a function for and on its behalf, via the fourth interconnect fabric (by configuring those transaction initiating functional modules related protection unit accordingly).

[0051] The invention is now illustrated on the basis of a conventional FPCU architecture (without Flexible hardware secure module) as shown in FIG. 1 (0100), comprising: [0052] (0101): One or multiple conventional processor cores. In such FPCU component, the processor cores are dedicated to the part of the application that do not require hard real-time processing. [0053] (0102): One or multiple Flexible Logic Unit matrices. Each of them can optionally be capable of task switching. [0054] (0103): Multiple sensor/actuator and hardware accelerator peripherals. [0055] (0104): An “Hardware Security Module” (according to Evita terminology). This is a conventional security sub-system featuring: [0056] A local processor core and associated secure firmware [0057] Multiple cryptographic hardware accelerators. [0058] Multiple mechanism for protection against hacking attacks [0059] (0105): This is the physical boundary of the Security sub-system. This notion is important in the sense where it clearly specifies the communications channels between the secure domain and the application domain. Within this boundary, all the hardware content is strictly reserved to the secure computing unit (like CPU but also FLU is possible) and cannot be accessed from other computing units (CPU or other) of the component. [0060] (0106): An arbitrary complex interconnect network that allows different kinds of communications between elements of the system (bus communications, interrupts, triggers, . . . )

[0061] As explained above, the state-of-art solution based on software does not properly solve the problems.

[0062] So, the invented concept is about taking benefit of the existence of the flexible logic unit and/or mathematical accelerators present in the (so-called AxEC) sub-system to extend the “boundary” of the HSM module. This resource allocation is intended to be done dynamically at runtime so that the AxEC resource usage can be adapted to any in-field situations.

[0063] The FIG. 2 (0200) explains the concept on an example.

[0064] In this example: [0065] The conventional security module (0201) functionality is extended by using one partition of FLU (0202) and/or (and preferably both) a hardware accelerator (0203). [0066] Thanks to dedicated mechanisms (0204) (explained further) within interconnect structure, the above elements are made exclusive for HSM usage. This means that those resources become “invisible” to any master of the SOC but the HSM itself. [0067] Therefore, the effective secure sub-system physical boundary (0205) is extended to integrate some real-time computing power of the AxEC. This is the basic FHSM concept.

[0068] More generally speaking the electric arrangement is provided, which, comprises: (a) functional modules (such as HSM, CPU, FLU), whereby such functional module may need another functional module (FLU, Peripheral) to execute a (security) function for and on its (exclusive) behalf.

[0069] As introduced above, the FHSM concept consists in virtually extending the secure sub-system boundary towards AxEC computing resources (FLU, Peripheral).

[0070] The hardware mechanisms that are further defined strictly guarantee that any resource allocated to the HSM cannot be influenced by other parts of the SOC. This means that any communication channel for which the resource is a “slave” (not the initiator of the communication) should be restricted so that only the components being part of the FHSM boundary are able to initiate communication on this channel. This means that specific “isolation” hardware is needed to reach this goal.

[0071] Note: The communication channels for which the resource is a “master” do not need special care.

[0072] Depending on the type of communication channel, the isolation mechanism may differ as explained further.

[0073] The different types of communication channels are: [0074] System bus: this kind of channel relies on bus transfer protocols (AXI, AHB, APB, OCP, . . . ). This kind of channel is a set of signals and vectors that work together in a sequence according to pre-defined protocols. [0075] Direct data bus: this kind of channel is a simple vector of data, optionally associated with a dataValid/dataAck validation protocol. [0076] Trigger: this kind of channel is a single bit wire. [0077] Clock/reset: this kind of signal must be handled properly to avoid semi invasive security attacks.

[0078] As said the invention is about providing security by enabling (long-term) use of (as functional module) a specific secure sub-system featuring state-of-art cryptographic and anti-hacking functions and able to handle new security challenges by defining a specially adapted architecture within such FPCU kind of components, more in particular making it future proof by allowing a secure sub-system to rely (exclusively) on other resources in the arrangement, wherein especially the communication architecture requires attention.

[0079] In essence since the invention relates to an (electric) arrangement, comprising: (a) functional modules; and(b) a interconnect fabric connecting the functional modules and providing communication between those functional modules; for the purpose set forth above the (electric) arrangement has to be being arranged in that a selected functional module has (temporally) exclusive access to another functional module(s), executing a function for and on its behalf, but avoiding uncontrolled access thereto (via the interconnect fabric) via protection means (attached to the communication architecture defined by the interconnect fabric).

[0080] The possible different available communication mechanisms (defining the communication architecture) are now described in more detail.

[0081] Trigger Mechanism

[0082] FIG. 3 (0300) explains the triggers hardware management architecture within an FPCU component: [0083] (0301) a set of SOC modules are able to drive one or multiple triggers. In this context a “module” can be a FLU partition, an AxEC peripheral, or an AxEC computing accelerator. [0084] (0302) a set of SOC modules are able to take as input one or multiple triggers. Note that some modules may have both input and output triggers. [0085] (0303) A central trigger routing function is able to route any input trigger to any output trigger based on a set of configuration registers accessed through system bus slave configuration interface (0304)

[0086] Now, let's consider the following case as shown in FIG. 4 (0400) where some of the modules are selected for FHSM exclusive access. In this case, what is important is to insure that: [0087] Right module #1 (0402) is able to receive a trigger from left module #2 (0401). This is not a security breach because both modules are within the FHSM virtual boundary. [0088] Right module #1 (0402) cannot receive any trigger from any module but the left module #2 (0401). Thus, no trigger information is able to cross the FHSM virtual boundary.

[0089] As mentioned in FIG. 3 (0300) the trigger router configuration is done through system bus slave interface. The consequence is the router must also be considered as being included in FHSM virtual boundary as conceptually illustrated in FIG. 5 (0500). Therefore, its slave configuration interface has to be managed to achieve this. A particular embodiment to achieve this is described further.

[0090] With this new virtual boundary, the HSM module is able to decide for proper trigger routing and then insure that the conditions above are met.

[0091] The edge effect consequence is that the HSM sub-system become also responsible for the configuration of all triggers of the SOC., including those that are not part of the security activities. This is not a problem. It is always possible for the Application CPU to configure the necessary non-secure trigger. The only constraint is that the application CPU is not able to do it directly by writing trigger router registers. Instead it must transmit a specific request toward the HSM. Then this one can check the secure aspect of this demand and accept or refuse the trigger routing request accordingly.

[0092] Generally speaking an (electric) arrangement, wherein said first interconnect fabric connecting the functional modules and providing communication between those functional modules, comprises a (further) third interconnect fabric, for exchanging task specific trigger signals between functional modules, said third interconnect fabric comprising a trigger router module, able to route any input triggers to any output trigger, should ensure that said trigger router module is adapted to ensure that functional modules other than the selected functional module, have no uncontrolled access thereto via the third interconnect fabric.

[0093] Clock and Reset Management

[0094] As said a FPCU may have different available communication mechanisms, which can be combined. Another FPCU (internal) communication mechanism is the clock and reset mechanism. As said before each communication mechanism requires adaptation to ensure that the expanding security functions to other modules does not result in safety- and timing issues.

[0095] Fortunately the clock&reset management for FHSM is pretty similar to the triggers management.

[0096] So, the module(s) that is(are) responsible for generating clock and reset must be under exclusive control of the HSM module (like trigger router in previous section).

[0097] Therefore, the configuration interfaces of the clock&reset manager(s)shall be managed likewise described further. And, if the main CPU needs some clock&reset operation, tt would post a request towards the HSM module that shall check for security validity of the request and eventually execute the requested configuration.

[0098] As before an (electric) arrangement is hence provided, wherein said first interconnect fabric connecting the functional modules and providing communication between those functional modules, comprises a (further) third interconnect fabric, related to clock and reset, said third interconnect fabric comprising a clock&reset management module, adapted to ensure that functional modules other than the selected functional module, have no uncontrolled access thereto via the third interconnect fabric.

[0099] Slave Interfaces

[0100] In a typical SOC architecture like the one used in FPCU, all functional modules are connected to an arbitrary complex interconnect fabric that allows bidirectional data transmission between transaction initiators and targets.

[0101] In the most general case, all the initiators have the possibility to access any of the targets thanks to memory mapping of target resources. However, for software execution robustness and functional safety reasons, a preferred architecture in accordance with the invention features a multi-layer MPU (Memory Protection Unit) structure that allows to fine-grain filter the interconnect memory map access right based on transaction characteristic : [0102] Identifier of the initiator module [0103] Address of the access [0104] Direction of the access (read/write) [0105] Security level of the access [0106] . . .

[0107] So, a typical interconnect structure in FPCU as shown in FIG. 6 (0600) can be summarized as below: [0108] (0601): A multiplicity of MPU components are inserted on interconnect sockets. [0109] On initiator side, the functional safety requirements are requesting the MPUs to be inserted unconditionally. [0110] On target side, the MPU are optional. They can be included anyway if the granularity of memory-map regions on initiator side MPUs is too large. Having MPU on target side offers a very fine-grain control of the memory-map protection. [0111] (0602): Each MPU features a configuration port which is itself a target socket on a sub-part of the SOC interconnect structure (0603). [0112] This part of interconnect is itself protected by an MPU (0604)

[0113] Now, let's imagine that, at runtime, the HSM module needs to use some computing resource within AxEC, as this is the concept introduced by the invention, as illustrated in FIG. 7 (0700).

[0114] In the example above, the security requirement is that FLU-#1 and Periph-#2 cannot be accessed through interconnect by any initiator but the HSM sub-system.

[0115] So, this means that the all the MPUs being on the interconnect socket of those modules must be configured by the HSM module.

[0116] So this means that the access to the configuration interface of those MPUs must be protected the same way as the modules interfaces.

[0117] So, this means that the MPU controlling the access to the secure configuration interconnect must also be controlled by the HSM.

[0118] Consequently, in this architecture, all the MPUs of the SOC must be configured only by the HSM sub-system, expanding the virtual boundary as illustrated in FIG. 8 (0800).

[0119] If the main CPU needs some MPU configuration for non-secure reasons, then it would address a service request to the HSM module. And then this one will configure the MPU accordingly after checking of the security validity of the request.

[0120] In essence for the above architecture the previously mentioned (communication) protection means comprises: one or more protection units provided (between said modules and part of said first interconnect fabric); whereby the configuring of said protection units is (directly or indirectly) controlled by said selected transaction initiation functional module.

[0121] Use of Flexible Logic Unit in the Flexible Hardware Secure Mechanism

[0122] So far, the communication mechanism in a SOC and the required adaptations for the flexible hardware approach (FSHM) in accordance with the invention are discussed. Preferably the FHSM concept takes benefit of the hardware computing resource of the AxEC for security purpose.

[0123] The required FLU characteristics to enable this concept are now addressed.

[0124] First the basic cases wherein no segregation nor task switching capability is foreseen or used in the FLU is addressed.

[0125] In the case where an FPCU component is equipped with a single FLU matrix that does not provide tasks witching capabilities, then we can imagine two cases : [0126] Either the embedded FPGA is able to support in-field partial reconfiguration. [0127] In this case, the HSM could have the possibility to reserve a region of the eFPGA for FHSM purpose and then fill it with dedicated bitstream. [0128] However, this solution is not secure enough because: [0129] It is almost impossible to demonstrate that there is not possible interactions between secure and non-secure parts of the matrix. [0130] The management of the sub-part bitstream is handled by a software application whose security level cannot be certified. [0131] Or, the FLU is fully dedicated to FHSM or application exclusively at any point of time. [0132] This is OK in terms of security level [0133] However, it makes the FPCU component almost unusable for targeted application domains where the real-time computing cannot be interrupted.

[0134] In conclusion, while technically feasible in case of full dedication, an FPCU featuring a single mono-task FLU matrix is not a good candidate for implementing the FHSM concept.

[0135] There exist concepts wherein the FPCU component contains at least 2 FLU matrices that can optionally be used jointly as a big single one. In this case the FHSM concept is highly relevant: [0136] The application shall use some of the FLU matrices for real-time algorithms. [0137] The HSM may use remaining free FLU matrices for security purpose (applying the FHSM boundary management operations described) [0138] The allocation of FLU matrices to HSM or application can be done at runtime if needed. [0139] The demonstration of the mutual independence between secure FLU parts and non-secure parts becomes then straightforward.

[0140] There exist also concepts (combinable with the above one) wherein the FPCU component contains at least one FLU matrix that is able to execute task switching.

[0141] In this case the FHSM concept is also relevant, but a little bit more complex to use: [0142] The usage of the FLU matrix shall be temporally split in two periodic temporal windows: [0143] A time window is reserved to real-time application [0144] A time window is reserved to HSM [0145] The FLU is configured for task switching between both contexts. [0146] The demonstration of the mutual independence between secure FLU parts and non-secure parts is possible thanks to micro-architecture principles.

[0147] The difficulty here is to handle properly the FHSM boundaries as described because the matrix must switch between secure boundaries and non-secure boundaries. This makes the switching sequence more complex than switching between two applicative tasks. The mechanism to do this is shown in FIG. 9 (0900). Of course, all the sequence must be managed exclusively by the HSM module for security reasons. The previous sequence is technically possible. However, the latency between two FLU execution windows because of the MPU configuration must be verified for real-time applications.

[0148] In essence the above described electric arrangements, wherein one or more of said functional modules being a hardware programmable unit, being a programmable logic matrix, is adapted for sequentially execution of at least two tasks and/or preferably comprise a plurality of flexible logic unit arrangements arranged side-by-side and adapted for being (run-time) pair-wise either physically connected or isolated, and describes the relation switching mechanisms must be adapted for handle properly the FHSM requirements.

[0149] FHSM Use Cases

[0150] Hardware Accelator

[0151] Using FHSM concept, it is possible to dedicate to the secure sub-system some eFPGA resource and mathematical accelerators so that new cryptographic algorithm can be implemented.

[0152] The benefits of such an approach compared to a simple software implementation of the algorithm are the following: [0153] An FPGA architecture is particularly efficient at executing cryptographic algorithm because of the massively parallel computing capability it provides. [0154] The power perturbations signature of an FPGA activity is much noisier than the signature of a CPU core. So, the algorithm computing is more resilient to non-invasive security attacks. [0155] Performance of cryptography algorithms is higher when implemented in hardware [0156] In essence the electric arrangement in accordance with the invention is now used in that the one or more of said functional modules being a hardware programmable unit (0202), being a programmable logic matrix are configured to at least in part executed a cryptography method.

[0157] Safe Security [0158] Let's take the simple FPCU architecture featuring 2 FLU matrices : [0159] One is allocated to real-time application [0160] Second is allocated to FHSM

[0161] The first FLU content is not able to access any information from second one (FHSM boundary explained above)

[0162] However, there is no security problem for the second FLU section to have access to any information within the first FLU part. So, the secure FLU content can have real-time information of the activity of the running application.

[0163] This capability allows having secure activity and application activity strictly synchronized.

[0164] It is also possible to implement in a FLU matrix a cryptography algorithm to duplicate a reference algorithm implemented either in the hard part of FHSM or in software. This results in a lockstep implementation of a security algorithms which allows to check the correctness of the execution of the duplicated algorithm.

[0165] Several implementations are possible here: [0166] Algorithm duplicated in the FLU is strictly the same as the reference one (same RTL): it ensures a spatial and temporal redundancy [0167] Algorithm duplicated in the FLU differs from the reference one (same function with different RTL): it ensures a spatial and temporal redundancy and correctness of the result (Two different algorithms produce the same result)

[0168] Secure Attacks Detection (Digital Sensor)

[0169] An eFPGA matrix like FLU can be configured in such a way that it can detect invasive and semi-invasive attacks based on physical effects on internal propagation delays.

[0170] Counter Measures

[0171] FLU matrix are well intended to implement new cryptography algorithms, but in the same way some hardware countermeasures can also be implemented in FLU matrix of FHSM in order to increase the security level of the component addressing new attack technics.

[0172] As an example some random noise could be generated by the FLU to shuffle the power profile of the component and thus increase resistance of the component to Side Channel Attacks.