Patent Description:
Electronic control units (ECUs) are increasingly being introduced into motor vehicles in a wide range of automotive domains, such as powertrain, chassis, body, active safety, driver assistance, passenger comfort and infotainment. Not only is the number of ECUs embedded in a vehicle rising, but also these units are becoming ever more interconnected.

ECUs are expected to comply with functional safety standards. For example, automotive electric and electronic systems are required to comply with the ISO <NUM> standard. Moreover, as with any networked computer system, automotive electronic systems are vulnerable to attack by external malicious entities, and so they should also include measures to make them secure, i.e., to meet security requirements.

Thus, attention is being directed to systems which satisfy both safety and security requirements, and an example of a system which satisfies these requirements can be found in <CIT>.

<CIT> describes a system including a plurality of matching block cipher devices, and a hardware state machine communicatively coupled to each of the plurality of matching block cipher devices. Each of the plurality of matching block cipher devices can be independently invoked by the hardware state machine such that the hardware state machine causes two or more of the plurality of matching block cipher devices to selectively perform a block-cipher-based symmetric cryptographic operation in a redundant mode or a parallel mode. The block-cipher-based symmetric cryptographic operation may be associated with securing a communication channel of an automotive system.

<CIT> describes a system including a first master element; and at least one shared communication element arranged to operably couple the first master element to at least one slave element. The system further comprises at least one validation element located on at least one further validation path located between the first master element and the at least one slave element, wherein the at least one validation element is arranged to validate at least one of: at least one access request by the first master element; and a response to an access request from the at least one slave element.

<CIT> describes an apparatus having a processing pipeline (<NUM>) which includes an execute stage and at least one front end stage for controlling which micro operations are issued to the execute stage. The pipeline has an intra-core lockstep mode of operation in which the at least one front end stage issues micro operations for controlling the execute stage to perform main processing and checker processing. The checker processing comprises redundant operations corresponding to associated main operations of at least part of the main processing. Error handling circuitry is responsive to the detection of a mismatch between information associated with given checker and main operations to trigger a recovery operation to correct an error and continue forward progress of the main processing.

According to a first aspect of the present invention, there is provided an integrated circuit. The integrated circuit comprises a safety processor, a memory and a secure computing module. The secure computing module comprises a secure processor, first and second cryptographic units for encrypting and decrypting data in the memory, and first and second data transfer units for transferring data between the memory and the first and second cryptographic units respectively. The first cryptographic unit and the first data transfer unit provide a first cryptographic data handling system and the second cryptographic unit and the second data transfer unit provide a second cryptographic data handling system. The integrated circuit further comprises a switch and the secure computing module further comprises selector circuitry for selectively coupling and uncoupling the first and second cryptographic handling systems in response to control signals from the switch, such that, in a first mode, the first and second cryptographic data handling systems are uncoupled and operable independently of each other and, in a second mode, the first and second cryptographic data handling systems are coupled and operable together to provide hardware redundancy.

Thus, the transfer units and the cryptography units can be selectively switched between a first mode in which secure, non-safety-related data or authentication-only data can be handled at a relatively high throughput and a second mode in which secure, safety-related data can be handled at a relatively low throughput.

The first and second cryptographic data handling systems may be operable for time-diverse error detection. The first and second cryptographic data handling systems may be operable in dual core lock step (DCLS).

The secure computing module comprises an interface for interfacing with the safety processor and the memory, the interface comprising first and second interface circuits operable together to provide hardware redundancy. The first and second interface circuits may be arranged in DCLS.

The safety processor may comprise first and second cores operable together to provide hardware redundancy. The first and second cores may be arranged for time-diverse error detection. The first and second cores may be arranged in DCLS.

The secure computing module may comprise a hardware security module (HSM). The first and second cryptographic units may comprise first and second Advanced Encryption Standard (AES) units respectively. The first and second cryptographic units may comprise first and second SM4 block cipher units respectively. The first and second data transfer units may comprise first and second direct memory access (DMA) controllers respectively. The first and second cryptographic units may be arranged such that, when coupled to provide a redundancy-incorporating cryptographic unit, the redundancy-incorporating cryptographic unit is able to support AES Galois/Counter Mode (AES-GCM) operation.

In the first mode, the first cryptographic data handling system may be operable to process first data stored in the memory and the second cryptographic data handling system is operable to process second, different data stored the memory, simultaneously. In the second mode, the first and second cryptographic data handling systems may be operable to process the first and second data sequentially.

The safety processor may be configured, in response to receiving or transmitting encrypted safety data, to send a request to the switch to cause the secure computing module to switch from the first mode to second mode.

The switch may comprise a state monitor and the selector circuitry may comprise a set of selectors. Each selector in the set of selectors may be arranged to communicate its state to the state monitor. The switch may be configured to determine the respective states of the selectors in the set of selectors and, upon determining the states are in the correct respective states, to switch states.

The secure computing module may further comprise a cryptographic signature or hash engine. The cryptographic signature or hash engine may be a first cryptographic signature or hash engine and the secure computing module may further comprise a second signature engine. The first cryptographic data handling system and the first cryptographic signature or hash engine are operable to process a first code block in a booting process and the second cryptographic data handling system and the second cryptographic signature or hash engine are operable to process a second code block during the booting process.

The integrated circuit may further comprise a communications controller for receiving and transmitting data from a bus. The communications controller may be operable to receive received data and to store the received data in the memory and to retrieve transmit data from the memory and to transmit the transmit data. The communications controller may be an Ethernet controller. The communications controller may be a controller area network (CAN) controller. The CAN controller may be operable to CAN <NUM> and/or CAN FD standards. The communications controller may be a FlexRay controller.

The switch may comprise a scheduler and a timer. The scheduler may be configured, in response to the timer reaching a first pre-defined value T1, to cause the secure computing module to switch from the first mode to the second mode and, in response to the time reaching a second pre-defined value T2, to cause the secure computing module to switch from the second mode to the first mode.

The integrated circuit may further comprise an error module. The switch may be configured to monitor states of selectors in the selector circuitry and, in response to a given selector or the switch determining that the given selector is in an erroneous state, the given selector and/or switch sending an error signal to the error module.

The hardware redundancy in the integrated circuit is preferably sufficient to support Automotive Safety Integrity Level (ASIL) level D.

The integrated circuit may be a microcontroller or a system-on-a-chip (SoC).

According to a second aspect of the present invention, there is provided a vehicle, such as a motor vehicle, comprising a communications bus and at least two nodes arranged to communicate via the communications bus, each node comprising an integrated circuit of the first aspect.

The motor vehicle may be a motorcycle, an automobile (sometimes referred to as a "car"), a minibus, a bus, a truck or lorry. The motor vehicle may be powered by an internal combustion engine and/or one or more electric motors.

According to a third aspect of the present invention, there is provided a switching method. The method comprises selectively coupling and uncoupling first and second cryptographic data handling systems. The first cryptographic data handling system may comprise a first cryptographic unit and a first data transfer unit and the second cryptographic data handling system may comprise a second cryptographic unit and a second data transfer unit. In a first mode, the first and second cryptographic data handling systems uncoupled and operable independently of each other and, in a second mode, the first and second cryptographic data handling system are coupled and operable together to provide hardware redundancy.

The method may comprise coupling the first and second cryptographic data handling systems in response to a request from a safety processor and, later, uncoupling the first and second cryptographic data handling systems. Uncoupling the first and second cryptographic data handling systems may be in response to finishing processing a set of data. Uncoupling the first and second cryptographic data handling systems may be in response to another request from the safety processor.

The method may comprise coupling the first and second cryptographic data handling systems in response to a timer value reaching a predetermined timer value threshold and, later, uncoupling the first and second cryptographic data handling systems. Uncoupling the first and second cryptographic data handling systems may be in response to the timer reaching another predetermined timer value threshold.

In the following description, like parts are denoted by like reference numerals.

It is desirable for microcontrollers and systems-on-a-chips (SoCs) to be able to handle, among others, two specific use cases, namely secure boot to detect manipulated code and secure communication to detect manipulated message data.

Hitherto, functional safety and security have been treated separately in such devices. It is, however, desirable to combine functional safety and security for a number of different reasons, such as, for example, trying to avoid conflicting requirements in functional safety and security, and to reduce complexity of devices.

In addition to these, integrity, which is a property found in security, can also be put to use in functional safety. In the case of secure boot, integrity of code which in embedded or external flash memory can be checked. Checking the integrity of the code can render the need for performing an additional cyclic redundancy check (CRC) of the code unnecessary and so help to speed-up start time of the device. In the case of secure communication, integrity of message data can be checked using a security measure, such as cipher-based message authentication code (CMAC) or encryption with a digest tag. Checking the integrity of the message data in one of these ways means that additional end-to-end protection superfluous.

To handle the secure boot and secure communication use cases, a microcontroller or an SoC can use a secure computing module in the form of an HSM.

Referring to <FIG>, a first integrated circuit <NUM> for use in safety-related applications is shown.

The integrated circuit <NUM> takes the form of a microcontroller or an SoC, and includes a secure computing module <NUM> in the form of an HSM for handling secure boot and secure communication. For example, at start-up, the integrated circuit <NUM> obtains code <NUM>, either from embedded flash memory <NUM> or from external flash memory <NUM>. The veracity of the code <NUM> can be checked using a signature or hash <NUM> (herein after simply referred to as a "signature").

The integrated circuit <NUM> includes, among other things, a flash memory controller <NUM> and a redundancy-incorporating (or "high-reliability") safety processor <NUM> (or "safety control unit"). The safety processor <NUM> is provided with redundancy by virtue of, for example, using two cores <NUM>, <NUM> arranged in DCLS or other suitable arrangement. In <FIG>, DCLS circuitry, such as flip-flops, is not shown for clarity. The integrated circuit <NUM> also includes shared memory <NUM> (or "system memory") in the form of random-access memory (RAM) and a bus system <NUM>.

The integrated circuit <NUM> comprises other elements, such general input/output modules (not shown), communication controllers (not shown) and other peripheral modules (not shown), but which are omitted from <FIG> to aid clarity.

The secure computing module <NUM> is provided with one-time programmable (OTP) read-only non-volatile memory <NUM> for example in the form of an eFuse for providing secure keys <NUM> to the secure computing module <NUM>. The secure computing module <NUM> includes a redundancy-incorporating interface <NUM> (herein referred to as a "master interface"), a secure processor <NUM> provided with memory <NUM>, an interrupt controller <NUM> which can generate interrupts <NUM> and a local clock <NUM> which receive a system clock signal <NUM>.

The secure computing module <NUM> includes a redundancy-incorporating data transfer unit <NUM> in the form of a redundancy-incorporating direct memory access (DMA) controller. The redundancy-incorporating data transfer unit <NUM> is provided with suitable redundancy, for example, using DCLS. The master interface <NUM> can communicate directly with the secure processor <NUM> and the redundancy-incorporating data transfer unit <NUM>. The redundancy-incorporating data transfer unit <NUM> is also able to communicate directly with a redundancy-incorporating cryptography unit <NUM> in the form of a redundancy-incorporating Advanced Encryption Standard (AES) unit. The redundancy-incorporating cryptography unit <NUM> is provided with suitable redundancy, for example, using DCLS, and is able to support AES Galois/Counter Mode (AES-GCM) operation. The redundancy-incorporating data transfer unit <NUM> is provided with suitable redundancy to support AES-GCM operation. During AES-GCM operation, message data is encrypted at a sender (not shown) and decrypted at a receiver (not shown).

The secure processor <NUM>, the redundancy-incorporating data transfer unit <NUM> and the redundancy-incorporating cryptography unit <NUM> are connected to a module bus system <NUM>. The secure computing module <NUM> also includes a random number generator <NUM> (RNG) in which can generate true random numbers and/or pseudorandom numbers, a public key cryptographic engine <NUM>, a cryptographic signature or hash engine <NUM> herein referred to simply as a "signature engine") for generating a signature or hash, an interval timer <NUM> and a watchdog timer <NUM> ("WDT") connected to the module bus system <NUM>.

In end-to-end communication, there is a trend towards the use of domain controllers and zone servers and gateways. Thus, the amounts of secure communication and high-performance (i.e., high throughput) processing are likely to increase, and the volume of safety-related security communication in AES-GCM mode is also likely to rise. Redundancy, however, cannot be relaxed and yet using redundancy generally halves performance. Furthermore, only a proportion (for example, less than <NUM>% or <NUM>%) of secure messages may be safety-related.

One solution to maintaining or increasing performance is to add hardware accelerators.

Referring to <FIG>, a second integrated circuit <NUM>' is shown. The second integrated circuit <NUM>' is the same as the first integrated circuit <NUM> (<FIG>), but differs in that it includes an additional hardware accelerator in the form of a (non-redundancy-incorporating) cryptography unit <NUM> outside of the secure computing module <NUM>.

Redundancy-incorporating parts <NUM>, <NUM> of the secure computing module <NUM> are used for secure communication employing AES-GCM, while the cryptography unit <NUM> is used for secure, non-safety-related communication and for safety communication that requires only authentication, such as CMAC. This approach, however, increases complexity, die size and cost.

Referring to <FIG>, a third integrated circuit <NUM> is shown.

The integrated circuit <NUM> takes the form of a microcontroller or an SoC, and includes a secure computing module <NUM> in the form of an HSM for handling secure boot and secure communication. For example, at start-up, the integrated circuit <NUM> obtains code <NUM>, either from embedded flash memory <NUM> or from external flash memory <NUM>. The veracity of the code <NUM> can be checked using a signature or hash <NUM>.

The integrated circuit <NUM> includes, among other things, a flash memory controller <NUM> and a redundancy-incorporating safety processor <NUM> (or "safety control unit"). The safety processor <NUM> executes safety-related applications (not shown). The safety processor <NUM> is arranged to satisfy safety requirements for an application up to Automotive Safety Integrity Level (ASIL) level C or D (as defined by ISO <NUM>). Thus, the safety processor <NUM> is provided with redundancy by virtue of, for example, using two cores <NUM>, <NUM> (a "master core" and a "checker core") arranged in DCLS or other suitable time-diverse arrangement. In <FIG>, DCLS circuitry, such as flip-flops, is not shown for clarity. If a lower level of safety requirement is sufficient, then other less-stringent error-detecting arrangements can be used such as simple-redundancy or a single core with a self-check.

The integrated circuit <NUM> also includes shared memory <NUM> (or "system memory") and a bus system <NUM>. The integrated circuit <NUM> comprises other elements, such general input/output modules (not shown), communication controllers <NUM> (<FIG>) and other peripheral modules (not shown), but which are omitted from <FIG> to aid clarity.

The secure computing module <NUM> is provided with an OTP in the form of an eFuse <NUM> for providing secure keys <NUM>.

The secure computing module <NUM> includes a redundancy-incorporating interface <NUM> (herein referred to as a "master interface") which comprise two interface circuits <NUM>, <NUM> ("master interface" and "checker interface") and time-diverse error detection circuity (not shown) for providing redundancy, a secure processor <NUM> provided with memory <NUM>, an interrupt controller <NUM> which can generate interrupts <NUM> and a local clock <NUM> which receive a system clock signal <NUM>.

The secure computing module <NUM> includes a redundancy-capable data transfer unit <NUM> (herein sometimes referred to as "DTU") which comprises first and second data transfer units <NUM>, <NUM> and time-diverse error detection circuity (not shown) for providing redundancy. The first and second data transfer units <NUM>, <NUM> take the form of respective DMA controllers.

As will be explained in more detail hereinafter, the first and second data transfer units <NUM>, <NUM> are arranged to be selectively coupled and de-coupled via selector circuitry <NUM> so that they can operate together, in parallel, so as to provide time-diverse redundancy based on, for example, DCLS or other suitable arrangement, or separately so as to provide two independently-operable data transfer units <NUM>, <NUM>.

The master interface <NUM> can communicate directly with the secure processor <NUM> and, either directly or via selector circuity <NUM>, with the data transfer unit <NUM>, <NUM>.

The secure computing module <NUM> also includes redundancy-capable cryptography unit <NUM> which comprises first and second cryptography units <NUM>, <NUM> for providing time-diverse redundancy. The first and second cryptography units <NUM>, <NUM> take the form of respective AES units.

As will be explained in more detail hereinafter, the first and second data first and second cryptography units <NUM>, <NUM> are arranged so that, in a first mode ("performance mode"), they can operate separately so as to provide two independently-operable cryptography units <NUM>, <NUM> each working with a respective data transfer unit <NUM>, <NUM> as respective first and second cryptographic data handling systems <NUM>, <NUM> or, in a second mode (or "encrypted/decrypted safety mode" or simply "safety mode"), they can operate together, in parallel, and so provide time-diverse redundancy based on DCLS or other suitable arrangement to support AES-GCM operation (or other suitable form of authenticated encryption).

The secure processor <NUM>, the data transfer units <NUM>, <NUM> and the redundancy-incorporating cryptography unit <NUM> are connected to an internal module bus system <NUM> (or simply "module bus"). The secure computing module <NUM> also includes a random number generator <NUM> for generating true random numbers and/or pseudo random numbers, a public key cryptographic engine <NUM>, a cryptographic signature or hash engine <NUM> (herein referred to simply as a "signature engine"), an interval timer <NUM> and a WDT <NUM> connected to the module bus <NUM>.

Circuity <NUM> (herein referred to as "selector circuitry" or "switching circuitry") is provided in the secure computing module <NUM> to control data paths between the transfer units <NUM>, <NUM> and the cryptography units <NUM>, <NUM>, the master interface <NUM> and the module bus <NUM>.

Outside the secure computing module <NUM>, switching between modes is controlled and monitored using a redundancy-incorporating switch <NUM> (herein referred to as a "safety-performance secure switch" or "SPSS") comprising first and second switch circuits <NUM>, <NUM> and circuitry (not shown) for providing time-diverse redundancy.

The integrated circuit <NUM> also includes an error module <NUM>. The error module <NUM> collects error signals from safety mechanisms implemented in hardware and, based on the error signals and a configurable set of rules, takes action, such as perform a reset or transmit an error signal outside the device <NUM> to an external device (not shown). Using the selector circuitry <NUM> and the SPSS <NUM>, the transfer units <NUM>, <NUM> and the cryptography units <NUM>, <NUM> can be switched (on demand or automatically based predefined rules) between performance mode in which two separate cryptographic data handling systems <NUM>, <NUM> can operate independently of each other to process secure non-safety-related data or safety-related data requiring only authentication in parallel or the safety mode in which there is hardware redundancy to support secure, safety-related mode of operation, such as AES-GCM.

The safety processor <NUM> can request switching on demand (i.e., asynchronously). Alternatively, a programmable scheduler <NUM> (<FIG>) with an embedded timer <NUM> (<FIG>) can provide automatic switching (i.e., synchronously).

Performance mode is the default mode. Thus, the transfer units <NUM>, <NUM> and cryptography units <NUM>, <NUM> normally operate in performance mode and, when necessary, switch to safety mode, then switch back to performance mode once processing in safety mode is completed.

As will be described in more detail hereinafter, the selector circuitry <NUM> provides feedback to the SPSS <NUM> to allow state monitoring. Furthermore, error monitoring and notification is used to report errors to the error module <NUM>, for example, for the purpose of redundancy and/or for identifying incorrect selectors states. The SPSS <NUM> is preferably configured to switch only when the secure computing module <NUM> is ready, for instance, after any pending tasks by the transfer units <NUM>, <NUM> and cryptography units <NUM>, <NUM> are completed.

As will also be described in more detail hereinafter, an additional signature or hash engine <NUM> (<FIG>) may be used to provide redundancy and so provide acceleration for secure boot.

Referring also to <FIG>, switching between performance and safety modes <NUM>, <NUM> for processing received secure, non-safety-related data <NUM>, received secure, safety-related data <NUM>, to-be-transmitted secure, non-safety-related data <NUM> and to-be-transmitted secure, safety-related data <NUM> in a communication cycle <NUM> is shown.

Prior to receiving secure, safety-related data <NUM>, received secure, non-safety-related data <NUM> and to-be-transmitted secure, non-safety-related data <NUM> are processed in parallel by the secure computing module <NUM> in performance mode <NUM>. If secure, safety-related data <NUM> are received, then the SPSS <NUM> triggers the switch to safety mode <NUM> and the received secure, safety-related data <NUM> are processed by the secure computing module <NUM> in safety mode <NUM> (at a lower throughput). Once completed, the SPSS <NUM> switches the secure computing module <NUM> back to performance mode <NUM> up on request from the safety core <NUM> and further received secure, non-safety-related data <NUM> and to-be-transmitted secure, non-safety-related data <NUM> are processed in parallel in performance mode <NUM> until secure, safety-related data <NUM> are received and/or secure, safety-related data <NUM> is to be transmitted.

Referring to <FIG> and <FIG>, relative gain in performance achieved by dynamically switching between performance and safety modes <NUM>, <NUM> is schematically illustrated over the course of a communication cycle <NUM> having a duration Tcycle.

Referring in particular to <FIG>, using static redundancy provided by the first integrated circuit <NUM> (<FIG>), the secure computing module <NUM> (<FIG>) processes all received secure, non-safety-related data <NUM> and to-be-transmitted secure, non-safety-related data <NUM> are processed sequentially, in this case, in an interleaved way. The secure computing module <NUM> (<FIG>) then processes the received secure, safety-related data <NUM>. The secure computing module <NUM> (<FIG>) then continues to process further received secure, non-safety-related data <NUM> and to-be-transmitted secure, non-safety-related data <NUM> are processed sequentially. The time taken by the secure computing module <NUM> (<FIG>) to process the received and to-be-transmitted data <NUM>, <NUM>, <NUM>, <NUM> in the communication cycle <NUM> is Tstatic, where Tstatic > Tcycle.

Referring in particular to <FIG>, using dynamic redundancy, received secure, non-safety-related data <NUM> and to-be-transmitted secure, non-safety-related secure data <NUM> are processed in parallel by the secure computing module <NUM> (<FIG>) in performance mode <NUM>. Accordingly, the time taken by the secure computing module <NUM> (<FIG>) to process the received and to-be-transmitted data <NUM>, <NUM>, <NUM>, <NUM> in the communication cycle <NUM> is Tdynamic < Tstatic.

Referring to <FIG>, the secure computing module <NUM> and SPSS <NUM> are shown in more detail.

As explained earlier, the master interface <NUM>, the data transfer units <NUM>, <NUM>, the cryptography units <NUM>, <NUM> and the SPSS <NUM> are provided with error detection circuitry as part of a redundancy provision. In particular, the master interface <NUM> is provided with a first comparator <NUM> which compares the respective outputs of the two interface circuits <NUM>, <NUM> in which a time delay (e.g. two clock cycles) is introduced at different points in separate paths based on the DCLS principle. For instance, a delay is introduced before the first interface circuit <NUM> and a corresponding delay is added after the second interface circuit <NUM>. Delay circuits for providing DCLS are not shown for clarity. The data transfer units <NUM>, <NUM> are provided with a second comparator <NUM> which compares the respective outputs (in this case, three outputs) of the data transfer units <NUM>, <NUM> in which a time delay is introduced at different points in separate paths based on the DCLS principle. Delay circuits for providing DCLS are not shown for clarity. The cryptography units <NUM>, <NUM> are provided with a third comparator <NUM> which compares the respective outputs (in this case, two outputs) of cryptography units <NUM>, <NUM> in which a time delay is introduced at different points in separate paths based on the DCLS principle. Delay circuits for providing DCLS are not shown for clarity. The SPSS <NUM> is provided with a fourth comparator <NUM> which compares outputs of the first and second switch parts <NUM>, <NUM> in which a time delay is introduced at different points in separate paths based on the DCLS principle. Delay circuits for providing DCLS are not shown for clarity. If an error is detected by a comparator <NUM>, <NUM>, <NUM>, <NUM>, then the comparator <NUM>, <NUM>, <NUM>, <NUM> transmits an error signal to the error module <NUM>.

The selector circuity <NUM> includes a set of (in this case, nine) selectors <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM> (collectively referred to as "selectors <NUM>"). The selector circuity <NUM> may include more or fewer selectors <NUM> and/or the selectors <NUM> may be differently arranged.

Each of the selectors <NUM> receives respective control signals from the SPSS <NUM> via a selector control line <NUM> and returns respective selector states to the SPSS <NUM> via a selector state line <NUM>.

Each of the selectors <NUM> has first and second inputs, namely '<NUM>' and '<NUM>'. The input 'o' is selected when operating in performance mode and '<NUM>' is selected when operating in safety mode.

First and second selectors <NUM><NUM>, <NUM><NUM> are used for state monitoring when operating in safety mode. The first selector <NUM><NUM> receives an output from the second comparator <NUM> which is used for monitoring the first and second data transfer units <NUM>, <NUM> when they operate in concert as a redundancy-incorporating data transfer unit <NUM> (<FIG>). Likewise, the second selector <NUM><NUM> receive an output from the third comparator <NUM> which is used to monitor the first and second cryptographic units <NUM>, <NUM> when operating together as redundancy-incorporating cryptographic unit <NUM> (<FIG>). The first and second selectors <NUM><NUM>, <NUM><NUM> signal error states to the error module <NUM>.

The master interface <NUM>, the data transfer units <NUM>, <NUM>, the cryptographic unit <NUM>, <NUM>, module bus <NUM> and selectors <NUM> are connected by a plurality of data paths <NUM>,.

A first data path <NUM>, <NUM> runs from the master interface <NUM> to the first data transfer unit <NUM>. A second data path <NUM>, <NUM> runs from the module bus <NUM> to the first data transfer unit <NUM>. A third data path <NUM> runs from the first data transfer unit <NUM> to the master interface <NUM>. A fourth data path <NUM> runs from the first data transfer unit <NUM> to the module bus <NUM>. A fifth data path <NUM>, <NUM> runs from the first data transfer unit <NUM> to the first cryptography unit <NUM>.

A sixth data path <NUM> runs from the master interface <NUM> to a first input of a third selector <NUM><NUM>. A seventh data path <NUM>, <NUM> runs from the master interface <NUM> to a second input of a third selector <NUM><NUM>. A section <NUM> of the seventh data path <NUM>, <NUM> from the master interface <NUM> is shared with the first data path <NUM>, <NUM>. An eighth data path <NUM> runs from the output of the third selector <NUM><NUM> to the second data transfer unit <NUM>. The third selector <NUM><NUM> is used for switching the eighth data path <NUM> into the second data transfer unit <NUM> between the sixth and seventh data paths <NUM>, <NUM> in performance mode and safety mode respectively.

A ninth data path <NUM> runs from the module bus <NUM> to a first input of a fourth selector <NUM><NUM>. A tenth data path <NUM>, <NUM> runs from the module bus <NUM> to a second input of a fourth selector <NUM><NUM>. A section <NUM> of the tenth data path <NUM>, <NUM> from the module bus <NUM> is shared with the second data path <NUM>, <NUM>. An eleventh data path <NUM> runs from the output of the fourth selector <NUM><NUM> to the second data transfer unit <NUM>. The fourth selector <NUM><NUM> is used for switching the eleventh data path <NUM> between the ninth and tenth data paths <NUM>, <NUM> in performance mode and safety mode respectively.

A twelfth data path <NUM> runs from the second data transfer unit <NUM> to a first input of a fifth selector <NUM><NUM>. The second input of the fifth selector <NUM><NUM> receives an inactive value. A thirteenth data path <NUM> runs from the output of the fifth selector <NUM><NUM> to the master interface <NUM>.

A fourteenth data path <NUM> runs from the second data transfer unit <NUM> to a first input of a sixth selector <NUM><NUM>. The second input of the sixth selector <NUM><NUM> receives an inactive value. A fifteenth data path <NUM> runs from the output of the sixth selector <NUM><NUM> to the module bus <NUM>.

A sixteenth data path <NUM> runs from the second data transfer unit <NUM> to a first input of a seventh selector <NUM><NUM>. A seventeenth data path <NUM>, <NUM> runs from the first data transfer unit <NUM> to the second input of the seventh selector <NUM><NUM>. A section <NUM> of the seventeenth data path <NUM>, <NUM> is shared with the fifth data path <NUM>, <NUM>.

As mentioned hereinbefore, the fifth data path <NUM>, <NUM> runs from the first data transfer unit <NUM> to the first cryptography unit <NUM>. An eighteenth data path <NUM>, <NUM> runs from the module bus <NUM> to the first cryptography unit <NUM>. A nineteenth data path <NUM> runs from the first cryptography unit <NUM> to the module bus <NUM>.

A twentieth data path <NUM> runs from the module bus <NUM> to a first input of an eighth selector <NUM><NUM>. A twenty-first data path <NUM>, <NUM> runs from the module bus <NUM> to a second input of the eighth selector <NUM><NUM>. A section <NUM> of the twenty-first data path <NUM>, <NUM> is shared with the eighteenth data path <NUM>, <NUM>. A twenty-second data path <NUM> runs from the output of the eighth selector <NUM><NUM> to the second cryptography unit <NUM>. The eighth selector <NUM><NUM> is used for switching the twenty-second data path <NUM> into the second cryptography unit <NUM> between the twentieth and twenty-first paths <NUM>, <NUM> from the module bus <NUM> in performance mode and safety mode respectively.

A twenty-third data path <NUM> runs from the output of the seventh selector <NUM><NUM> to the second cryptography unit <NUM>. A twenty-fourth data path <NUM> runs from the second cryptography unit <NUM> to a first input of a ninth selector <NUM><NUM>. The second input of the ninth selector <NUM><NUM> receives an inactive value. A twenty-fifth data path <NUM> runs from the output of the ninth selector <NUM><NUM> to the module bus <NUM>.

Referring still to <FIG>, the SPSS <NUM> includes configuration registers <NUM>, state monitoring logic <NUM>, a scheduler <NUM> (for automatic mode) and timer <NUM>.

The SPSS <NUM> controls the selectors <NUM> to switch between the two modes on request from the safety core (on-demand switching mode) or automatically based on the scheduler <NUM> (automatic mode). The state (i.e., which input is selected for the output) of each of the selectors <NUM> is monitored using the feedback signal <NUM> to the SPSS <NUM>. If the reported state is not as expected, then an error signal is notified to the error module <NUM> for handling.

Referring to <FIG> and <FIG>, operation of the secure computing module <NUM> and the SPSS <NUM> during on-demand switching will now be described.

The safety processor <NUM> sends a request <NUM> to the SPSS <NUM> to set a flag in the configuration registers <NUM> to switch to safety mode (steps S1 & S2) and sends a request <NUM> to the secure processor <NUM> to encrypt/decrypt data stored in shared memory <NUM> (step S3). The secure processor <NUM> may prepare, for example, by completing processing of secure, non-safety-related data (step S4). The SPSS <NUM> waits until secure processor <NUM> notifies the SPSS <NUM> that it is ready for the mode switch by writing to a dedicated register <NUM> in the SPSS <NUM> (steps S5 & S6). The SPSS <NUM> sets the selectors <NUM> accordingly (step S7). In this case, input '<NUM>' is selected.

The SPSS <NUM> checks the state of each of the selectors <NUM> using the state monitoring function <NUM> (step S8). If any of the selectors <NUM> returns the wrong state, then the SPSS <NUM> sends an unintended mode error message <NUM> to the error module <NUM> (step S9). The check need not be a check at a single point in time. The SPSS <NUM> may continuously perform check (whether in performance or in safety mode) to confirm proper functioning. Once the SPSS <NUM> has confirmed that the selectors <NUM> are in the proper states, it writes the current mode (i.e., safety mode) in a dedicated internal register <NUM> (step S10).

After a short wait time, the secure processor <NUM> reads and checks the new mode (i.e., that is, safety mode) (steps S11, S12 & S13). If in the new mode the secure processor <NUM> loads keys <NUM> from the OTP <NUM> (steps S14 & <NUM>) and configures the cryptographic units <NUM>, <NUM> accordingly (steps S16 & <NUM>). In this case both cryptographic units <NUM>, <NUM> are configured to receive the same data to provide redundancy. The secure processor <NUM> then configures the data transfer units <NUM>, <NUM> to retrieve target data subject to encryption/decryption from the shared memory <NUM> (steps S18 & <NUM>) and triggers it (step S20).

The data transfer units <NUM>, <NUM> load data from shared memory <NUM> and provide it to the cryptographic units <NUM>, <NUM> for encryption/decryption and tag generation (step S21). The cryptographic units <NUM>, <NUM> continue to perform encryption/decryption as long as the data transfer units <NUM>, <NUM> supply new data. Encrypted/decrypted data are stored in the shared memory <NUM>. The secure processor <NUM> reads data transfer configuration data (step S22 & S23) and, if processing has finished, notifies the safety processor <NUM> that operations have completed (steps S24 & <NUM>).

The safety processor <NUM> sets a request <NUM> to switch back to performance mode in the internal register <NUM> in the SPSS <NUM> and notifies the secure processor <NUM> accordingly (step S26 & S27).

The secure processor <NUM> reads and checks the performance mode is entered (steps S29 & S30). If in performance mode, the secure computing module <NUM> proceeds with the next data (step S31). Any requests for performance mode are buffered while in safety mode.

Referring to <FIG> and <FIG>, for fully synchronous secure communication, the SPSS <NUM> can operate to schedule switching to/from the safety mode <NUM>.

The SPSS <NUM> includes a scheduler <NUM> and a timer <NUM>. The scheduler <NUM> can perform switching without a dedicated request from the safety core <NUM>.

In one example, time is counted and, depending on a programmed limit (which can vary), the scheduler <NUM> issues a trigger <NUM>. Programmable timer thresholds T1 and T2 are used for switching to safety mode and back to performance mode respectively. Typically, T1 > T2, i.e., the secure computing module <NUM> operates in performance mode for a longer period of time than in safety mode.

Referring to <FIG>, a fourth integrated circuit <NUM>' is shown. The fourth integrated circuit <NUM>' is the same as the third integrated circuit <NUM> (<FIG>), but differs in that it includes an additional signature or hash engine <NUM> in the secure computing module <NUM>. The interrupt controller <NUM> (<FIG>), clock <NUM> (<FIG>) and selector circuitry <NUM> (<FIG>) are omitted and the data transfer units <NUM>, <NUM> and cryptography units <NUM>, <NUM> presented in a simplified form for clarity.

When the device <NUM>' is powered on, the default mode is the performance mode.

If two signature or hash engines <NUM>, <NUM> are implemented inside the secure computing module <NUM>, it is possible to accelerate the secure boot. In particular, one set of data transfer unit <NUM>, cryptography unit <NUM> and signature or hash engine <NUM> can execute the secure boot on one code block <NUM><NUM> using its corresponding signature or hash <NUM><NUM> while the other set of data transfer unit <NUM>, cryptography unit <NUM> and signature or hash engine <NUM> can execute the secure boot on another code block <NUM><NUM> using its corresponding signature or hash <NUM><NUM> in parallel. The signature or hash engines <NUM>, <NUM> are used to generate a local signature or hash (not shown) for comparing with a received signature or hash <NUM><NUM>, <NUM><NUM>.

Referring to <FIG>, a motor vehicle <NUM> is shown in which a communications network <NUM> is deployed which includes nodes <NUM>, <NUM><NUM>, <NUM><NUM> connected to a bus <NUM>. The communications network <NUM> may be an Ethernet network, a controller area network (CAN) operable to CAN <NUM> and/or CAN FD standards, or FlexRay. There may be more than one network and there may be two or networks of different types.

Each node <NUM> comprises an integrated circuit <NUM> as hereinbefore described which is capable of dynamic switching between performance and safety modes <NUM>, <NUM>. For clarity, only two nodes are shown.

It will be appreciated that various modifications may be made to the embodiments hereinbefore described. Such modifications may involve equivalent and other features which are already known in the design, manufacture and use of integrated circuits for use in functional safety and security and component parts thereof and which may be used instead of or in addition to features already described herein. Features of one embodiment may be replaced or supplemented by features of another embodiment.

Other forms of error detection can be used. For example, if a safety level permits, single core with self-check or simple redundancy (without time diversity) may be used.

The data transfer units can take other forms such as data transfer system (DTS) or data transfer function (DTF).

Other forms of block cipher may be used instead of AES, such as SM<NUM>. Other forms of authenticated encryption may be used instead GCM. For example, Cipher Code Block (CBC), Output Feed Back (OFB), Cipher Feed Back (CFB), Counter (CTR), cypher chaining message (CCM), ChaCha20-Poly1305, or XEX-based tweaked-codebook mode with ciphertext stealing (XTS) may be used.

Additional safety mechanisms, such as cyclical redundancy code (CRC), may be provided, for example, to help support higher safety levels.

Other implementations of selector circuitry can be used.

Claim 1:
An integrated circuit (<NUM>; <NUM>') comprising:
· a safety processor (<NUM>);
· a memory (<NUM>); and
· a secure computing module (<NUM>), comprising:
- a secure processor (<NUM>);
- first and second cryptographic units (<NUM>, <NUM>) for encrypting and decrypting data in the memory; and
- first and second data transfer units (<NUM>, <NUM>) for transferring data between the memory and the first and second cryptographic units respectively;
wherein the first cryptographic unit and the first data transfer unit provide a first cryptographic data handling system (<NUM>), and the second cryptographic unit and the second data transfer unit provide a second cryptographic data handling system (<NUM>);
the integrated circuit further comprising:
· a switch (<NUM>);
and the secure computing module further comprises:
- selector circuitry (<NUM>) for selectively coupling and uncoupling the first and second cryptographic data handling systems in response to control signals from the switch, such that:
in a first mode, the first and second cryptographic data handling systems are uncoupled and operable independently of each other; and
in a second mode, the first and second cryptographic data handling system are coupled and operable together to provide hardware redundancy.