DE102024116338A1 - Procedure for integrity testing of a control unit - Google Patents

Abstract

Method and system (40) for integrity testing of a control unit (10) comprising a memory (11) for program instructions and data, a processor (12) for executing the program instructions and for processing the data and a hardware security module (15), comprising the steps:
- Requesting the integrity check at the control unit by a request unit (20),
- Executing the integrity check by the hardware security module with the processor acting as a communication intermediary, wherein the hardware security module forms a check result (R) based on a memory content of an area of the memory, generates an associated cryptographic hash value (H) based on at least the check result and returns the check result and the hash value to the processor,
- Transmitting the test result and the hash value to the requesting unit as an uncertain test result (R*) and an uncertain hash value (H*),
- Validation of the transmitted insecure test result by the requesting unit by generating the associated cryptographic hash value based on the transmitted insecure test result and comparing it with the transmitted insecure hash value, whereby a validation result (V) is positive and the integrity of the control unit is determined if the two compared hash values match, and is negative otherwise, and
- Providing the validation result.

Description

The invention relates to a method for integrity testing of a control unit, in particular a control unit for a vehicle, and to a system for integrity testing of a control unit, in particular a control unit for a vehicle.

For various reasons, it is necessary for today's control units used in vehicles to ensure and demonstrate the integrity and authenticity of the stored or executed software (consisting of executable program instructions and data, hereinafter collectively referred to as application data) to authorized parties.

This assurance can be achieved, for example, by using a specially secured hardware unit, separate from the processor (microprocessor, microcontroller, etc.) of the control unit, to verify the authenticity and, if necessary, the integrity of the stored application data that is later to be executed or processed by the processor. Only if these properties are met is a boot process and subsequent execution permitted. This approach is known as the "secure boot" concept. However, for various reasons, it may be necessary to supplement or even replace this concept with another approach in which the result of the authenticity/integrity check is only disclosed to a requesting instance. This variant is called "authenticated boot."

A common difficulty is that a consistently secure connection cannot be established between the testing entity (e.g., a Hardware-Secure Execution Environment, HSEE, implemented, for example, as a Hardware Security Module, HSM) and the instance requesting the test. Therefore, without further measures, the integrity of the transmitted information cannot be guaranteed. While the HSEE can detect manipulated application data from the control unit, if the control unit's processor is also used to communicate the test result, manipulated program instructions can indeed manipulate the result as well, thus deceiving the party requesting the test.

Furthermore, without additional measures, it is not guaranteed that the determined test result can be unambiguously assigned to the tested object (e.g., control unit) even after being transmitted to other systems, and that the test time can be verified without falsification. This presents several independent risks regarding the reliability of the information for the requesting party.

One method for the tamper-proof transmission of tax data is, for example, from DE 10 2010 033 229 A1 The procedure is known. It serves to detect manipulation during the transmission of control data from a first control unit to a second control unit of a vehicle and comprises the following steps: generation of integrity check information data for the control data by an integrity check generation unit on the sender side; calculation of a cryptographic checksum for the integrity check information data generated on the sender side using a cryptographic key; transmission of the integrity check information data and the cryptographic checksum to an integrity check verification unit, which verifies the cryptographic checksum using the cryptographic key; generation of integrity check information data for the received control data on the receiver side; and comparison of the integrity check information data generated on the receiver side and the verified integrity check information data generated on the sender side to detect data manipulation. The implementation of this functionality requires the integrity of the participating control units, which is necessary both for the generation of the cryptographic security elements and for their verification.

DE 10 2012 206 272 A1 This describes a fieldbus data transmission system used for the secure transmission of information between fieldbus communication participants. Each participant has a security layer comprising a fault tolerance layer and an information security layer, which in turn incorporate a checksum method and a symmetric cryptographic method as security measures. The integrity of the fieldbus participants is essential, as they are responsible for either generating the security features (sender) or verifying them (receiver).

Against this background, the invention aims to provide a method and a system for integrity testing of a control unit, in particular a control unit for a vehicle, which ensure the correctness of the integrity test result. The test result should be tamper-proof with regard to its content, without this being detectable. Furthermore, the assignment of a specific test result to the test object (i.e., the control unit under test) and the time of its determination should be unalterable.

This problem is solved by a method having the features of claim 1 and by a The system is solved according to the features of claim 11. Further particularly advantageous embodiments of the invention are disclosed in the respective dependent claims.

It should be noted that the features listed individually in the claims can be combined with one another in any technically meaningful way (even across category boundaries, for example between method and apparatus) and demonstrate further embodiments of the invention. The description further characterizes and specifies the invention, particularly in conjunction with the figures.

It should also be noted that the conjunction “and/or” used herein, which stands between two features and links them together, is always to be interpreted in such a way that in a first embodiment of the object according to the invention only the first feature may be present, in a second embodiment only the second feature may be present, and in a third embodiment both the first and the second feature may be present.

• - Anfordern der Integritätsprüfung beim Steuergerät durch eine Anforderungseinheit,
• - Ausführen der Integritätsprüfung durch das Hardwaresicherheitsmodul unter kommunikationsvermittelnder Zwischenschaltung des Prozessors des Steuergeräts, wobei das Hardwaresicherheitsmodul ein Prüfungsresultat basierend auf einem Speicherinhalt wenigstens eines vorbestimmbaren Bereichs des Speichers des Steuergeräts bildet, basierend auf wenigstens dem Prüfungsresultat einen zugeordneten kryptografischen Hashwert erzeugt und das Prüfungsresultat sowie den Hashwert an den Prozessor zurückgibt,
• - Übermitteln des Prüfungsresultats und des Hashwerts an die Anforderungseinheit als unsicheres Prüfungsresultat und unsicheren Hashwert,
• - Validieren des übermittelten unsicheren Prüfungsresultats durch die Anforderungseinheit, indem diese basierend auf dem übermittelten unsicheren Prüfungsresultat den zugeordneten kryptografischen Hashwert (selbst) erzeugt und diesen mit dem übermittelten unsicheren Hashwert vergleicht, wobei ein Validierungsergebnis positiv ausfällt und die Integrität des Steuergeräts bestimmt wird, wenn die beiden verglichenen Hashwerte übereinstimmen, und andernfalls negativ ausfällt, woraufhin das Steuergerät als kompromittiert bestimmt wird, und
• - Bereitstellen des Validierungsergebnisses.

The invention relates to a method for integrity testing of an electronic control unit (ECU), in particular an ECU for a vehicle, which comprises a memory (e.g., RAM, E(E)PROM, Flash, ROM, or similar) for program instructions and data (hereinafter collectively referred to as application data), a processor (e.g., microprocessor, microcontroller, or similar) for executing the program instructions and processing the data, and a hardware security module (e.g., Hardware Security Module, HSM, Hardware-Secured Execution Environment, HSEE). The method comprises the following steps:

• - Requesting an integrity check at the control unit by a requesting unit,
• - Execution of the integrity check by the hardware security module via the communication-mediating intermediary of the control unit's processor, wherein the hardware security module forms a test result based on a memory content of at least one predeterminable area of the control unit's memory, generates an associated cryptographic hash value based on at least the test result, and returns the test result and the hash value to the processor.
• - Transmitting the test result and the hash value to the requesting unit as an uncertain test result and uncertain hash value,
• - Validation of the transmitted insecure test result by the requesting unit by generating the associated cryptographic hash value (itself) based on the transmitted insecure test result and comparing it with the transmitted insecure hash value, whereby a validation result is positive and the integrity of the control unit is determined if the two compared hash values match, and negative otherwise, whereupon the control unit is determined to be compromised, and
• - Providing the validation result.

The request unit can be a unit external to the control unit, e.g. a test device, a functionally standardized, generic so-called scan tool, a manufacturer-specific test tool or another control unit and the like, as well as an indirectly connected functionality in a backend.

The hardware security module (HSM) is an internal or external physical security device for the efficient and secure execution of cryptographic operations or applications for sensitive data (in this case, the application data of the control unit). The necessary access to the control unit's memory by the HSM is technically performed without the intervention of the processor.

A cryptographic hash function is a hash function (scatter function) that fulfills certain properties that make it suitable for cryptographic applications. A hash function efficiently generates a fixed-length output value—the hash value—from an input value, such as a message, a file, or the contents of a memory area. For cryptographic use, further properties are required: A cryptographic hash function is a one-way function, offers collision resistance, and generates a pseudorandom hash value.

Content is considered "unsafe" (e.g., an unsafe hash value, an unsafe test result) if it may be falsified and therefore not trustworthy.

Within the scope of the invention, the integrity of the control unit under test is not required, with the exception of the inherently trusted, isolated hardware security module within the control unit under test. The hardware security module thus constitutes or includes the only so-called "trust anchor".

In the case of the control unit being tested, its integrity is the subject of the test, the result of which, despite the cause of the integrity loss, The compromise is made available in an unalterable form to an (external) system (i.e., request unit) connected only for this testing process.

In the case of additional control units optionally involved in forwarding the test result, their integrity is irrelevant, as one of two possible scenarios occurs: A falsification by a non-integral control unit is recognized as such, as is the case for every link in the transmission chain. Integral control units, on the other hand, forward the test result unchanged. Consequently, all control units—including the one whose integrity test result is to be communicated—are part of the communication/transmission channel, which is assumed to be insecure.

Any untrusted link in the transmission chain, and therefore any control unit involved in the information forwarding, can cause situations in which the generated integrity information cannot be evaluated, but it cannot be falsified without detection.

The invention relates to the detection and notification of modifications/manipulations of one or more electronic control units (ECUs). The subject of the invention is not data exchanged between ECUs during operation concerning a primary function, but rather the integrity of the ECU itself as determined or evaluated by a trusted authority (i.e., the hardware security module). Even if the associated information (i.e., the test result) is exchanged between other ECUs for the purpose of forwarding, it and its integrity are irrelevant to these other ECUs within the scope of their primary function (e.g., controlling a vehicle function), as they do not evaluate this information because it is not required for their primary function.

The invention is based on the idea of interpreting the transmission of the test result from the specially secured hardware security module via the control unit's processor as a form of transport over an insecure channel and providing a suitable safeguard for this transmission. This ensures the correctness of the transmitted information. In addition, the assignment of a specific test to the test object (i.e., the control unit under test) and its time can be made tamper-proof.

In any case, manipulation is detectable. For the case, detectable by the query unit, that no test result is obtained despite the request (for example, due to the blocking of communication), the interpretation is intended as a "worst case," which generally corresponds to the statement "manipulation detected." Accordingly, any manipulation of the communication content or the suppression of forwarding detected by the cryptographic verification method is directly considered the desired outcome.

The key advantage lies in providing the requesting actor (i.e., the requesting unit) with reliable information regarding the integrity/authenticity of the application data contained in a specific device instance (i.e., control unit) at a precisely known point in time. This information cannot be manipulated without detection. It cannot be attributed to any other device instance or any other point in time.

There is also no possibility of undetectable manipulation by recording or copying the information of an intact control unit for the purpose of feigning the intact state after manipulation of the same or another device by means of replay upon subsequent request.

To prevent the transmitted hash values from being manipulated or replaced with correct values, in an advantageous embodiment a (new) random value is generated with each request for the integrity check, transmitted by the requesting unit to the control unit (i.e., to the processor), and provided to the hardware security module (by the processor) as an insecure random value, wherein the execution of the integrity check by the hardware security module additionally includes determining the hash value based on the insecure random value, and the validation of the transmitted insecure check result by the requesting unit additionally includes determining the hash value based on the generated random value.

Since the control unit's processor may be compromised, it is not guaranteed that the random value in the hardware security module is unmodified. However, this situation is detected later. The random value is linked to the information (i.e., the test result) to be transmitted from the hardware security module to the request unit before the additionally transmitted cryptographic hash value, which ensures the integrity of the information, is generated. After the information has been transmitted to the request unit, the linking with the random value can be reversed by the request unit. The subsequent verification of the cryptographic hash value then... The hash value then provides information on whether the transmitted information is authentic and integer and matches the query.

For this purpose, the random value known to the requesting unit (generated by it) is combined with the transmitted result of the check, and the combination is subjected to the same hash value calculation as in the hardware security module. Comparing the hash values thus allows both the validity check of the transmitted information and its secure assignment to the query. A replay of a previous query from the same control unit is impossible due to the inclusion of the random information, as is a response from a different control unit.

In a further preferred embodiment, the execution of the integrity check by the hardware security module before returning the hash value to the processor includes encrypting the hash value, and the validation of the transmitted insecure check result by the requesting unit before comparing the two hash values includes decrypting the transmitted insecure hash value. Encrypting the hash value is equivalent to a signature, which makes the authorship and integrity of the hash value unambiguously verifiable. This provides an additional cryptographic safeguard for the transmission, preventing the hash values transmitted to the requesting unit from being manipulated or replaced with correct values.

Further advantageous embodiments provide that the encryption of the hash value and the decryption of the transmitted insecure hash value are carried out using an asymmetric cryptographic encryption method, wherein the hash value is encrypted by the hardware security module with a control unit-related private key stored (only) in this module, and the transmitted insecure hash value is decrypted by the requesting unit with a control unit-related public key that can be provided to it.

Preferably, during the manufacturing process of the control unit, a key pair for a public/private key pair-based asymmetric encryption method is generated in a trusted environment. The private key is stored exclusively in the control unit's hardware security module and cannot be extracted from there. The trusted environment can be a manufacturer's infrastructure, which, once and optionally with cryptographic security via a start key, transfers the private key to the hardware security module and subsequently destroys any copies it makes. The individual public key can be stored using an identifier that uniquely identifies the control unit, for example, so that it can be transmitted to the requesting unit later upon request.

As an alternative to embedding the key material in the ECU's hardware security module, it is also particularly advantageous to generate the key pair within the hardware security module itself, store the private key exclusively there (it never leaves the hardware security module), and transmit the public key to the trusted manufacturing infrastructure. The latter then proceeds as described above. Subsequent replacement of the key pair with another subsequently generated (e.g., externally or otherwise) key pair is impossible.

An additional measure to increase security is to also authenticate the generated key pair and the identification feature using "public/private key" procedures by the trusted manufacturing infrastructure.

Accordingly, in further advantageous embodiments, the request for the integrity check by the requesting unit comprises requesting and providing the ECU-related public key by means of an individual identification feature (e.g., serial number) assigned to the ECU from a data collection (e.g., table, database, etc.) of several ECU-related public keys. The data collection can be provided by another entity external to the requesting unit, for example, by a service provided by a backend.

In another embodiment, the hardware security module defines the test result as a hash value or checksum generated from the memory contents of at least one predetermined area of the memory. That is, the generated hash value and/or checksum directly constitute the test result.

In an alternative embodiment, the hardware security module outputs as the test result a binary result of a comparison of a hash value or checksum formed from the memory content of at least one predeterminable area of the memory with corresponding values stored in a tamper-proof memory of the hardware security module. Stored hash or checksum comparison values are defined, whereby the result of the comparison is positive and indicates the integrity of the control unit if the compared values match, and negative otherwise, indicating a compromise of the control unit. The integrity check can thus be performed and evaluated autonomously (so-called "on-board attestation"), e.g., during a control unit startup process or cyclically. Due to very high safety requirements, an exemplary application of this approach is the qualification of highly automated driving functions, by automatically subjecting them to a test before each use.

The reference value(s) can be stored together with the authentic software during the software installation process in the control unit, provided that the creation and installation process takes place in a trusted environment and is cryptographically secured. In-situ generation during software installation is also possible.

In the event that this cannot be guaranteed, or if the introduction of inauthentic software along with its cryptographic hash values has nevertheless succeeded (by circumventing security mechanisms), it is advantageous to extract not only the binary comparison result, but also the determined cryptographic hash value itself (off-board attestation). The evaluation is then performed by the requesting entity by comparing the transmitted (insecure) hash value with the hash values of authentic software known to the requesting entity.

Another advantageous embodiment provides that the result of the comparison is stored by the hardware security module in its tamper-proof memory. This allows the test result to be documented securely in the hardware security module for verification purposes, particularly in the case of self-initiated integrity checks by the control unit or the hardware security module.

In preferred other embodiments, the validation result is provided by the requesting unit with authentic time information from a timer assigned to the requesting unit. In this way, the test time can be verified without falsification.

Furthermore, according to an advantageous embodiment, the memory area of the control unit is predetermined by the requesting unit and transmitted accordingly when requesting the integrity check from the control unit. Based on the memory content of the predetermined memory area, the hardware security module generates the test result. The specific memory section or area to be tested is thus unknown to the control unit in advance. Moreover, the selection of the specific memory area can be random for each test. There is no possibility of undetected manipulation by recording or copying the transmitted test result of an intact control unit for the purpose of feigning an intact state after manipulation of the same or a different device by means of subsequent replay upon a request.

Furthermore, the invention relates to a system for integrity testing of a control unit, in particular a control unit for a vehicle, which comprises the control unit having a memory for program instructions and data (i.e., application data), a processor for executing the program instructions and for processing the data, and a hardware security module, and a request unit for requesting the integrity test from the control unit, wherein the request unit and the control unit are configured to establish a communication link between the request unit and the hardware security module of the control unit via the communication-mediating intermediary of the control unit's processor, and to execute a method according to one of the embodiments disclosed herein.

It is understood that, with regard to system-related definitions of terms as well as the effects and advantages of system-related features, full reference can be made to the disclosure of analogous definitions, effects, and advantages of the method according to the invention, and vice versa. A repetition of explanations of analogous features, their effects, and advantages can therefore be omitted in favor of a more concise description, without such omissions being to be interpreted as a limitation of any of the disclosed subject matter of the invention.

• 1A eine erste Hälfte eines Ablaufdiagramms eines Verfahrens nach einer Ausführungsform der Erfindung sowie ein System nach einer Ausführungsform der Erfindung; und
• 1B die zweite Hälfte des Ablaufdiagramms des Verfahrens aus 1A.

Further features and advantages of the invention will become apparent from the following description of a non-limiting embodiment of the invention, which is explained in more detail below with reference to the drawing. This drawing schematically shows:

• 1A a first half of a flowchart of a procedure after an execution a form of the invention and a system according to an embodiment of the invention; and
• 1B the second half of the flowchart of the procedure 1A .

In the different figures, parts that are equivalent in function are always provided with the same reference symbols, so that they are usually only described once.

1A Figure 1 represents the first half of a flowchart of an exemplary method for integrity testing of a control unit 10 according to an embodiment of the invention, as well as a system 40 for integrity testing of the control unit 10. The second half of the flowchart of the method according to the invention represents 1B The following also refers to the 1A and 1B taken.

System 40 comprises control unit 10, e.g., a control unit of a vehicle not shown in detail, which in turn comprises a memory 11 for program instructions and data (e.g., parameter values), a processor 12 for executing the program instructions and processing the data, and a hardware security module 15. Furthermore, system 40 comprises a request unit 20 for requesting the integrity check from control unit 10, which in this example is configured as an external test device. The request unit 20 and the control unit 10 are configured to establish a communication link between the request unit 20 and the hardware security module 15 of the control unit 10 via the communication-mediating intermediary of the processor 12 of the control unit 10 and to execute a method according to one of the embodiments disclosed herein.

In particular, in step 100, the request unit 20 requests an integrity check from the control unit 10, which is performed by the hardware security module 15 with the communication-mediating intermediary of the processor 12 (see steps 102, 140). Based on the contents of a predefined area of memory 11, which can be specified by the request unit 20, but is not necessarily limited to this, the hardware security module 15 generates a test result R in step 110. Based on at least the test result R, the hardware security module 15 generates an associated cryptographic hash value H in step 120. In step 130, the hardware security module 15 returns the test result R and the hash value H to the processor 12. For this purpose, the two values can be linked/combined in step 129.

These are then transmitted to request unit 20 in step 140 as an insecure test result R* and an insecure hash value H*. The linked transmitted values R* and H* can be decomposed again by request unit 20 in step 141. Subsequently, request unit 20 validates the transmitted insecure test result R* by generating the associated cryptographic hash value H itself in step 150 based on the transmitted insecure test result R* and comparing it with the transmitted insecure hash value H* in step 160. The integrity of the control unit 10 is determined if a validation result V is positive, i.e., if the two hash values H and H* compared in step 160 match. Otherwise, that is, if the validation result V is negative, the control unit 10 is determined to be compromised. The validation result V is then made available by request unit 20, for example, for further processing.

The validation result V can optionally be provided in step 160 by the request unit 20 with authentic time information T from a timer 22.

Control unit 10 is assigned an individual identification feature (ID, e.g., serial number). Control unit 10 has an external interface (see steps 102, 140) through which bidirectional communication with request unit 20 is possible.

The processor 12 offers bidirectional communication with the request unit 20 and provides the request unit 20 with the execution of various services, in particular the output of the test results R of the internal authentication/integrity checks and the output of cryptographically secure hash values H over memory areas specified by the request unit 20. Furthermore, the processor 12 can communicate with the hardware security module 15 and, in particular, utilize services offered by it, e.g., for encryption or cryptographically secure hashing of data blocks.

Without necessarily being limited to this, the following will be discussed in the 1A and 1B In the illustrated embodiment, with each request for the integrity check, a random value Z is also generated in step 101 and transmitted by the request unit 20 to the control unit 10 and provided to the hardware security module 15 by the processor 12 in step 102 as an unsafe random value Z*. Therefore, in this case, the execution of the integrity check by the hardware security module 15 includes determining the hash value H in step Step 120 additionally includes determining the hash value H based on the uncertain random value Z*. This is combined with the test result R in a preceding step 119. On the request unit 20 side, validating the transmitted uncertain test result R* includes determining the hash value H in step 150, additionally based on the generated random value Z, which was previously generated by the request unit 20. This is combined with the uncertain test result R* in a preceding step 149.

Without necessarily limiting this to the above, the following includes the one in the 1A and 1B In the illustrated embodiment, the integrity check is performed by the hardware security module 15 before the hash value H is returned to the processor 12. In step 121, the hash value H is encrypted. Encrypting the hash value H corresponds to a signature that makes the authorship and integrity of the hash value H verifiable beyond doubt. The encryption of the hash value H and the decryption of the transmitted insecure hash value H* are performed using an asymmetric cryptographic encryption method, whereby the hash value H is encrypted by the hardware security module 15 with a control unit-specific private key K _{_priv,ID} stored exclusively in this module. Furthermore, the validation of the transmitted insecure test result R* by the request unit 20 before comparing the two hash values H, H* in step 160 includes decrypting the transmitted insecure hash value H* in step 148. In the embodiment shown here, this is decrypted with a control unit-related public key K _pub,ID , which can be provided to the request unit 20.

For this purpose, in step 103, the request unit 20 requests the public key K _pub,ID assigned to the control unit 10 to be tested, using the individual identification feature ID assigned to the control unit 10, from a data collection K _pub,ID0.n containing several control unit-related public keys. In this case, the data collection K _pub,ID0.n is provided by a backend 30, but is not necessarily limited to this. The data collection K _pub,ID0.n could alternatively be stored in the request unit 20. In this case, in step 104, the backend 30 determines the public key K _pub,ID from the data collection K _pub,ID0.n using the ID and transmits it to the request unit 20 in step 105.

At the in 1A In the illustrated embodiment of the method, the hardware security module 15 determines in step 110 the test result R as a hash value or checksum formed from the memory content of at least one predeterminable area of the memory 11.

Optionally, a comparison of the hash value or checksum formed from the memory content with hash or checksum comparison values Σx stored in a tamper-proof memory 16 of the hardware security module 15 is possible, whereby a result of the comparison is positive and indicates the integrity of the control unit 10 if the compared values match, and is otherwise negative and indicates a compromise of the control unit 10.

The result of the comparison can optionally be stored by the hardware security module 15 in the tamper-proof memory 16 or in another tamper-proof memory M _R , as shown in 1A is indicated by a dashed arrow to memory 16 or to memory M _R, which is also shown with a dashed line.

The requirement unit 20 of the in the 1A and 1B In the illustrated embodiment, the request unit 20 can communicate with the processor 12 of the control unit 10 under test. Furthermore, it possesses the device-specific public part K _pub,ID of the key pair for asymmetric encryption or signature, or can obtain this part based on the identification feature ID (e.g., serial number) of the control unit 10 under test. In addition, the request unit 20 in the case shown here has a cryptographically strong random number generator and cryptographic functionality for using asymmetric encryption and is capable of generating cryptographically secure hash values of communication content. Finally, it (optionally) has authentic time information T with which communication results can be stamped.

The hardware security module 15 includes the capability for asymmetric encryption and decryption of communication and contains the private part K _{_priv,ID} of the individual key pair for asymmetric encryption or signature. It also stores a copy of the identification feature ID of the control unit 10. Furthermore, the hardware security module 15 is capable of read access to the application data stored in the control unit 10 under test without the mediation of the processor 12, offers a service for cryptographically secure hash value generation of data blocks and communication content, and, with the exception of the private key material, provides access to the services located in the processor 12 via a A secure hardware interface and an associated software API provide the underlying functions and information and are uniquely and permanently assigned to the control unit 10 to be tested and its memory 11.

During the manufacturing process of the control unit 10, the software-based individualization of the control unit 10 is carried out. At least one individualization feature ID is generated, which uniquely identifies a device unit and makes it possible to recognize the belonging of extracted information to a single device unit and, if applicable, to the environment in which it is installed (e.g., a vehicle).

In the case of device customization, this can be an unchangeable serial number. In any case, care must be taken to ensure that the information is securely generated, transmitted if necessary, and stored in the hardware security module 15.

The individualization feature ID can be introduced at several stages of the manufacturing process (device manufacturing at the supplier, integration into the overall product at the OEM, etc.), possibly even multiple times.

Alternatively, an individualization feature (serial number) already present in the hardware security module 15 from the time of semiconductor production can be used. This can be used, for example, after being converted into a table that is permanently available at the manufacturer of the control unit 10 to be tested. The table converts the existing feature (semiconductor serial number) into an individualization feature ID that is better suited for the OEM's purposes (for example, a device serial number).

The hardware security module 15 is capable of reading from the memory 11 (e.g., flash) of the processor 12 without its mediation. It can thus generate checksums and cryptographically secure hash values over any section (address range) of the memory 11, in particular over externally specified areas (e.g., by the request unit 20) or over the entire memory space. This can occur during runtime in parallel with the execution of program instructions by the processor 12, during a startup process (boot procedure), or in a special operating mode of the control unit 10.

Since the processor 12 of the control unit 10 is fundamentally considered part of an insecure transmission path (it could be compromised by manipulation of the program instructions it executes), it must be ensured that it does not falsify the transmitted information (i.e., the test results) without this being detectable. This is achieved by appending a cryptographically secure hash value H to each piece of information transmitted by the hardware security module 15. This hash value is encrypted or signed with the private part K _priv,ID of the key pair, which exists only in the hardware security module 15. By decrypting with the public part K _pub,ID (which is available to the request unit 20 after assignment via the individualization feature ID of the control unit 10 being tested) and comparing it with the hash value H generated locally in the request unit 20, the integrity and authorship can be verified beyond doubt. A discrepancy is interpreted as the "worst-case" result "manipulation detected".

REFERENCE MARK LIST:

10

control unit

11

Memory for program instructions and data

12

processor

15

Hardware security module

16

Tamper-proof storage

20

Requirement unit

21

Provision of identification feature

22

Timer

30

Backend

40

system

H

Cryptographic hash value

ID

Individual identification feature

K

Encrypted value

Kpriv,ID

ECU-specific private key

Kpub,ID

ECU-related public key

Kpub,ID0.n

Data collection of control unit-related public keys

MR

Tamper-proof storage

R

Exam result

Σx

Hash or checksum comparison value

T

Time information

V

Validation result

Z

Random value

[A-Z]

Trustworthy, unadulterated content

[A-Z]*

Unsafe, potentially falsified content

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions.

Cited patent literature

• DE 10 2010 033 229 A1 [0006]
• DE 10 2012 206 272 A1 [0007]

Claims (11)

A method for integrity testing of an electronic control unit (10), in particular an electronic control unit for a vehicle, comprising a memory (11) for program instructions and data, a processor (12) for executing the program instructions and processing the data, and a hardware security module (15), wherein the method comprises the steps of: - requesting the integrity test from the electronic control unit (10) by a request unit (20), - performing the integrity test by the hardware security module (15) via the communication-mediating intermediary of the processor (12), wherein the hardware security module (15) generates a test result (R) based on a memory content of at least one predeterminable area of the memory (11), generates an associated cryptographic hash value (H) based on at least the test result (R), and returns the test result (R) and the hash value (H) to the processor (12), - transmitting the test result (R) and the hash value (H) to the requesting unit (20) as an insecure test result (R*) and insecure hash value (H*), - Validating the transmitted insecure test result (R*) by the requesting unit (20) by generating the associated cryptographic hash value (H) based on the transmitted insecure test result (R*) and comparing it with the transmitted insecure hash value (H*), whereby a validation result (V) is positive and the integrity of the control unit (10) is determined if the two compared hash values (H, H*) match, and negative otherwise, whereupon the control unit (10) is determined to be compromised, and - Providing the validation result (V). Procedure according to Claim 1 , wherein with each request for the integrity check a random value (Z) is generated and transmitted by the request unit (20) to the control unit (10) and provided to the hardware security module (15) as an unsafe random value (Z*), wherein the execution of the integrity check by the hardware security module (15) includes determining the hash value (H) additionally based on the unsafe random value (Z*) and the validation of the transmitted unsafe check result (R*) by the request unit (20) includes determining the hash value (H) additionally based on the generated random value (Z). Procedure according to Claim 1 or 2 , in which the execution of the integrity check by the hardware security module (15) before returning the hash value (H) to the processor (12) includes encrypting the hash value (H) and the validation of the transmitted insecure check result (R*) by the request unit (20) before comparing the two hash values (H, H*) includes decrypting the transmitted insecure hash value (H*). Procedure according to Claim 3 , in which the encryption of the hash value (H) and the decryption of the transmitted insecure hash value (H*) are carried out using an asymmetric cryptographic encryption method, wherein the hash value (H) is encrypted by the hardware security module (15) with a control unit-related private key (K _priv,ID ) stored in it and the transmitted insecure hash value (H*) is decrypted by the request unit (20) with one of the control unit-related public keys (K _pub,ID ) that can be provided to it. Procedure according to Claim 4 , in which the request for integrity checking by the requesting unit (20) includes requesting and providing the ECU-related public key (K _pub,ID ) by means of an individual identification feature (10) assigned to the ECU (10) from a data collection (K _pub,ID0.n ) of several ECU-related public keys. Method according to one of the preceding claims, wherein the hardware security module (15) determines as the test result (R) a hash value or checksum formed from the memory content of at least one predeterminable area of the memory (11). Procedure according to one of the Claims 1 until 5 , in which the hardware security module (15) determines as the test result (R) a binary result of a comparison of a hash value or checksum formed from the memory content of at least one predeterminable area of the memory (11) with corresponding hash or checksum comparison values (Σx) stored in a tamper-proof memory (16) of the hardware security module (15), wherein the result of the comparison is positive and indicates the integrity of the control unit (10) if the compared values match, and is otherwise negative and indicates a compromise of the control unit (10). Procedure according to Claim 7 , in which the result of the comparison is stored by the hardware security module (15) in the tamper-proof memory (16) of the hardware security module (15). Method according to one of the preceding claims, wherein the validation result (V) is provided with time information (T) by the request unit (20). Method according to one of the preceding claims, wherein the area of the memory (11) of the control unit (10), based on whose memory content the hardware security module (15) forms the test result (R), is predetermined by the request unit (20) and transmitted to the control unit (10) with the request for the integrity check. System (40) for integrity testing of a control unit (10), in particular a control unit for a vehicle, comprising the control unit (10) which has a memory (11) for program instructions and data, a processor (12) for executing the program instructions and for processing the data and a hardware security module (15), and a request unit (20) for requesting the integrity test at the control unit (10), wherein the request unit (20) and the control unit (10) are configured to establish a communication connection between the request unit (20) and the hardware security module (15) of the control unit (10) via the communication-mediating intermediary of the processor (12) of the control unit (10) and to carry out a method according to one of the preceding claims.