Patent Description:
Hardware debug interfaces, such as the debug interface defined by the JTAG (Joint Test Action Group), are a powerful tool for debugging embedded systems due to extensive read and write rights. However, such interfaces may represent a target for attackers with physical access to read-out security assets (e.g. secret keys) or overwrite critical data (e.g. tuning values such as a maximally allowed speed). To protect those interfaces, chip manufactures have introduced debug locking mechanisms that can only be unlocked by providing the correct password. Those secret keys are typically generated when the embedded system is programmed. In a next step, the generated keys are often stored by the supplier in its own database, or the database is transmitted to the OEM (Original Equipment Manufacturer). For that reason, the suppliers of the OEM might have access to the secret keys, which may be disadvantageous for several reasons. For once, it might neither be transparent who has access to the keys, nor might it be clear how the keys are protected against internal as well as external adversaries. For example, an employee of the supplier might decide to sell the keys, or the keys may be stored in an insecure server environment that can be easily penetrated. Additionally, the password might need to be stored for the next decades. For example, if the supplier has a financial crisis, it may be required to shut down the servers that store the respective keys. Moreover, storing those keys requires dedicated memory as well as the mandatory security mechanisms for protecting this storage, which is typically implemented by some kind of backend system.

European patent application <CIT> relates to a vehicle security module system. In said system, a Diffie-Hellman key exchange is used to perform a cryptographic key exchange between a dongle and a vehicle security module. An authenticity of the dongle is verified based on the Diffie-Hellman key exchange.

US patent application <CIT> relates to end-to-end communication security in a controller area network (CAN) in a vehicle. In said application, a Diffie Hellman key exchange is used to establish the end-to-end communication security between two electronic control units of the vehicle.

There may be a desire to overcome the above-mentioned limitations.

This desire is addressed by the subject-matter of the independent claims.

Embodiments of the present disclosure are based on the finding, that it may be desirable that the password used to access the debugging functionality of the electronic control unit never actually leaves the electronic control unit, but can be recreated by the OEM. To this end, a shared secret may be generated by two entities - by the electronic control unit, and by an entity of the OEM. To this end, the known Diffie-Hellman key exchange can be modified to provide a temporally decoupled key exchange between the entities. The electronic control unit is configured to determine the shared secret that is shared between the entities using a private key of the electronic control unit and using a public key of the OEM. The OEM can do the same using the public key of the electronic control unit (which may be provided by the electronic control unit, or printed on the electronic control unit), and based on the private key of the OEM. Thus, the private key of the electronic control unit, which would allow reconstruction of the shared secret by the supplier, could be contained in the electronic control unit itself, unknown to the supplier, reducing the risk of a breach of keys to the electronic control unit. Additionally, as the shared secret is identical between the two entities, a simple comparison of the shared secrets may suffice, alleviating the need for a processor to be active to perform the comparison. Instead, this functionality can be moved into the debug port of the electronic control unit, enabling a use of the concept even if a main processor of the electronic control unit is inactive due to an internal error state. Thus, a lightweight mechanism is provided that enables an OEM to ensure that the supplier is incapable of storing the secret keys and to avoid the necessity to run a full-blown backend secret key storage, while getting control even in non-functional states of the electronic control unit.

Embodiments of the present disclosure thus provide an electronic control unit for a vehicle. The electronic control unit comprises processing circuitry configured to determine first cryptographic information based on a private key of the electronic control unit and based on a public key of a second entity. The processing circuitry is configured to obtain second cryptographic information from an external apparatus via a JTAG interface. The processing circuitry is configured to compare the first cryptographic information and the second cryptographic information. The processing circuitry is configured to unlock a control access to the electronic control unit if the second cryptographic information is based on a private key of the second entity and based on a public key of the electronic control unit, i.e., if the first cryptographic information and the second cryptographic information match. As the private key of the electronic control unit is not required by the second entity to determine the second cryptographic information, the private key of the electronic control unit might be contained within the electronic control unit, and may even be discarded after generation of the first cryptographic information. Furthermore, the private key may be generated during initialization of the electronic control unit at the OEM, further shielding the private key from access by a malicious actor.

For example, the processing circuitry may be configured to store the first cryptographic information using memory circuitry of the electronic control unit. The processing circuitry may be configured to discard the private key of the electronic control unit after determining the first cryptographic information. Consequently, the private key of the electronic control unit might not be disclosed to anyone.

For example, the processing circuitry is configured to determine the first cryptographic information during a factory setup process of the electronic control unit, e.g. during initialization of the electronic control unit at the OEM. Thus, the first cryptographic information may be generated on device, and never be exposed.

In various embodiments, the processing circuitry may be configured to generate the private key of the electronic control unit. Consequently, the private key of the electronic control unit might be contained within the electronic control unit, and not be exposed.

Furthermore, the processing circuitry may be configured to generate the public key of the electronic control unit based on the private key of the electronic control unit. The processing circuitry may be configured to provide the public key of the electronic control unit via the interface. If the public key is generated on-device, the private key may be contained within the electronic control unit. For example, the public key of the electronic control unit may be provided via the interface during a factory setup process of the electronic control unit, e.g. during initialization of the electronic control unit at the OEM.

In some embodiments, the public key of the electronic control unit is shown in machine-readable form on the electronic control unit. Thus, the public key need not be saved in a database, but can be read by a debugging device using an optical scanner.

The processing circuitry is configured to obtain the second cryptographic information from the external apparatus via the JTAG interface, and to provide debug functionality for the electronic control unit to the external apparatus (via the interface) after unlocking the control access. In other words, the second cryptographic information is used to unlock debug access to the electronic control unit.

Embodiments of the present disclosure further provide an apparatus for performing control operations on an electronic control unit of a vehicle. The apparatus comprises processing circuitry that is configured to provide cryptographic information to a JTAG interface of the electronic control unit via an interface. The cryptographic information is based on a public key of the electronic control unit and based on a private key of a second entity. The processing circuitry is configured to gain control access to the electronic control unit via the interface. The control access to the electronic control unit is unlocked by the electronic control unit based on the provided cryptographic information. This apparatus may be the counterpart to the electronic control unit, gaining control access to the electronic control unit based on the above-mentioned cryptographic key exchange scheme.

In addition, the processing circuitry is configured to determine the cryptographic information based on the public key of the electronic control unit and based on the private key of the second entity. Thus, the cryptographic information can be determined on-site after obtaining the public key of the electronic control unit. Alternatively, the processing circuitry may be supplied with the cryptographic information by a backend entity. In this case, the apparatus need not know the private key of the second entity.

In various embodiments, the processing circuitry is configured to communicate with the electronic control unit via the interface using a wired or wireless data communication connection. The processing circuitry may be configured to receive the public key of the electronic control unit via the data communication connection. Thus, the public key may be received from the electronic control unit, the cryptographic information subsequently generated and provided. Alternatively, the processing circuitry may be configured to process visual sensor data depicting at least a part of the electronic control unit to obtain the public key of the electronic control unit. Accordingly, the public key may be printed on the exterior of the electronic control unit.

The processing circuitry is configured to access a debugging functionality of the electronic control unit after gaining the control access to the electronic control unit. Thus, the apparatus may be a debugging apparatus.

Embodiments of the present disclosure further provide a method for an electronic control unit of a vehicle. The method comprises determining first cryptographic information based on a private key of the electronic control unit and based on a public key of a second entity. The method comprises obtaining second cryptographic information from an external apparatus via a JTAG interface. The method comprises comparing the first cryptographic information and the second cryptographic information. The method comprises unlocking a control access to the electronic control unit if the second cryptographic information is based on a private key of the second entity and based on a public key of the electronic control unit, i.e., if the first and second cryptographic information match. The method comprises providing debug functionality for the electronic control unit to the external apparatus after unlocking the control access.

Embodiments of the present disclosure further provide a method for performing control operations on an electronic control unit of a vehicle. The method comprises determining cryptographic information based on a public key of the electronic control unit and based on a private key of a second entity. The method comprises providing the cryptographic information to a JTAG interface of the electronic control unit via an interface. The method comprises gaining control access to the electronic control unit via the interface. The control access to the electronic control unit is unlocked by the electronic control unit based on the provided cryptographic information. The method comprises accessing a debugging functionality of the electronic control unit after gaining the control access to the electronic control unit.

Embodiments of the present disclosure further provide a computer program having a program code for performing at least one of the above methods, when the computer program is executed on a computer, a processor, or a programmable hardware component.

Accordingly, while further examples are capable of various modifications and alternative forms, some particular examples thereof are shown in the figures and will subsequently be described in detail. However, this detailed description does not limit further examples to the particular forms described. Further examples may cover all modifications, equivalents, and alternatives falling within the scope of the disclosure. Same or like numbers refer to like or similar elements throughout the description of the figures, which may be implemented identically or in modified form when compared to one another while providing for the same or a similar functionality.

It will be understood that when an element is referred to as being "connected" or "coupled" to another element, the elements may be directly connected or coupled via one or more intervening elements. If two elements A and B are combined using an "or", this is to be understood to disclose all possible combinations, i.e. only A, only B as well as A and B, if not explicitly or implicitly defined otherwise. An alternative wording for the same combinations is "at least one of A and B" or "A and/or B". The same applies, mutatis mutandis, for combinations of more than two Elements.

<FIG> shows a block diagram of an embodiment of an electronic control unit <NUM> for a vehicle <NUM>. The electronic control unit comprises processing circuitry <NUM> and an interface <NUM> (e.g. interface circuitry <NUM>), which is coupled to the processing circuitry <NUM>. In general, the processing circuitry <NUM> may be configured to provide the functionality of the electronic control unit <NUM>. In some other embodiments, the processing circuitry may (merely) provide the functionality of a debug interface of the electronic control unit, alongside a main processor of the electronic control unit. In other words, the processing circuitry <NUM> may be configured to implement a debugging interface of the electronic control unit <NUM>.

The processing circuitry is configured to determine first cryptographic information based on a private key of the electronic control unit and based on a public key of a second entity. The processing circuitry is configured to obtain second cryptographic information via the interface. The processing circuitry is configured to compare the first cryptographic information and the second cryptographic information. The processing circuitry is configured to unlock a control access to the electronic control unit if the second cryptographic information is based on a private key of the second entity and based on a public key of the electronic control unit. <FIG> further shows a vehicle <NUM> comprising the electronic control unit <NUM>.

<FIG> shows a flow chart of an embodiment of a corresponding method for the electronic control unit <NUM>. Correspondingly, the method may implement the functionality of a debug interface of the electronic control unit <NUM>. The method comprises determining <NUM> first cryptographic information based on a private key of the electronic control unit and based on a public key of a second entity. The method comprises obtaining <NUM> second cryptographic information via an interface. The method comprises comparing <NUM> the first cryptographic information and the second cryptographic information. The method comprises unlocking <NUM> a control access to the electronic control unit if the second cryptographic information is based on a private key of the second entity and based on a public key of the electronic control unit.

The following description relates both to the electronic control unit of <FIG> and to the method of <FIG>. Features described in connection with the electronic control unit of <FIG> may likewise be applied to the method of <FIG>.

Various embodiments of the present disclosure relate to an electronic control unit, or to a method or computer program for an electronic control unit. For example, the electronic control unit may be an electronic control unit of a vehicle, or an electronic control unit of another piece of electronically controlled machinery. In general, vehicles comprise a multitude of different electronic control units, e.g. electronic control units for controlling the engine, electronic control units of sensors of the vehicle, electronic control units of a security system of the vehicle etc. These electronic control unit are often manufactured by third-party suppliers of the manufacturer of the vehicle (i.e. of the Original Equipment Manufacturers, OEMs). At the same time, OEMs often wish to limit the access to said electronic control units, e.g. in order to avoid manipulations of the electronic control units by malicious actors. In some systems, as has been laid out afore, the electronic control units are secured using security codes that are implanted into the electronic control units by the suppliers, and shared with the OEMs via a database. In such cases, the database comprising the security codes may present a compelling target for malicious actors. Embodiments may avoid providing such a compelling target by using a cryptographic scheme, in which shared secrets are used that are generated using two pairs of private and public keys. As the name suggests, the public keys may be publicly accessible without compromising the security concept. Thus, merely the public keys may be exchanged between the OEM and the supplier, enabling access of the OEM to the electronic control units without comprising the security concept.

The processing circuitry is configured to determine the first cryptographic information based on a private key of the electronic control unit and based on a public key of a second entity. In the context of the present disclosure, (at least) six pieces of cryptographic information are used:.

The shared secret generated by the electronic control unit is denoted the first cryptographic information, and the shared secret generated by the apparatus of the second entity is denoted the second cryptographic information. If the first and second cryptographic information match, i.e. if the shared secrets match, the control access to the electronic control unit may be unlocked. For example, the first and second cryptographic information match, i.e. the shared secret match, if the first cryptographic information is based on the private key of the electronic control unit and based on the public key of the second entity, and if the second cryptographic information is based on the private key of the second entity and based on the public key of the electronic control unit.

In general, the most secure approach may be to generate the private key of the electronic control unit on-device, e.g. using the processing circuitry <NUM>. In other words, the processing circuitry may be configured to generate the private key of the electronic control unit. For example, the processing circuitry may be configured to use a cryptographic functionality of the processing circuitry to generate the private key of the electronic control unit, or the processing circuitry may be configured to execute a cryptographic algorithm to generate the private key of the electronic control unit. Alternatively, the processing circuitry <NUM> may be configured to obtain the private key of the electronic control unit, e.g. via the interface <NUM>, and/or from another processor of the electronic control unit.

Based on the private key of the electronic control unit, the public key may be generated. In other words, the processing circuitry may be configured to generate the public key of the electronic control unit based on the private key of the electronic control unit. For example, the processing circuitry may be configured to derive the public key of the electronic control unit from the private key of the electronic control unit. In various implementations, e.g. when adapting the Elliptic Curve Diffie Hellman key exchange in a time-decoupled manner, the private key may be an integer, and the public key may be a point on an elliptic curve that is based on a multiple of the private key's integer.

The processing circuitry may be configured to provide the public key of the electronic control unit via the interface. For example, the public key may be provided via the interface during a factory setup process of the electronic control unit, e.g. before control access to the electronic control unit is locked. For example, the factory setup process may be a factory setup process at the manufacturer of the electronic control unit, or a factory setup process at a manufacturer of the vehicle (or machine), i.e. the OEM, comprising the electronic control unit. In this case, the public key may be provided to a factory setup entity, and subsequently stored in a database, transmitted to the OEM, or printed out on a label that is pasted on the electronic control unit. For example, the public key may be shown in machine-readable form on the electronic control unit, e.g. on a label, or on an electronic display of the electronic control unit. Alternatively, the public key of the electronic control unit may be provided to the apparatus seeking to gain control access to the electronic control unit, e.g. before obtaining the second cryptographic information. Again, in another embodiment, the public key may be generated outside the device, and later provided to the processing circuitry.

To generate the first cryptographic information, the public key of the second entity is used. For example, the processing circuitry may be configured to obtain (i.e. receive) the public key of the second entity via the interface <NUM>, e.g. from an apparatus <NUM> seeking to gain control access to the electronic control unit, or from a factory setup apparatus before the control access to the electronic control unit is locked. In the former case, the public key of the second entity may be verified, e.g. to avoid public keys from entities that are not trustworthy. In various embodiments, however, the public key of the second entity may be stored within a memory circuitry of the electronic control unit. For example, the public key of the second entity may be part of a firmware of the electronic control unit.

Once the private key of the electronic control unit and the public key of the second entity are available, the processing circuitry may use both to determine the first cryptographic information. As has been pointed out before, the first cryptographic information may be a shared secret of the key exchange performed between the electronic control unit and the second entity. In other words, it may be a symmetric key, that can be generated using one of two different key combinations - using the private key of the electronic control unit and the public key of the second entity, or using the private key of the second entity and the public key of the electronic control unit. For example, the processing circuitry may be configured to determine the first cryptographic information during a factory setup process of the electronic control unit. Alternatively, the processing circuitry may be configured to determine the first cryptographic information upon receipt of the public key of the second entity, or upon generation of the private key of the electronic control unit. After generating the first cryptographic information, it may be stored within a memory of the electronic control unit. In other words, the processing circuitry may be configured to (permanently) store the first cryptographic information using memory circuitry of the electronic control unit (i.e. within the electronic control unit).

Once the first cryptographic information is generated, the private key of the electronic control unit might not be required anymore, and may be discarded. In other words, the processing circuitry may be configured to discard (i.e. delete) the private key of the electronic control unit after determining the first cryptographic information (and/or after storing the first cryptographic information).

After generating the first cryptographic information, or, alternatively, after the public key of the second entity is stored within the electronic control unit, the control access to the electronic control unit may be locked. In other words, the processing circuitry may be configured to lock the access to the electronic control unit, e.g. if one or more of the following conditions are met:.

To unlock the electronic control unit, the first cryptographic information is compared to the second cryptographic information. The processing circuitry may be configured to compare the first and second cryptographic to determine that (or whether) the second cryptographic information is generated using the private key of the second entity and the public key of the electronic control unit. In other words, if the second cryptographic information matches the first cryptographic information, the second cryptographic information may be deemed to be generated using the private key of the second entity and the public key of the electronic control unit. If this is the case, i.e. if the first cryptographic information matches the second cryptographic information, the control access may be unlocked.

In general, the control access may provide control functionality to an entity communicating with the electronic control unit (e.g. via the interface <NUM>). For example, the control access may enable (i.e. authorize) the entity communicating with the electronic control unit to read out status information and/or parameters of the electronic control unit, and/or to adapt parameters of the electronic control unit. In short, the control access may provide debug functionality (i.e. diagnostic functionality, or functionality for accessing or changing internal parameters or an internal status of the electronic control unit) to the external entity. Consequently, the processing circuitry may be configured to obtain the second cryptographic information from an external apparatus via the interface, e.g. from an apparatus <NUM> as introduced in connection with <FIG>. The processing circuitry may be configured to provide debug functionality for the electronic control unit to the external apparatus after unlocking the control access.

The interface <NUM> may correspond to one or more inputs and/or outputs for receiving and/or transmitting information, which may be in digital (bit) values according to a specified code, within a module, between modules or between modules of different entities. For example, the interface <NUM> may comprise interface circuitry configured to receive and/or transmit information. In some embodiments, the interface <NUM> may be a debug port of the electronic control unit, e.g. a JTAG port.

In embodiments the processing circuitry <NUM> may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer or a programmable hardware component being operable with accordingly adapted software. In other words, the described function of the processing circuitry <NUM> may as well be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may comprise a general purpose processor, a Digital Signal Processor (DSP), a micro-controller, etc..

More details and aspects of the electronic control unit and of the corresponding method are mentioned in connection with the proposed concept or one or more examples described above or below (e.g. <FIG>). The electronic control unit and corresponding apparatus may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

<FIG> shows a block diagram of an embodiment of an apparatus <NUM> for performing control operations on an electronic control unit <NUM>, e.g. an electronic control unit of a vehicle <NUM> or of another device. The apparatus comprises processing circuitry <NUM> and an interface <NUM> that is coupled to the processing circuitry <NUM>. In general, the processing circuitry is configured to provide the functionality of the apparatus, e.g. in conjunction with the interface <NUM>. The processing circuitry is configured to provide (second) cryptographic information to the electronic control unit via the interface <NUM>. The cryptographic information is based on a public key of the electronic control unit and based on a private key of a second entity. The processing circuitry is configured to gain control access to the electronic control unit via the interface. The control access to the electronic control unit is unlocked by the electronic control unit based on the provided cryptographic information.

<FIG> shows a flow chart of an embodiment of a corresponding method for performing control operations on an electronic control unit. The method comprises providing <NUM> cryptographic information to the electronic control unit via an interface. The cryptographic information is based on a public key of the electronic control unit and based on a private key of a second entity. The method comprises gaining <NUM> control access to the electronic control unit via the interface. The control access to the electronic control unit is unlocked by the electronic control unit based on the provided cryptographic information.

The following description relates both to the apparatus of <FIG> and to the method of <FIG>. Features described in connection with the apparatus of <FIG> may likewise be applied to the method of <FIG>.

Some embodiments of the present disclosure relate to an apparatus <NUM>, a method and a computer program for performing control operations on an electronic control unit <NUM> of a vehicle <NUM>. In other words, the apparatus <NUM> may be suitable for, or configured to, use a control access, i.e. a debugging access or a diagnostic access, to the electronic control unit. Accordingly, the processing circuitry may be configured to access a debugging functionality (i.e. a diagnostic functionality) of the electronic control unit after gaining the control access to the electronic control unit. For example, the processing circuitry may be configured to access and/or adapt one or more parameters and/or a status of the electronic control unit after gaining the control access to the electronic control unit. In terms of the language used in connection with <FIG> and/or 1b, the apparatus <NUM> may be an apparatus of the second entity, gaining control access to the electronic control unit for (i.e. representing) the second entity.

The processing circuitry is configured to provide cryptographic information to the electronic control unit via an interface <NUM>, the cryptographic information being based on a public key of the electronic control unit and based on a private key of the second entity. As has been mentioned in connection with <FIG> and/or 1b, the cryptographic information (denoted second cryptographic information in connection with <FIG> and/or 1b) may be a shared secret, e.g. a symmetric cryptographic key, that is generated by the second entity using the private key of the second entity and the public key of the electronic control unit. In some embodiments, the processing circuitry may use cryptographic information that is provided by another entity, e.g. by a server of the second entity. In other words, the processing circuitry may be configured to retrieve the cryptographic information, e.g. from the server of the second entity, or from memory circuitry of the apparatus, if the cryptographic information is stored within a memory of the apparatus. Alternatively, the cryptographic information may be generated on-device, by the apparatus <NUM>. In other words, the processing circuitry may be configured to determine (i.e. generate) the cryptographic information based on the public key of the electronic control unit and based on the private key of the second entity.

In some embodiments, the public key of the electronic control unit may be retrieved from the server of the second entity. In other words, the processing circuitry may be configured to obtain (i.e. receive) the public key of the electronic control unit from the server of the second entity. Alternatively, the public key of the electronic control unit may be obtained from the electronic control unit. For example, the public key of the electronic control unit may be printed on a label of the electronic control unit, or shown by a display of the electronic control unit. In this case, visual sensor data of a camera may be used to read the public key of the electronic control unit. In other words, the processing circuitry may be configured to process visual sensor data (of a camera, e.g. a camera that is connected to the apparatus <NUM>) depicting at least a part of the electronic control unit to obtain the public key of the electronic control unit. For example, the visual sensor data may comprise a photo of the electronic control unit, the photo depicting the public key. The processing circuitry may be configured to extract the public key of the electronic control unit from the visual sensor data. Alternatively, the processing circuitry may be configured to receive the public key from the electronic control unit via the interface. For example, the processing circuitry may be configured to communicate with the electronic control unit via the interface using a wired or wireless data communication connection, e.g. according to the JTAG standard. The processing circuitry may be configured to receive the public key of the electronic control unit via the data communication connection, e.g. in response to a request from the apparatus.

The processing circuitry is configured to gain control access to the electronic control unit via the interface. As has been laid out before, the control access to the electronic control unit may provide the apparatus with access to the debugging / diagnostic functionality of the electronic control unit. Access to the debugging / diagnostic functionality may be locked before the cryptographic information is provided, and may be locked again after the apparatus is disconnected from the electronic control unit. In other words, the control access to the electronic control unit is unlocked (i.e. made available) by the electronic control unit based on the provided cryptographic information, and may not be available to apparatuses incapable of providing the correct cryptographic information.

The interface <NUM> may correspond to one or more inputs and/or outputs for receiving and/or transmitting information, which may be in digital (bit) values according to a specified code, within a module, between modules or between modules of different entities. For example, the interface <NUM> may comprise interface circuitry configured to receive and/or transmit information.

<FIG> shows a diagram of an information exchange performed between an electronic control unit and a debugging apparatus. <FIG> shows the interaction between the electronic control unit of <FIG> and of the apparatus of <FIG>. In <FIG>, optional features are denoted with dashed lines. Embodiments of the present disclosure provide a system comprising the electronic control unit (of <FIG>) and the apparatus (of <FIG>).

In preparation of the comparison of the cryptographic information, both sides may optionally generate the cryptographic information, and/or the private and/or public keys that the cryptographic information is based on. For example, the electronic control unit may generate <NUM> the private key of the electronic control unit, and/or the electronic control unit may generate <NUM> the public key of the electronic control unit. Additionally, the public key of the electronic control unit may be provided <NUM> (by the electronic control unit) and received <NUM> (by the apparatus). Alternatively, the apparatus may process <NUM> visual sensor data to obtain the public key of the electronic control unit. Both sides determine (i.e. generate) <NUM>/<NUM> the respective cryptographic information (optional for the apparatus). Furthermore, the electronic control unit may store <NUM> the first cryptographic information, and optionally discard its private key thereafter. The apparatus provides <NUM> the (second) cryptographic information to the electronic control unit, which is obtained <NUM> (i.e. received) by the electronic control unit. The electronic control unit compares <NUM> the first and second cryptographic information, and unlocks <NUM> control access if they match, so that the apparatus gains <NUM> control access. Once the control access is unlocked, the electronic control unit may provide debug functionality <NUM>, which may be accessed <NUM> by the apparatus.

More details and aspects of the system are mentioned in connection with the proposed concept or one or more examples described above or below (e.g. <FIG>). The system may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

Embodiments of the present disclosure provide an improved concept for securing the ownership and confidentiality of third-party generated secrets while avoiding their storage.

Embodiments may provide a concept for preventing the supplier from having any knowledge of the secret debug passwords and avoiding storing an entire database with secret keys. At least some embodiments are based on the Diffie-Hellman key exchange that is typically used for securely deriving a shared secret via an unprotected communication channel. In a Diffie-Hellman key exchange, both entities possess an asymmetric key pair with a public and a private key. Then both entities exchange their public key and combine it with their own private key, resulting in a shared secret. In the context of this disclosure, the first cryptographic information generated by the electronic control unit and the (second) cryptographic information provided/generated by the debugging apparatus correspond to the shared secret.

In embodiments, the OEM (i.e. the second entity) may generate a single asymmetric key pair (i.e. the private key and the public key of the second entity). Subsequently, e.g. when the supplier manufactures the embedded system, an individual asymmetric key pair may be generated on-chip (i.e. the private key and the public key of the electronic control unit). The controller may use the OEM public key and combine it with its (secret) private key to a device individual secret (i.e. the first cryptographic information). This secret may serve as the debug password. Optionally, the private key of the devices' asymmetric key pair may be deleted. If an entity (e.g. the debugging apparatus) requires debug access, the devices' public key may be made available, e.g. by means of the controller (for example the public key could be printed on the controller's package) or using a database. Contrary to a purely password based solution the database might only contains public keys, and may therefore be uncritical from a security point of view. In the final step, the OEM may generate the shared secret (i.e. the (second) cryptographic information) by combining the device's public key with its private key and send this key to the controller. If the two secrets match, the debug port may be unlocked. This approach can be therefore seen a time-shifted Diffie-Hellman key exchange. It may be ssen as being time-shifted since the one part of the key exchange is performed when the debug port of the electronic control unit is locked and the other part is (only) conducted when requiring access to the device.

In an exemplary implementation of the concept, elliptic curve cryptography (ECC), and more specifically the elliptic curve Diffie-Hellman (ECDH) key exchange, has been used. Using ECDH, the process may be performed using one or more of the following actions:.

This may enable that the supplier does not possess the debug password, and avoid the necessity to store and manage an entire database with secret keys. The concept may be used for electronic control unit in automotive and embedded systems environments.

In some other systems, a more direct approach may be taken, in which it may at least be avoided that the supplier is capable of illegally storing the generated password when processing them. This problem can be tackled by generating the password on the device, locking the debug port and storing the password in some application on the controller. The application unlocks the debug port by providing the password, e.g. only if it receives a valid certificate. The corresponding key pair may be generated by the OEM where the public key is stored into the component and the private key is controlled by the OEM. A valid certificate might be issued only if an authorized person requests it. While this approach overcomes some of the initial issues, it assumes that the processor is operating in a functional state. Often it is the case that a controller is debugged when faulty behavior was observed. As such it is common that the processor is incapable to boot and hence incapable of verifying the incoming certificate. Furthermore, the hardware debug functionality is protected through passwords (i.e. symmetric keys) that are processed by the supplier when storing them in a database. Thus, the key exchange provided by embodiments of the present disclosure may provide a more comprehensive approach, which may also be applied if the main processor of the electronic control unit is stuck.

More details and aspects of the concept are mentioned in connection with the proposed concept or one or more examples described above or below (e.g. <FIG>). The concept may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

Functions of various elements shown in the figures, including any functional blocks labeled as "means", "means for providing a signal", "means for generating a signal. ", etc., may be implemented in the form of dedicated hardware, such as "a signal provider", "a signal processing unit", "a processor", "a controller", etc. as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which or all of which may be shared. However, the term "processor" or "controller" is by far not limited to hardware exclusively capable of executing software, but may include digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and nonvolatile storage.

It is to be understood that the disclosure of multiple acts, processes, operations, steps or functions disclosed in the specification or claims may not be construed as to be within the specific order, unless explicitly or implicitly stated otherwise, for instance for technical reasons. Therefore, the disclosure of multiple acts or functions will not limit these to a particular order unless such acts or functions are not interchangeable for technical reasons. Furthermore, in some examples a single act, function, process, operation or step may include or may be broken into multiple sub-acts, -functions, -processes, -operations or -steps, respectively. Such sub acts may be included and part of the disclosure of this single act unless explicitly excluded.

Claim 1:
An electronic control unit (<NUM>) for a vehicle (<NUM>), the electronic control unit comprising processing circuitry (<NUM>) configured to:
determine first cryptographic information based on a private key of the electronic control unit and based on a public key of a second entity;
obtain second cryptographic information from an external apparatus via an interface (<NUM>), the interface (<NUM>) being a Joint Test Action Group, JTAG, interface;
compare the first cryptographic information and the second cryptographic information; and
unlock a control access to the electronic control unit if the first cryptographic information and the second cryptographic information match; and
provide debug functionality for the electronic control unit to the external apparatus after unlocking the control access.