WO2022100812A1

WO2022100812A1 - Integrated circuit, method for operating the integrated circuit, computer program product, electronic control unit and vehicle

Info

Publication number: WO2022100812A1
Application number: PCT/EP2020/081575
Authority: WO
Inventors: Florian REHM; Vladislav RUMYANTSEV
Original assignee: Zf Cv Systems Global Gmbh
Priority date: 2020-11-10
Filing date: 2020-11-10
Publication date: 2022-05-19

Abstract

-25- Abstract Integrated Circuit, Method for Operating the Integrated Circuit, Computer Program Product, Electronic Control Unit and Vehicle The invention relates to an integrated circuit for controlling components in a vehicle, to a method for operating such integrated circuit, to a computer program product, to an electronic control unit comprising the integrated circuit and to a vehicle comprising it. For providing varying levels of capabilities and security infrastructure, as different lifecycle phases may require, while at the same time preventing fraudulent use, lifecycle states are introduced in the integrated circuit, between which transitions are restricted to those forming an acyclic directed graph. (Fig. 2)

Description

Integrated Circuit, Method for Operating the Integrated Circuit, Computer Program Product, Electronic Control Unit and Vehicle

The invention relates to an integrated circuit for an electronic control unit, in particular for an electronic control unit for controlling components in a vehicle, in particular a utility vehicle. The invention also relates to a method for operating the integrated circuit, to a computer program product, to an electronic control unit comprising the integrated circuit or implementing the method, and to a vehicle comprising the integrated circuit or the electronic control unit.

In today’s vehicles, electronic control units, also abbreviated as ECUs, are used to control braking systems, automatic transmissions, suspension systems, motor control systems, and the like.

With respect to a life cycle of ECUs, development, testing, manufacturing, operation, and field debugging are different life cycle phases, which involve specific actors and may involve that the ECU is put into respectively dedicated operating environments. A similar concept of lifecycles and phases is laid out and known from [6].

During some life cycle phases related to development, testing and manufacturing of an ECU, usage of powerful diagnostic capabilities like interfaces and software functions is typically required. Examples of such diagnostic capabilities are the known JTAG [1][2] and XCP [13] interfaces, and diagnostic services.

Similarly, towards the end of a manufacturing phase, conceptually general purpose ECUs are often parametrized and customized for use in a specific type of vehicle. This may comprise setting parameter values, allowing or disallowing commands, and the like. For this phase, sometimes known as “end of line customization”, some diagnostic capabilities and software functions are required, although maybe not as many as in the development, testing and (general) manufacturing phases. As part of customization, crypto material like keys, credentials, certificates and the like are perhaps being entered into specially protected memory of the ECU hardware, which also requires extended access capabilities.

Parametrization and customization for use in a specific type of vehicle or even for use in a specific single vehicle out of a series may also take place during a phase known as “OEM manufacturing”. OEM manufacturing may also comprise its own part of entering crypto material into the device. This is motivated from the OEM perspective for instance for implementing a uniform diagnosis interface under full OEM control, even if there are several ECU suppliers. It also contributes to clarify and separate the crypto material’s maintenance and responsability.

On the other hand, as a drawback, many if not all diagnostic capabilities could cause or contribute to compromising the overall ECU cybersecurity, if they were also enabled or present during other life cycle phases, for example those that are more operation related.

Trying to reduce this risk by generally adding cybersecurity controls to the diagnostic capabilities, can easily delay the development and testing during the active development of the product. Similarly, generally enabling existing cybersecurity features like secure flash updating of the ECU prevents developers from easily and/or swiftly testing new software versions.

In another aspect, after an ECU has been in operation with restricted or absent diagnostic capabilities and security features enabled, field claims related to malfunctions or performance issues may be raised. In that case, it is necessary to go into a claims handling phase and identify the root cause. For this purpose at least some diagnostic capabilities and functions need to be available. More than that, if a specific, individual ECU that has been in operation and gave rise to claims has collected any kind of usage data in an internal log, it may be unavoidable that the diagnostic capabilities needed for claims handling must be re-enabled on that specfic ECU. On the other hand, after such re-enabling of diagnostic capabilities and functions for an ECU that already had been in operation, the security of this ECU cannot be ensured any more. Therefore those ECUs must not be used in any series vehicles anymore. Furthermore such ECUs with re-enabled diagnostic capabilities bear the risk of cryptographic keys and IP of WABCO being extracted by unauthorized 3rd parties.

Against this background, a first aspect of the invention aims to achieve the object of providing an integrated circuit that allows to provide varying levels of capabilities and security infrastructure, as needed in the different lifecycle phases, while at the same time preventing any fraudulent use thereof.

A second aspect of the invention aims to achieve the object of providing a method to operate the integrated circuit in such a way that varying levels of capabilities and security infrastructure are provided in different lifecycle phases, while at the same time fraudulent use thereof is prevented.

A third aspect of the invention aims to achieve the object of providing a computer program product that implements the method of the invention.

A fourth aspect of the invention aims to achieve the object of providing an Electronic Control Unit which, using the integrated circuit, allows to provide those varying levels of capabilities and security infrastructure, while at the same time preventing any fraudulent use thereof.

A fifth aspect of the invention aims to achieve the object of providing a vehicle that comprises the Electronic Control Unit according to the fourth aspect.

In the first aspect of the invention, the object is achieved by an integrated circuit for an Electronic Control Unit, which comprises a central processing unit programmed in such a way that only commands selected from a configurable allowed command set which is a subset of a predefined overall command set are being processed. The integrated circuit also comprises at least one interface for connecting the integrated circuit to an external component and a status register equipped and configured to indicate a lifecycle state of the integrated circuit being one of at least a first lifecycle state, a second lifecycle state, and a third lifecycle state. In each lifecycle state of the integrated circuit, one allowed command set applies.

With other words, the integrated circuit is programmed in such a way that, as long as it is running in one lifecycle state, commands from outside of the allowed command set applying for that lifecycle state are either being refused or the associated action simply doesn’t take place.

The integrated circuit is programmed to perform lifecycle state transitions. According to the invention, the integrated circuit is equipped such that its lifecycle states as graph vertices and the lifecycle state transitions implemented on it, as graph edges, constitute a directed acyclic graph. This means that the state diagram has no closed loops, and that all state transitions are directed and without a “way back”. The mathematical concept of “directed acyclic graph” is well-known and described e.g. in [16]

Having the state diagram constituted as a directed acyclic graph is key to preventing fraudulent use of the integrated circuit.

The notion of “states” and “transitions” indicates, that the ECU is abstracted here in the sense of the known concept of a “finite automaton”. Note that this abstraction does not relate to the operation or running of the ECU or of the integrated circuit within any one of the lifecycle states, but rather to the level where transitions take place between lifecycle states. Within each lifecycle state, and as long as that lifecycle state is not being “left” by a lifecycle state transition, the integrated circuit - or the ECU containing it - operates like a normal, known programmable controller.

To further illustrate the concepts of lifecycle state transitions in connection with allowed command sets, it must be noted that allowed command sets can arbitrarily be assigned to lifecycle states, as lifecycle phases in a particular implementation or the lifecycle states used to model them may require. In particular, depending on those choices, transiting from a first lifecycle state into a second lifecycle state may enlarge, reduce, or change the allowed command set, or keep it constant. The notion of “changing” an allowed command set is meant here to denote a case where - under the transition - some additional commands become newly allowed and some previously allowed commands are no longer allowed.

To illustrate the external components which the interfaces allow to connect to, they can be envisaged as random access memory, read only memory, bus interconnections, sensors, actuators, external debug tools and the like.

Advantageously, the status register may be implemented as a monotonic counter, and the lifecycle state transitions are implemented by custom software running inside a hardware security module of the integrated circuit. Using this mechanism, it is possible to ensure that the ECU can only be put in a “later” lifecycle state.

As an advantageous alternative, the status register may be implemented as a write- once register consisting for example of several fuse structures that can be “blown” with a specified current, and the lifecycle state transitions are implemented by appropriately and irreversably writing individual bits of the write-once register.

Advantageously, the integrated circuit comprises a state transition log memory, and is equipped and configured that at least some of the lifecycle state transitions are entered into the state transition log. If that state transition log is implemented in write- once technology, what is entered thereto advantageously becomes unforgeable. Also advantageously, the integrated circuit is equipped and configured that the state transition log entries comprise date and time information of when the transition has taken place, and also comprise authentication information if available, with other words information on who has triggered the transition and what were his provided credentials.

ECUs in a Claims Handling life cycle, with re-extended access capabilites, allow access to information like crypto material, which may jeopardize the security of the entire ECU series, if fallen into fraudulent hands. Therefore, physical access to such ECUs must be restricted to authorized personnel only. At the end of the Claims Handling life cycle, it may no longer be possible to restore all the encapsulation and security features that were in force during operation. Therefore, at the end of their physical lifetime, these ECUs must be suitably disposed of. To reliably prevent any fraudulent use of end-of-lifetime ECUs or integrated circuits, all sensitive information thereon should be actively erased before forwarding them to a recycling contractor. Alternatively, such ECUs would have to be stored in a secure archive for a considerable time.

Advantageously, the integrated circuit is so equipped and configured that at least some of the lifecycle state transitions require authentication.

Advantageously, the integrated circuit is equipped and configured in such a way that the lifecycle state transitions are entered into the state transition log with a pertaining date and time information, and with authentication information if available. In that way, inspection of the state transition log allows to identify which actor triggered a specific state transition, and what her/his entitlements were.

Advantageously, the integrated circuit additionally comprises a substatus register to indicate a sub-state of the integrated circuit for at least one of the lifecycle states. Such integrated circuit is then equipped and configured to perform, within the at least one lifecycle state, sub-state transitions. In the sub-states of the at least one lifecycle state, arbitrarily choosable allowed command sets and interface enablements apply. In contrast to the state diagram of the lifecycle states, the sub-states as graph vertices and the sub-state transitions as graph edges constitute a directed but not necessarily acyclic graph. With other words sub-state transitions may form loops. An alternative way to describe the sub-states is that, within one lifecycle state having its allowed command set, for each sub-state, arbitrarily some of the commands can be disallowed.

Alternatively and equivalently, the interrelation between the lifecycle states and the sub-states can be described as follows: An integrated circuit comprising sub-states and sub-state-dependent allowed command sets is an integrated circuit according to the invention, if a grouping of the sub-states into lifecycle states exists, such that the lifecycle states as graph vertices and the transitions between the lifecycle states as graph edges, constitute a directed, acyclic graph.

In the second aspect of the invention, the object is achieved by a method to operate an integrated circuit that comprises at least one central processing unit, at least one interface, and a status register to indicate a lifecycle state of the integrated circuit. In this, the central processing unit is equipped and configured to process commands from a configurable allowed command set.

According to the invention, the method comprises consecutive steps of

- running the integrated circuit in a first lifecycle state;

- transiting from the first lifecycle state to a second lifecycle state in which the integrated circuit has not been run before; and

- running the integrated circuit in the second lifecycle state.

In this, running the integrated circuit in a particular lifecycle state shall mean that commands from outside the allowed command set associated to the particular lifecycle state are not being performed.

According to the invention, for any such transiting, the second lifecycle state is a lifecycle state in which the integrated circuit has never been run before the transiting. This is equivalent to saying that the state diagram does not contain any loops, because transiting along a loop would mean that at least at some instance of time, a lifecycle state is being reached, in which the circuit has already been run in the past.

It can also be seen here, that the lifecycle states with the allowed command sets tied to them and the allowed state transitions are also well suited in connection with the concept of “diagnostic roles” as described in the “RS_Diag_04232” requirement of [14], Based on the current lifecycle state the integrated circuit or the ECU is in, different diagnostic roles can be authorized to trigger a state transition. For example: During operation, only the diagnostic role "supplier" is allowed to change the lifecycle state into Claims handling. During manufacturing, only the diagnostic role "production" is allowed to change the lifecycle state into operation. This role based state transition management is implemented as a role-based secure diagnostic authentication using digital certificates and cryptographic keys or tokens.

For the special case of the state transition from operation to claims handling, in an advantageous extension, the lifecycle state transition may be restricted by requiring that a unique ECU identifier is embedded as part of the certificate or token. This enables that an actor wanting to transition a particular specimen ECU into claims handling can do so only if he has been assigned that right beforehand, specifically for that specimen, encoded in the certificate or token he has received.

Additionally, certificates or tokens issued to actors can be provided with an expiration date to mitigate the risk in case the keys and certificates or tokens would be stolen. For example: A public key infrastructure, also known as PKI, of the ECU supplier may issue a digital certificate for a specific user including the diagnostic role "supplier" with an expiration date of 7 days after issuance and with a specific ECU identifier or range of ECU identifiers. In this case the holder of the certificate can only switch the lifecycle state of that specific ECU respectively those specific ECUs to claims handling within the 7 day interval. The known concepts of PKI are described for example in [15].

In a further advantageous extension, after an actor has triggered a state transition, a fingerprint of that actor may be stored in a state transition log, to ensure liability. The invention also provides the possibility to disable certain cybersecurity functions during development and claims handling.

If the ECU is in the claims handling lifecycle state then a permanent diagnostic error will be set to avoid putting the device back into a series vehicle. Setting permanent diagnostic errors is a mechanism known today. An ECU having a permanent diagnostic error, when put into a vehicle afterwards, will reliably cause the driver to be informed, e.g. in the vehicle dashboard, that this ECU has been modified and that he should not continue driving, a status that is also known as “red alert”.

One context where disabling cybersecurity functions may be appropriate is in a diagnosis, during the claims handling lifecycle state, of ongoing communication between the ECU and other units. During the operation lifecycle state, messages on a CAN bus may advantageously be encrypted. However, in the claims handling lifecycle state, such encryption would hinder interpreting the observed traffic and make it very complicated to find errors in the communication between different devices.

The invention also provides the possibility to irreversibly disable certain functionalities, after the designed lifetime of the product has been reached. For example: If a supplier provides guaranteed security updates for 15 years, afterwards the provisioning of those updates cannot be ensured due to technological limitations (e.g. cryptographic functions become deprecated, development environment is not maintained anymore). In this case, it is necessary to securely disable functionalities which impose a high cybersecurity risk (e.g. over-the-air updates, cloud connectivity). This can be achieved by changing the ECUs lifecycle state based on the current date and time, proactively and without an actor being involved.

Advantageously, at least for some of the transiting steps, data are entered into a transition log. This is a big help in any claims handling or analysis phase.

Advantageously, for at least some of the transiting steps, authentication is required. An example embodiment of this would employ for the transitions a special command where, either as part of the command itself or as a command parameter, an actor requesting a transition must provide authentication information, the authentication information is checked, and the transition itself is only performed if the check was positive. It may be advisable and advantageous, if all transitions, whether positively checked and performed or not, are entered into the transition log. In the third aspect of the invention, the object is achieved by a computer program product that, when executed in an integrated circuit comprising a CPU, causes the integrated circuit to perform the method according to the invention.

In the fourth aspect of the invention, the object is achieved by an Electronic Control Unit that comprises the integrated circuit according to the invention, or that is equipped and configured to perform the method according to the invention.

In the fifth aspect of the invention, the object is achieved by a vehicle comprising the integrated circuit or the Electronic Control Unit according to the invention.

In the following text, the invention will be explained further using exemplary embodiments which are shown in the drawing, in which

Fig. 1 shows, in symbolic form, lifecycle states and possible transitions between them for a first exemplary embodiment of the invention,

Fig. 2 shows, in symbolic form, lifecycle states and possible transitions between them for a second, more complex exemplary embodiment of the invention,

Fig. 3 shows, in symbolic form, an integrated circuit according to an aspect of the invention, and

Fig. 4 shows, in symbolic form, a vehicle comprising an integrated circuit according to an aspect of the invention.

Fig. 1 shows lifecycle states and possible transitions between them for a first, simple exemplary embodiment of the invention. The Figure amounts to what is known in the art as a “state diagram” or “state transition diagram”. In the first exemplary embodiment, an integrated circuit according to the invention or an ECU comprising the integrated circuit can be in one of three lifecycle states, namely a first lifecycle state 101 , a second lifecycle state 103, and a third lifecycle state 105. Only two lifecycle state transitions simply called “transitions” in the following are possible: A first transition 102, bringing the ECU from the first lifecycle state 101 to the second lifecycle state 103, and a second transition 104, bringing the ECU from the second lifecycle state 103 to the third lifecycle state 105.

For illustrating advantages of the invention, we now arbitrarily assume, that the ECU, when and while in the first lifecycle state 101 ,

• has a write-once error flag having been reset, and

• has an allowed command set 307 comprising commands to control, access and use a first and a second diagnostic interface.

When and while in the second lifecycle state 103, the ECU shall

• have the error flag reset, and

• have an allowed command set 307 not comprising the commands to control, access and use the first and the second diagnostic interface.

When and while in the third lifecycle state 105, the ECU shall

• have the error flag set, and

• have an allowed command set 307 comprising the commands to control, access and use the first diagnostic interface, but not comprising the commands to control, access and use the second diagnostic interface.

From this structure and behaviour, it can be recognized that the lifecycle states 101, 103, 105 of the integrated circuit as graph vertices and the lifecycle state transitions 102, 104 as graph edges constitute a directed acyclic graph.

With respect to the here assumed capabilities of the integrated circuit respectively of the ECU around it, it can be seen that they start very powerful when in the first lifecycle state 101 , they are then strongly reduced in the second lifecycle state 103, and they are re-enabled to some extent but not fully in the third lifecycle state 105. Note that, for re-enabling the capabilities, instead of returning into the powerful first lifecycle state 101 , a dedicated third lifecycle state 105 is provided. This has a first advantage, namely that one is not bound to re-enable all capabilities that were given in the first lifecycle state 101 if only a part of the capabilities are needed. It also has a second advantage, that in the third lifecycle state 105, by virtue of it being a separate dedicated lifecycle state lacking any possibilities to return into the previous lifecycle states 101, 103, one can implement a mechanism to prevent “third lifecycle state integrated circuits” from being used in the previous lifecycle states. In the example shown in Fig. 1 , this is symbolically implemented though not depicted with the error flag, which we assume to be re-set in the first and second lifecycle states 101 , 103, and to be irreversibly set in the third lifecycle state 105.

As mentioned, the allowed command set 307 is independently choosable for each lifecycle state. Hence, by tailoring the individual allowed command sets 307 of the lifecycle states, availability of the debugging tools and accessibility of the IC components can be defined as needed. This can be illustrated by an exemplary embodiment - not depicted - where in a first lifecycle state, the integrated circuit is designed to have a first allowed command set 307 that comprises a first interface control command set to control a first interface, whereas in a second lifecycle state having a second allowed command set 307, the second allowed command set 307 does not comprise the first interface control command set and instead comprises a second interface control command set to control the first interface. With other words, this constitutes switching the way a specific first interface is being controlled from a first interface control command set to a second interface control command set. One area where this may be useful is memory access commands like read or write. It is easily understood that in a development lifecycle phase, memory access should be quick and flexible, hence the first memory access command set may be one which does not comprise any authorizisation checking. On the other hand, in an operation lifecycle phase, it may be mandatory or desirable to block some or all kinds of memory access unless an authorization for that kind of memory access has been positively checked.

Note also that, due to the acyclic directed graph structure of the state diagram, being in one of the lifecycle states 101 , 103, 105 is an unforgeable equivalent to having undergone a specific sequence of previous lifecycle state transitions. More specifically, when the acyclic directed graph-shaped state diagram does not have any ramifications, being in a lifecycle state allows to deduct, without any doubt, the sequence of transitions the integrated circuit must have been through. On the other hand, when the acyclic directed graph-shaped state diagram does have some ramifications with branches re-uniting as shown in the example of Fig. 2, being in a lifecycle state “behind” the reunification point allows to deduct the sequence of transitions not in all detail. Referring to the example of Fig. 2, being in lifecycle state 204 allows one to deduct that the integrated circuit must have undergone, in the very beginning of its lifecycle, the transition 207. But then, lacking further information, it cannot be told whether the integrated circuit has undergone transition 208 directly bringing it from lifecycle state 202 to lifecycle state 204, or whether it has transited from lifecycle state 202 first to lifecycle state 203 and only thereafter to lifecycle state 204.

Fig. 2 shows, in symbolic form, lifecycle states and possible transitions between them for a second, more complex exemplary embodiment of the invention.

In the exemplary embodiment, there are 6 lifecycle states the ECU can be in, namely a development lifecycle state 201 , a production lifecycle state 202, an OEM production lifecycle state 203, an operation lifecycle state 204, a claims handling lifecycle state 205, and an end-of-life lifecycle state 206. Additional lifecycle states may be added for restricted operation modes, for example to provide a degraded functionality after end of maintenance.

During each of the lifecycle states 201, 202, 203, 204, 205, 206, potentially different interface controls and functions are available for e.g. development, testing and manufacturing purposes. The concept of allowing or disallowing certain commands depending on a status is known as such, for example from the “Delegation Model” of Chapter 29 of [12],

In the exemplary embodiment, the lifecycle states and the transitions between them as shown in Fig. 2 are implemented using a monotonic counter inside a “Hardware Security Module” of the ECU. A concept of monotonic counters is known, a description can be found for example in Chapter 3.3 of [3] and in Chapter 17 of [12], A “Hardware Security Module” is a concept known for example from [3], from pages 18-20 of [4], and from [5].

Alternatively, lifecycle states between which only progressive transitions are possible, could also be implemented in an Integrated Circuit by coding the lifecycle state using the known concepts of “eFuse” [8][9][10] and of “Antifuse” [11]. These allow to perform, within an existing Integrated Circuit, specific physical, hence irreversible, modifications of chip topology.

Allowed transitions between the lifecycle states are implemented using a custom software running inside a protected domain within the Hardware Security Module 310 of the integrated circuit.

Depending on the current lifecycle state, the ECU will provide or not provide certain development interfaces and functions.

For example:

• During development and prototyping, the usage of XCP [13] and JTAG [1] interfaces is mandatory. Hence, in the development lifecycle state 201 of the exemplary embodiment, control commands for the XCP interface 304 and the JTAG interface 303 are included in the allowed command set 307.

• During production, the usage of certain diagnostic services is needed to ensure the correct parameterization during End-Of-Line test. Hence, in the production lifecycle state 202 of the exemplary embodiment, the allowed command set 307 comprises commands for debug interfaces except those that would allow to debug the HSM 310 itself.

• During field claims handling, the usage of the JTAG interface 303 and the XCP interface 304 is mandatory. Hence, in the claims handling lifecycle state 205 of the exemplary embodiment, control commands for the XCP and JTAG interfaces 303, 304 except those to access the HSM 310 itself are included in the associated allowed command set 307. • During OEM Production, the usage of certain diagnostic services might be needed to ensure end-of-line parameterization at the customer manufacturing line. Typically, capabilities will not be quite as powerful as in the production lifecycle state 202. This will be reflected in the allowed command set 307 of the OEM production lifecycle state 203 of the exemplary embodiment.

• During operation, all those functions and interfaces must be disabled to avoid compromising the security and therefore the functions of the ECU. Hence, in the operation lifecycle state 204 of the exemplary embodiment, any debug control commands are not included in the allowed command set.307.

• On the other hand, during operation, the allowed command set 307 will be such that additional security features such as encrypted communication on a CAN bus, or mandatory authorization for some commands, are supported.

The transitions between the lifecycle states - if allowed at all - are implemented in this exemplary embodiment using protected diagnostic commands as provided by the HSM architecture [3, 5].

For the exemplary embodiment,

• Away from the development lifecycle state 201 , only a third lifecycle state transition 207 is allowed, which brings the integrated circuit into the production lifecycle state 202. Note that there is no state transition from the Production lifecycle state 202 back into the development lifecycle state 201.

• Away from the production lifecycle state 202, only a fourth lifecycle state transition 208 or a fifth lifecycle state transition 210 are allowed. The fourth lifecycle state transition 208 brings the integrated circuit into the operation lifecycle state 204, whereas the fifth lifecycle state transition 210 brings the integrated circuit into the OEM production lifecycle state 203. Note that, neither from the operation lifecycle state 204 nor from the OEM production lifecycle state 203, a state transition back into the production lifecycle state 202 exists.

• Away from the OEM production lifecycle state 203, only a sixth lifecycle state transition 211 is allowed, which brings the integrated circuit into the operation lifecycle state 204. Note that there is no state transition from the operation lifecycle state 204 back into the OEM production lifecycle state 203. • Away from the operation lifecycle state 204, only a seventh lifecycle state transition 209 or an eighth lifecycle state transition 212 are allowed. The seventh lifecycle state transition 209 brings the integrated circuit into the end- of-life lifecycle state 206, whereas the eighth lifecycle state transition 212 brings the integrated circuit into the claims handling lifecycle state 205. Note that, neither from the end-of-life lifecycle state 206 nor from the claims handling lifecycle state 205, a state transition back into the operation lifecycle state 204 exists.

• Away from the claims handling lifecycle state 205, only a ninth lifecycle state transition 213 is allowed, which brings the integrated circuit into the end-of-life lifecycle state 206. Note that there is no state transition from the end-of-life lifecycle state 206 back into the claims handling lifecycle state 205.

• Away from the end-of-life lifecycle state 206, no lifecycle state transition at all exists, so that, in this embodiment, an integrated circuit that has reached the end-of-life lifecycle state 206, will stay there until destruction.

From this structure and behaviour, it can be recognized that the lifecycle states of the integrated circuit as graph vertices and the lifecycle state transitions as graph edges constitute a directed acyclic graph.

Fig. 3 shows, in symbolic form, an integrated circuit 301 according to an aspect of the invention. The integrated circuit 301 comprises a central processing unit or CPU 302, interfaces 303, 304, 305, and a status register 306. It may additionally comprise a substatus register 309. The interfaces may comprise a JTAG interface 303, an XCP interface 304 and a diagnostic interface 305. The CPU 302 is equipped and configured to be able to process commands from an allowed command set 307 which is a subset of an overall command set 308. Which commands of the overall command set 308 are contained in the allowed command set 307 depends on and is controlled by the value contained in the status register 306 and - if existing - on the value contained in the substatus register 309. Those commands of the overall command set 308 that are not contained in the allowed command set 307 cannot be processed by the CPU 302. The CPU 302, the status register 306, optionally also the substatus register 309, the allowed command set 307, and the overall command set 308 are comprised in a Hardware Security Module 310 of the integrated circuit 301 . The Hardware Security Module 310 also comprises a state transition log 311 , which is a memory area dedicated to the purpose that log entries are written into it chronologically. Alternatively, the state transition log may be implemented as part of a memory region dedicated to other purposes as well.

Outside of the Hardware Security Module 310, the integrated circuit 301 may also comprise a second CPU 312 for performing non-security critical tasks.

Fig. 4 shows, in symbolic form, a vehicle 401 comprising an integrated circuit 402 according to an aspect of the invention.

The invention relates to an integrated circuit for controlling components in a vehicle, to a method for operating such integrated circuit, to a computer program product, to an electronic control unit comprising the integrated circuit and to a vehicle comprising it. For providing varying levels of capabilities and security infrastructure, as different lifecycle phases may require, while at the same time preventing fraudulent use, lifecycle states are introduced in the integrated circuit, between which transitions are restricted to those forming an acyclic directed graph.

List of Reference Numerals (Part of the description)

101 First lifecycle state

102 First lifecycle state transition, first transition

103 Second lifecycle state

104 Second transition

105 Third lifecycle state

201 Development lifecycle state

202 Production lifecycle state

203 OEM production lifecycle state

204 Operation lifecycle state

205 Claims handling lifecycle state

206 End-of-life lifecycle state

207 Third lifecycle state transition

208 Fourth lifecycle state transition

209 Seventh lifecycle state transition

210 Fifth lifecycle state transition

211 Sixth lifecycle state transition

212 Eighth lifecycle state transition

213 Ninth lifecycle state transition

301 Integrated circuit

302 Central processing unit

303, 304, 305 Interfaces

303 JTAG interface

304 XCP interface

305 Diagnostic interface

306 Status register

307 Allowed command set

308 Overall command set

309 Substatus register

310 Hardware Security Module

311 State transition log

312 Second CPU 401 Vehicle

402 Electronic Control Unit

References:

[1] Joint test action group, [online]. Wikipedia, 2020 [retrieved on 2020-03-13]. Retrieved from <https://de.wikipedia.org/wiki/Joint_Test_Action_Group>.

[2] JTAG Explained (finally!). In SENRIO BLOG [online] [retrieved on 2020-03- 13]. Retrieved from <https://blog/senr.io/blog/jtag-explained>.

[3] WOLF, Marco; GENDRULLIS, Timo. Design, implementation, and evaluation of a vehicular hardware security module. In: 14th International Conference on Information Security and Cryptology, Seoul, South Korea, November/December 2011 , [retrieved on 2020-09-15]. Retrieved from <https://evita-project.org/Publications/WG11 ,pdf>.

[4] AURIX™ 32-bit microcontrollers for automotive and industrial applications I Issue 2020. Product Brochure [online]. Infineon Technologies AG, 2020 [retrieved on 2020-10-29], Retrieved from <http://infineon.com/cms/en/product/microcontroller/32-bit-tricore- microcontroller/#!documents>.

[5] HSM I Hardware Security Module I AURIX™ TC2xx Microcontroller Training V1 .1 2019-03. Training Document [online]. Infineon Technologies AG, 2019 [retrieved on 2020-09-15]. Retrieved from <http://infineon.com/cms/en/product/microcontroller/32-bit-tricore- microcontroller/#!trainings>.

[6] SURFACE VEHICLE RECOMMENDED PRACTICE. SAE International. J3061 JAN2016; 2016

[7] TCG TSS 2.0 Overview and Common Structures Specification. Trusted Computing Group, TSS Work group. 2019 [retrieved on 2020-10-29], Retrieved from <https://trustedcomputinggroup.org/wp- content/uploads/TCG_TSS_Overview_Common_Structures_v0.9_r03_publish ed.pdf>.

[8] eFuse IP Core, [online], Semipedia 2019 [retrieved on 2020-11 -03], Retrieved from <https://anysilicon.com/semipedia/efuse-ip-core/>. [9] IBM eFUSE, [online]. Wikipedia, 2020 [retrieved on 2020-11 -03]. Retrieved from <https://en.wikipedia.org/wiki/IBM_eFUSE>.

[10] US 4,962,294 (A)

[11] Antifuse, [online]. Wikipedia, 2019 [retrieved 2020-11 -03]. Retrieved from <https://en.wikipedia.org/wiki/Antifuse>.

[12] TPM Main I Part 1 Design Principles. Trusted Computing Group. 2011 [retrieved on 2020-09-22] Retrieved from <https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-1 - Design-Principles_v1 ,2_rev116_01032011 . pdf>.

[13] XCP (protocol), [online]. Wikipedia, 2020 [retrieved 2020-11 -03]. Retrieved from <https://en.wikipedia.org/wiki/XCP_(protocol)>.

[14] Requirements on Diagnostics, AUTOSAR FO R19-11 , [retrieved on 2020-11 - 03]. Retrieved from <https://www.autosar.org/fileadmin/user_upload/standards/foundation/19-

11/AUTOSAR_RS_Diagnostics.pdf>.

[15] Public Key Infrastructres (PKIs), [online]. Bundesamt fur Sicherheit in der Informationstechnik, [retrieved 2020-11 -03]. Retrieved from <https://www.bsi.bund.de/EN/Topics/ElectrlDDocuments/securPKI/securityme chanismsPKI.html>.

[16] Directed acyclic graph, [online]. Wikipedia, 2020 [retrieved on 2020-11 -09]. Retrieved from <https://en.wikipedia.org/wiki/Directed_acyclicgraph>.

Claims

1. An integrated circuit (301 ) for an Electronic Control Unit, the circuit comprising

- at least one central processing unit (302) equipped and configured to process commands selected from a configurable allowed command set (307) which is a subset of a predefined overall command set (308);

- at least one interface (303, 304, 305) for connecting the integrated circuit (301 ) to an external component;

- a status register (306) equipped and configured to indicate a lifecycle state (101 , 103, 105, 201 , 202, 203, 204, 205, 206) of the integrated circuit (301 ) being one of at least a first lifecycle state (101 ), a second lifecycle state (103), and a third lifecycle state (105);

- the integrated circuit (301 ) being equipped and configured to perform lifecycle state transitions (102, 104, 207, 208, 209, 210, 211 , 212, 213),

- the integrated circuit (301 ) being equipped and configured such that in each lifecycle state, one arbitrarily configured allowed command set (307) applies; characterized in that the lifecycle states (101 , 103, 105, 201 , 202, 203, 204, 205, 206) of the integrated circuit (301 ) as graph vertices and the lifecycle state transitions (102, 104, 207, 208, 209, 210, 211 , 212, 213) as graph edges constitute a directed acyclic graph.

2. The integrated circuit (301 ) of claim 1 , characterized in that the status register (306) is implemented as a monotonic counter, and the lifecycle state transitions (102, 104, 207, 208, 209, 210, 211 , 212, 213) are implemented by custom software running inside a hardware security module (310) of the integrated circuit (301 ).

3. The integrated circuit (301 ) of claim 1 , characterized in that the status register (306) is implemented as a write-once register, and the lifecycle state transitions (102, 104, 207, 208, 209, 210, 211 , 212, 213) are implemented by appropriately and irreversibly writing individual bits of the write-once register. 4. The integrated circuit (301 ) of any of the previous claims, characterized in that it comprises a state transition log (31 1 ) memory, and is equipped and configured that at least some of the lifecycle state transitions (102, 104, 207, 208, 209, 210, 21 1 , 212, 213) are entered into the state transition log (31 1 ).

5. The integrated circuit (301 ) of claim 4, characterized in that the state transition log (31 1 ) is a write-once memory.

6. The integrated circuit (301 ) of any of the previous claims, characterized in that it is equipped and configured that at least some of the lifecycle state transitions (102, 104, 207, 208, 209, 210, 21 1 , 212, 213) require authentication.

7. The integrated circuit (301 ) of any of claims 4 to 6, characterized in that it is equipped and configured that the lifecycle state transitions (102, 104, 207, 208, 209, 210, 21 1 , 212, 213) are entered into the state transition log with a pertaining date and time information, and with authentication information if available.

8. The integrated circuit (301 ) of any of the previous Claims, characterized in that

- it comprises a substatus register (309) equipped and configured to indicate a sub-state of the integrated circuit (301 ) for at least one of the lifecycle states (101 , 103, 105, 201 , 202, 203, 204, 205, 206);

- it is equipped and configured to perform, within the at least one lifecycle state (101 , 103, 105, 201 , 202, 203, 204, 205, 206), sub-state transitions,

- it is equipped and configured such that in the sub-states of the at least one lifecycle state (101 , 103, 105, 201 , 202, 203, 204, 205, 206), arbitrarily choosable allowed command sets apply; and in that the sub-states as graph vertices and the sub-state transitions as graph edges constitute a directed graph.

9. The integrated circuit (301 ) of Claim 2, characterized in that - the circuit comprises a JTAG interface (303), an XCP interface (304) and a diagnostic interface (305);

- the lifecycle state is one of a set comprising a development lifecycle state

(201 ), a production lifecycle state (202), an OEM production lifecycle state (203), an operation lifecycle state (204), a claims handling lifecycle state (205), and an end-of- life lifecycle state (206);

- the integrated circuit is equipped and configured such that

-- in the development lifecycle state (201 ) as well as in the production lifecycle state (202), the allowed command set (307) comprises commands to access the JTAG interface (303), the XCP interface (304) and the diagnostic interface (305);

-- in the OEM production lifecycle state (203), the allowed command set (307) comprises less commands than in the development lifecycle state (201 );

- in the operation lifecycle state (204), the allowed command set (307) may comprise security related commands and does not comprise diagnostics commands;

-- in the claims handling lifecycle state (205), the allowed command set (307) does not comprise commands for debugging the hardware security module (310);

-- in the end-of-life state (206), the allowed command set (307) does not comprise any commands to access internal information;

- the integrated circuit is equipped and configured such that state transitions are only possible

- from the development lifecycle state (201 ) to the production lifecycle state

(202),

- from the production lifecycle state (202) to the OEM production lifecycle state (203) or to the operation lifecycle state (204),

- from the OEM production lifecycle state (203) to the operation lifecycle state

(204),

- from the operation lifecycle state (204) to the claims handling lifecycle state

(205) or to the end-of-life lifecycle state (206), and

- from the claims handling lifecycle state (205) to the end-of-life lifecycle state

(206).

10. A method to operate an integrated circuit (301 ) comprising at least one central processing unit (302) equipped and configured to process commands from a configurable allowed command set (307), comprising at least one interface (303, 304, 305), and comprising a status register (306) to indicate a lifecycle state (101 , 103, 105, 201 , 202, 203, 204, 205, 206) of the integrated circuit (301 ); the method comprising consecutive steps of

- running the integrated circuit (301 ) in a first lifecycle state (101 , 103, 201 , 202, 203, 204, 205);

- transiting from the first lifecycle state (101 , 103, 201 , 202, 203, 204, 205) to a second lifecycle state (103, 105, 202, 203, 204, 205, 206);

- running the integrated circuit (301 ) in the second lifecycle state (103, 105, 202, 203, 204, 205, 206); and characterized in that

- the transiting is into a second lifecycle state (103, 105, 202, 203, 204, 205, 206) in which the integrated circuit (301 ) has not been run before.

11 . The method of Claim 10, additionally characterized in that for at least some of the transiting steps, data are entered into a state transition log (311 ).

12. The method of Claim 10, additionally characterized in that for at least some of the transiting steps, authentication is required.

13. A computer program product comprising commands which, when executed in an integrated circuit (301 ) comprising a CPU (302), cause the integrated circuit (301 ) to execute the steps of the method according to one of claims 10 to 12.

14. An Electronic Control Unit (402) for controlling a component in a vehicle, characterized in that it comprises the integrated circuit (301 ) according to one of Claims 1 to 9, or in that it is equipped and configured to perform the method according to one of claims 10 to 12.

15. A vehicle (401 ), characterized in that it comprises the integrated circuit (301 ) according to one of Claims 1 to 9, or the Electronic Control Unit (402) according to Claim 14.