METHOD FOR KEY EXCHANGE BETWEEN AN ENGINE CONTROL UNIT AND A SENSOR

Abstract

The present invention relates to a method for key exchange between an engine control unit (3), in particular an engine control unit (3) for controlling an internal combustion engine (2), and a sensor (4, 5, 37), in particular a sensor (4, 5, 37) for detecting an emission value. The method comprises determining (41) an authorization for key exchange; transmitting (47), based on the determined authorization, a first partial key to the sensor (4, 5, 37), wherein the first partial key is based on a random number (26); and generating (49) a session key (9, 10) for communication with the sensor (4, 5, 37), wherein the session key (9, 10) is based on the random number (26). The present invention further relates to an engine control unit (3) and a motor vehicle (1).

Description

The invention relates to a method for key exchange between an engine control unit and a sensor.It is known to record emission values of internal combustion engines. For example, sensors are known that measure an emission of nitrogen oxides (NOx) in an exhaust gas of an internal combustion engine. More stringent legislation could require protection of sensors for sensing emission values of an internal combustion engine in order to prevent or at least make difficult manipulation of the sensors.One approach includes protecting a sensor using cryptographic means. For example, cryptographic keys for controllers may be managed with a vehicle key management system (VKMS). A potent VKMS may call for certain diagnostic functionalities on a controller to operate with the controller. However, the VKMS cannot thereby operate with control units which implement only a certain basic range of diagnostic functionalities and do not meet the requirements of the VKMS. For example, for some "small" control units, in particular sensor components such as a NOx sensor, there may be no or only very little diagnostic functionality. VKMS cannot be used in such sensors.In particular, the creation of a trust anchor has not been implementable in previous solutions (e.g. the VKMS, the diagnostic anti-sampling system (DIAS) project and proprietary solutions with global initial secrets) for "small" control units. Either a prior transmission of control device-specific data from the control device supplier to the vehicle manufacturer (original equipment manufacturer, OEM) had to take place, which then had to be read out in the vehicle production (keyword: diagnostic capability), or a key exchange was initiated on the basis of global secrets. However, these global secrets can then be particularly critical, and knowing the global secrets can underbrogate the security of all other sensors still to be used which have already been produced with the respective global secret. All sensors located in the field or stored in storage inventories can thus be attacked.U.S. Pat. No. 8,913,747 B2 discloses a method for the secure configuration of a sensor system. The method includes identifying a new sensor that is not activated within the sensor system, the new sensor including a new sensor identifier, establishing a first communication link between the new sensor and a sensor controller, communicating the new sensor identifier between the sensor and the sensor controller, generating a key pair for the sensor controller, the key pair including a controller public key and a controller private key, generating a key pair for the new sensor, the key pair including a sensor public key and a sensor private key, communicating the controller public key to the new sensor and the sensor public key to the sensor controller, and generating a paired key within the sensor controller and the new sensor. The method has the disadvantage that a trust anchor cannot be established without using a global secret. The method further has the disadvantage that a training of a new sensor takes place on the basis of a check on the basis of a list of authorized sensors. Backend communication thus takes place and global or individualized sensor data are required, which must be attributable and proveable.WO 2021 / 065754 A1 discloses a data acquisition system comprising a host device and a sensor device for transmitting measurement data to the host device via a network, wherein the data acquisition system is capable of secure communication between the host device and the sensor device and is capable of reducing power consumption of the sensor device. The data acquisition system is provided with a host device and a battery-powered sensor device for transmitting measurement data to the host device via a network. The host device includes a cryptographic key generation unit for generating a cryptographic key specific to the sensor device, a storage unit for storing the cryptographic key, a transmission unit for transmitting the cryptographic key to the sensor device using a public key cryptographic infrastructure, and a reception unit for receiving the measurement data of the sensor device. The sensor device includes a receiving unit for receiving the cryptographic key transmitted from the host device, a packet generating unit for generating a packet including the measurement data encrypted with the cryptographic key, and a transmitting unit for transmitting the packets by broadcast. The data acquisition system has the disadvantage that a prior transmission of control device-specific data from the control device supplier to the OEM is necessary.U.S. Pat. No. 8,675,875 B2 discloses that the use of cryptographic key storage hardware security modules is optimized in a system having a first, low-security key storage device and a second, more abundant, low-security key storage device. The use comprises saving a cryptographic key to the higher level of security by initially storing the key in the first storage device, then in response to an event evaluating the stored key according to one or more rules, and subsequent to the evaluation reclassifying the stored key for relocation, encrypting the reclassified key using a key encryption key; moving the reclassified key to the second, less saved storage device; and storing the key encryption key in the first storage device. The use has the disadvantage that it only allows a key to be stored, but not a "small" control device with limited diagnostic capability to be secured.US 11,650,935 B2 discloses secure key provision technologies comprising a computing device having a processor with support for a secure enclave and a manageability controller. The manageability controller receives a secret key from a network source via a network interface isolated from non-trusted software of the computing device. The manageability controller authenticates a secure enclave of the computing device and, if successful, provides a session key derived from the secret key securely to the secure enclave. The manageability controller may provide additional session keys after the session key expires. The manageability controller may monitor whether the secret key is retrieved from the network source. Upon call-back, the maintainability controller does not provide any further session keys to the secure enclave. The manageability controller may also provide the session key to a sensor device protected by the secret key provided to the sensor device in advance. The technologies have the disadvantage that a prior transmission of control device-specific data from the control device supplier to the OEM is necessary.U.S. Pat. No. 10,893,057 B2 discloses systems and methods for ensuring data security. For each selected message from a data protocol containing at least two messages, a MAC is calculated in sequence. To build a block of data, a preset encryption key is used for a first message and an encryption key for the previous message is used for subsequent messages. A determination that the data protocol is compromised may be made based on MAC frame data and an independent calculation of a MAC. The systems and methods have the disadvantage that a prior transmission of control device-specific data from the control device supplier to the OEM is necessary.The existing solutions therefore do not allow cryptographic key material to be exchanged with a secure method even for "small" control units which have only a limited diagnostic capability.It is an object of the present invention to provide a method, engine control unit and motor vehicle which at least partially overcomes the above-mentioned disadvantages.This object is achieved by the method according to the invention as claimed in claim 1, by the engine control device according to the invention as claimed in claim 9 and by the motor vehicle according to the invention as claimed in claim 10.Further advantageous embodiments of the invention are evident from the dependent claims and the following description of preferred exemplary embodiments of the present invention.A first aspect of the invention relates to a method for key exchange between an engine control unit (ECU), in particular an ECU for controlling an internal combustion engine, and a sensor, in particular a sensor for detecting an emission value, the method comprising:determining an enable for key exchange;transmitting, based on the determined enabling, a first partial key to the sensor, wherein the first partial key is based on a random number; andgenerating a session key for communication with the sensor, wherein the session key is based on the random number.Each of the MSG and the sensor may include a computing unit (e.g., a central processing unit (CPU), a programmable microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or the like), a storage unit (e.g., flash memory, electrically erasable programmable read-only memory (EEPROM), magnetic memory, or the like), and a communication unit (e.g., for communication via controller area network (CAN), Ethernet, Wi-Fi (IEEE 802.11), universal serial bus (USB), or the like). The computing unit can control a functionality of the MSG or of the sensor based on software and / or firmware instructions, which can be stored in the memory unit. The MSG and the sensor may be connected to each other via their respective communication units, for example, via a CAN bus, via Ethernet, via Wi-Fi, via USB, or the like, and thus may communicate.The ECU may be configured to control an engine based on an emission value of the engine detected by the sensor. The engine may provide torque based on combustion of a fuel. The fuel may include gasoline, diesel, kerosine, ethanol, methanol, natural gas, liquefied gas, hydrogen, or the like. The internal combustion engine may exhaust combustion products.The emission value may indicate, for example, an emission of the internal combustion engine. For example, the ECU may control the internal combustion engine such that the emission value detected by the sensor does not exceed a predefined limit value. If the emission value detected by the sensor exceeds a predefined limit value (e.g. briefly), the ECU can control the internal combustion engine such that the emission value detected by the sensor is again within the predefined limit value. Whether the emission value exceeds the predefined limit value can be determined by the MSG on the basis of the emission value detected by the sensor.The predefined limit value for the emission value can be legally predefined, for example. For example, in order for the emission value to meet the predefined threshold, the ECU may control the engine such that the engine provides a decreased power and / or torque.The MSG may determine whether the sensor is trusted based on a cryptographic key. For example, the sensor may sign the detected emission value according to the cryptographic key, e.g., using a message authentication code (MAC). The MAC may correspond to a checksum of data indicating the emission value detected by the sensor and the cryptographic key. To sign the detected emission value, the sensor may calculate the corresponding MAC and transmit it to the MSG along with the detected emission value. The MSG may calculate a MAC based on the emission value received from the sensor and compare it with the MAC received from the sensor. If the MAC calculated by the MSG matches the MAC received from the sensor, then the MSG may rank the corresponding emission value and sensor as trusted. If the MAC calculated by the MSG does not match the MAC received from the sensor (or if the sensor transmits the emission value without the MAC to the MSG), then the MSG may rank the emission value and the sensor as being untrusted, and cause, for example, an engine indicator light (MIL) to light up, thereby indicating that communication between the MSG and the sensor is failed.In order for both the MSG and the sensor to be able to calculate the MAC, it may be necessary for the cryptographic key for calculating the MAC to be present both in the MSG and in the sensor. For example, an initial key exchange may occur in which the MSG and sensor negotiate the cryptographic key (e.g., through the exchange of information from which the cryptographic key may be generated).In order to make it difficult to manipulate the sensor (e.g. to exchange the sensor and / or to intercept and / or change the emission value transmitted by the sensor), it may be necessary to exchange the cryptographic key between the MSG and the sensor in a way that is secure against interception, for example by not transmitting the cryptographic key itself. For example, the key exchange between the MSG and the sensor may be based on Diffie-Hellman key exchange.The ECU may initiate key exchange upon request, for example, during production / manufacture of a vehicle including the ECU, engine, and sensor, service, and / or repair.The MSG, when performing the key exchange, may identify one or more sensors connected to the MSG (e.g., via a CAN bus or the like, as described above) and may generate a new random number for each identified sensor and, based thereon, a first subkey and a session key, as described below. The MSG may alternatively also use the same random number (and the same first subkey) for a plurality of identified sensors. Additionally, in performing the key exchange, the MSG may delete (if present) a cryptographic key (e.g., session key) that the MSG generated in an earlier key exchange with the sensor(s).In order to prevent unauthorized key exchange, which can be requested for the purpose of manipulating the sensor, for example, the MSG can determine, before initiating the key exchange, whether an enable for the key exchange is present. The enabling may indicate an authorisation for carrying out a key exchange (and thus e.g. for exchanging the sensor and / or for adding a further sensor). For example, the MSG may deny key exchange with the sensor if the MSG cannot determine an enable for key exchange. On the other hand, when the MSG detects an enable for key exchange, it may perform key exchange.For key exchange, the MSG may transmit the first partial key to the sensor. The first partial key can be based on a random number. The MSG may include, for example, a random number generator and generate the random number with the random number generator. The MSG may generate the first partial key according to a predefined calculation rule based on the random number. The MSG may communicate the first subkey via the communication unit (e.g., via a CAN bus, etc., as described above). The predefined calculation rule can be based on a one-way function (trap door function, e.g. discrete logarithm, elliptic curve, prime factor decomposition, etc.), so that the random number cannot be derived from the first partial key (or can be derived only with low probability or only with high calculation effort). In some exemplary embodiments, it may be ensured that an attacker cannot ascertain the random number even if he is listening to the first partial key (e.g. as a man-in-the-middle between the MSG and the sensor). For example, the first partial key may comprise a public key of the MSG.The MSG may generate the session key based on the random number according to a predefined calculation rule. The session key can be used as a cryptographic key for signing the emission value detected by the sensor and for checking the signature, as described above.As a result, the MSG and the sensor can negotiate the session key for signing an emission value detected by the sensor in some exemplary embodiments in a manner secure against interception and secure against manipulation. In some exemplary embodiments, the ascertainment of the enabling for the key exchange makes it possible to dispense with a global secret for the authentication of the sensor in the MSG and with the upstream transmission of control-device-specific data from the control-device supplier to the OEM. Instead, the MSG may negotiate the session key with the sensor, for example, upon incorporation of the MSG and / or the sensor.In some embodiments, the method further comprises receiving a second partial key from the sensor; and generating the session key is further based on the second partial key.The second partial key can be based on a further random number. The sensor can generate the second partial key according to a predefined computing rule based on the further random number and transmit it via its communication unit to the MSG (e.g. via a CAN bus etc., as described above). The predefined calculation rule for generating the second partial key based on the further random number may be based on a one-way function (trap door function, e.g. discrete logarithm, elliptic curve, prime factor decomposition, etc.) and may correspond to the predefined calculation rule for generating the first partial key based on the random number, as described above. For example, the second partial key can comprise a public key of the sensor.For example, the sensor can generate the further random number with a random number generator contained in the sensor. If the sensor does not contain a random number generator, then the further random number can be written into a memory of the sensor at the factory, for example. For example, the sensor can use the same value for the further random number several times for key exchange, or the sensor can select a different value for the further random number for a first key exchange from a list with different values written in the memory of the sensor at the factory than for a second key exchange.The MSG may generate the session key based on the random number and on the second subkey. The sensor can generate a cryptographic key corresponding to the session key based on the further random number and on the first partial key, so that the MSG can verify a MAC, which the sensor has created based on the cryptographic key generated by the sensor, with the session key. For example, the cryptographic key generated by the sensor can correspond to the session key, e.g. be identical to the session key.The key exchange can be based on the Diffie-Hellman key exchange, so that the session key can be generated both based on the random number and the second partial key and based on the further random number and the first partial key.As a result, in some exemplary embodiments, the session key can be generated both by the MSG and by the sensor, wherein an attacker who only listens to the first partial key and the second partial key, but does not know either the random number or the further random number, cannot generate the session key. The MSG and the sensor can thus negotiate the session key in a tap-proof manner.In some embodiments, the MSG comprises a Hardware Security Module (HSM); and the creation of the session key is performed by the HSM.The HSM may comprise a random number generator and a cryptographic key memory (e.g. for the session key). The HSM may generate the random number with the random number generator, generate the first partial key based on the random number, and generate the session key based on the random number and on the second partial key. The HSM may store the session key in the cryptographic key memory. The HSM may transmit the first subkey to the sensor and receive the second subkey from the sensor.The HSM may receive and verify (check) an emission value and an associated MAC from the sensor. For example, the HSM may calculate a MAC based on the emission value and the session key stored in the memory of the HSM, and compare the thus calculated MAC with the MAC that the HSM has received from the sensor. If the two MACs match, then the HSM may output a signal indicating that the emission value is suspect. If the two MACs do not match, then the HSM may output a signal indicating that the emission value is not suspect.The HSM may prevent unauthorized access to the session key and to the random number. For example, the HSM may be configured to detect an access attempt to the random number generator and / or to the session key (e.g. by opening a housing of the HSM) and, if an access attempt is detected, to delete the session key.As a result, reading out or changing the session key (and thus also manipulation of the sensor) can be prevented or made more difficult in some exemplary embodiments.In some exemplary embodiments, the determination of the enabling comprises:receiving access data; anddetermining that a predefined production token indicates enabling of the access data.The credentials may identify a user account that may be associated with a user. For example, the access data can comprise a user name and / or an identifier of the user account. The access data can also comprise a user secret (e.g. password, passphrase, personal identification number (PIN), user certificate, electronic signature etc.), which only the user knows and on the basis of which the user can be authenticated. The MSG may receive the credentials from the user (e.g., through a user input, by loading a file with the credentials, by presenting a smart card (e.g., signature card), or the like).The production token may be stored in the MSG (e.g., in the HSM) and may indicate the release for the credentials. For example, the production token may be written to the MSG / HSM prior to production of a motor vehicle into which the MSG is installed (or prior to installation of the MSG into the motor vehicle). In some exemplary embodiments, it is thereby possible to ascertain the enabling for the access data without having to access an authorisation server (for example an SFD backend). For example, an OEM may use the production token to automatically perform key exchange between the MSG and the sensor when the MSG and the sensor are installed, e.g., in a vehicle.For example, the production token may correspond to a MAC or cryptographic hash of the credentials, and the MSG (or HSM) may calculate and compare a MAC or cryptographic hash of the credentials to the production token upon determining the enabling. Alternatively, the production token may also indicate the credentials in plain text, and the MSG (or HSM) may compare the received credentials to the production token upon determining the enabling.Upon matching the credentials and the production token, the MSG may determine that there is an enable for key exchange, and may perform the key exchange with the sensor (or with multiple identified sensors). If the credentials (or a MAC or cryptographic hash thereof) do not match the production token, then the MSG may deny key exchange.A validity of the production token may be limited to a production (e.g. of a vehicle in which the MSG is installed), such that key exchange based on the production token may be possible only during production. For example, the MSG may include a mechanism that inhibits insertion and / or use of a production token as a function of time, odometer / odometer distance, or the like.In addition, the MSG may delete or mark the production token as exhausted after key exchange, so that no further key exchange may be initiated and performed based on the production token. In some embodiments, on the other hand, the MSG does not delete the production token and marks it as not being used, so that the OEM can initiate a further key exchange with the production token.The manufacturer of the MSG and the OEM may keep the access data and / or the production token secret (e.g., hide from third parties) in order to prevent manipulation of the sensor based on the production token.In some exemplary embodiments, this can ensure that only the OEM can initiate a key exchange based on the production token. Additionally, the MSG may easily and quickly (e.g., without communication with an entitlement server or SFD backend) determine an enable for key exchange based on the production token, such that manufacturing (e.g., a vehicle in which the MSG and sensor are installed) is not long delayed by the determination of the enable.In some exemplary embodiments, the determination of the enabling comprises:receiving access data;transmitting the access data to an authorisation server; andreceiving the enabling from the authentication server.The credentials may identify a user account that may be associated with a user. For example, the access data can comprise a user name and / or an identifier of the user account. The access data can also comprise a user secret (e.g. password, passphrase, personal identification number (PIN), user certificate, electronic signature etc.), which only the user knows and on the basis of which the user can be authenticated.The authorisation server can store an enable for a key exchange for the user account identified by the access data. For example, the authorisation server can comprise a database in which an enable for a key exchange for one or more user accounts is stored.The MSG may receive the credentials from the user (e.g., through a user input, by loading a file with the credentials, by presenting a smart card (e.g., signature card), or the like) and communicate to the entitlement server via a communication network (e.g., via the Internet and / or an intranet). The authorisation server can authenticate the user on the basis of a checking of the user secret of the access data. The authorisation server can query from the database the clearance for the key exchange which is stored for the user account which is identified by the access data and can transmit the clearance to the MSG. The MSG may receive the enable from the entitlement server and determine that there is an enable for key exchange.The authorization server can, for example, operate an OEM (e.g. a vehicle manufacturer), which installs the MSG and the sensor (e.g. in a vehicle). A diagnostic tester and / or service technician (e.g., entrusted with vehicle maintenance and / or repair) may be registered with the OEM as a user, where the registration may include creating the user account associated with the user, creating the credentials identifying the user account, and storing an enable for key exchange for the user account in the entitlement server. The OEM may check a trustworthiness of the user before registering the user.The authorisation server can also log which user initiates a key exchange at which time for which MSG and / or has requested an enable for a key exchange at the authorisation server.For example, the credentials may enable access to component protection such as vehicle protection diagnostic (SFD) protection, and the entitlement server may be included in an SFD backend.This can ensure that only trusted users can initiate a key exchange, whereas attackers for whom no clearance is stored in the authorization server cannot initiate a key exchange. In addition, logging can keep track of which user has initiated a key exchange, so that a manipulation of the sensor can be tracked better in some exemplary embodiments.In some embodiments, the method further comprises storing the session key in the MSG.The MSG (e.g., the HSM of the MSG) may store (persist) the session key until the next key exchange. For example, the sensor can be taught by the key exchange in the MSG, and the MSG can verify emission values detected by the sensor on the basis of the stored session key, as long as the session key is stored in the MSG and the sensor is thus taught in the MSG.If a further key exchange is initiated in the MSG, the MSG can delete the session key, so that the MSG no longer verifies emission values on the basis of the session key. If the MSG identifies the sensor again as a sensor connected to the MSG during the further key exchange, then the MSG can negotiate a new session key with the sensor and store the new session key in the further key exchange, so that the MSG can verify emission values detected by the sensor and signed on the basis of the new session key on the basis of the new session key.The sensor can also store (persist) the session key and delete it on the next key exchange.By storing the session key in the MSG (and in the sensor), it is necessary in some embodiments to initiate key exchange between the MSG and the sensor only in exceptional cases (e.g. when the sensor is exchanged). For example, a key exchange between the ECU and the sensor may not be necessary upon each restart of the ECU and / or start of the internal combustion engine controlled by the ECU. As a result, the initiation of the key exchange can be restricted to authorized specialist personnel (for whose user account an authorization for key exchange is stored in the authorization server). Furthermore, initiation of a key exchange and thus the addition of authorized professionals may only be necessary in exceptional cases (e.g. when replacing the sensor). The ascertainment of the activation based on the transmission of the access data to the authorization server is therefore only necessary in exceptional cases in some exemplary embodiments.In some embodiments, the ECU is configured to control an engine; and the communication with the sensor comprises: receiving, from the sensor, an emission value of the engine signed according to the session key.The ECU may control an operating state of the engine, for example. For example, controlling the engine may include controlling an air supply of the engine, controlling a fuel injection into the engine, controlling a speed of the engine, controlling a / a speed provided by the engine, torque and / or power, etc. Controlling the engine may also have an influence on an emission of the engine (e.g., an amount and / or composition of an exhaust gas, a noise emission, a heat emission, etc. of the engine).The sensor may be arranged in or on the internal combustion engine such that the sensor can measure the emission value of the internal combustion engine. While the MSG controls the engine, the sensor may detect (e.g., measure) the engine's emission value based on the session key (e.g., by computing a MAC as described above) and communicate the signed emission value to the MSG.The MSG may receive and check the emission value signed by the sensor according to the session key from the sensor, e.g., by calculating a MAC and comparing the MAC calculated by the MSG with the MAC calculated by the sensor). For example, the ECU may control an operating state of the internal combustion engine such that the emission value does not exceed a predefined limit value.In some exemplary embodiments, this makes it possible to prevent the internal combustion engine from exceeding the predefined limit value for the emission value, and / or the ECU can control the internal combustion engine when the predefined limit value is exceeded (for a short period of time) such that the emission value no longer exceeds the predefined limit value.In some embodiments, the emission value is indicative of a nitrogen oxide (NOx) content in an exhaust gas of the internal combustion engine.The NOxcontent may comprise, for example, a nitric oxide content and / or a nitrogen dioxide content.However, the emission value is not limited to the NOx content. In some embodiments, the emission value additionally or instead indicates a hydrocarbon content, a carbon monoxide content, a carbon dioxide content, an ammonia content, a particulate matter content (e.g., particulate mass and / or number of particles, e.g., soot particles), or another pollutant content of the exhaust gas. The exhaust gas may include a combustion product of the combustion of the fuel in the internal combustion engine. In some embodiments, the emission value additionally or instead indicates noise emission, temperature emission (e.g., heat radiation / output), or the like of the engine.Thereby, it may be possible to reduce emission of the engine by appropriate control by the ECU.A second aspect of the invention relates to an engine control unit (ECU), in particular for controlling an internal combustion engine, which is configured to carry out the method described above.The MSG may include the features described above. Each feature described for the method may also represent a corresponding feature of the MSG.As a result, it may be possible to control an internal combustion engine with the ECU in such a way that an emission (for example pollutant emission, as described above) of the internal combustion engine is reduced, for example that the emission value does not exceed a predefined limit value or only briefly exceeds it. Furthermore, it may thereby be possible to protect the sensor from manipulation.A third aspect of the invention relates to a motor vehicle which comprises:the above-described MSG, anda sensor;wherein the sensor is configured to receive the first partial key from the MSG and generate the session key based on the first partial key.For example, the motor vehicle may include an internal combustion engine as a traction machine. The ECU may control the engine, and the sensor may detect and transmit an emission value of the engine to the ECU signed. The ECU and the sensor may exchange the session key for signing the emission value of the internal combustion engine detected by the sensor according to the method described above.The motor vehicle may include, for example, a passenger car, truck, motorcycle (or other motorcycle), trike, locomotive (or other rail vehicle), or the like.For example, the motor vehicle may perform the method for sensor protection of NOx sensors prior to tampering according to the Euro 7 exhaust gas standard.As a result, it may be possible to control an internal combustion engine with the ECU in such a way that an emission (for example pollutant emission, as described above) of the motor vehicle is reduced, for example that the emission value does not exceed a predefined limit value or only briefly exceeds it. Furthermore, it may thereby be possible to protect the sensor of the motor vehicle from manipulation.However, the method is not limited to a motor vehicle. For example, the ECU, the sensor and the internal combustion engine can also be installed in a working machine (e.g. chainsaw, vibrating plate, compressor, power unit, etc.). The GMAW, the sensor and the internal combustion engine can also be installed in a maritime means of transport (e.g. ship, boat, air cushion boat, submarine etc.) or in a means of transport of aircraft (e.g. aircraft, helicopter, multicopter, airship etc.). As a result, it is also possible to reduce emission of such working machines, maritime means of transportation or means of transportation of the aircraft and to secure the sensor installed therein against manipulation.The method, MSG and motor vehicle according to the invention has the advantage in some exemplary embodiments that a sensor-specific pre-requirement with an asymmetric key pair can be omitted and instead a sensor-specific key negotiation with the MSG can take place. In addition, the training of the sensor in the MSG can be secured by a user restriction via SFD. This makes it possible to track training processes via an SFD backend log and thus achieve better localizability of attackers, as a result of which a higher risk for an attacker can arise. In addition, in some exemplary embodiments, no diagnostic connection to the sensor is necessary, because the MSG can take over key management.Embodiments of the invention will now be described by way of example and with reference to the accompanying drawing, in which: FIG. 1 schematically illustrates an exemplary embodiment of a motor vehicle having an engine control unit; FIG. 2 illustrates an embodiment of a summary of a method for key exchange between an engine controller and sensors; FIG. 3 illustrates an exemplary embodiment of a sequence of a method for key exchange between an engine control unit and sensors; and FIG. 4 illustrates an exemplary embodiment of a method for key exchange between an engine control unit and a sensor.An exemplary embodiment of a motor vehicle 1 having an engine control unit (ECU) 3 is illustrated in FIG. 1. The automobile 1 includes an engine 2 and the ECU 3. The ECU 3 controls the engine 2, The automobile 1 also includes a first sensor 4 and a second sensor 5. the first sensor 4 and the second sensor 5 measure a nitrogen oxide (NOx) content in an exhaust gas of the engine 2. The ECU 3 controls the internal combustion engine 2 on the basis of the NOxcontent measured by the first sensor 4 and the second sensor 5 and on the basis of an engine speed 6 of the internal combustion engine and on further measured values 7.The MSG 3 comprises a hardware security module (HSM) 8. The HSM 8 stores a first session key 9 and a second session key 10. The first session key 9 and the second session key 10 are symmetric keys. The first session key 9 is also stored in the first sensor 4 and the second session key 10 is also stored in the second sensor 5.The first sensor 4 measures the NOx content, signs 11 it according to a lightweight sensor signal protection (LSA) with the first session key 9 and transmits a signal with the signed NOx content to the MSG 3. The second sensor 5 also measures the NOx content, signs 11 it according to the LSA with the second session key 10 and transmits a signal with the signed NOx content to the MSG 3. The signatures from 11 each comprise a message authentication code (MAC) and, like the measured NOx content, are transmitted from the first sensor 4 and the second sensor 5 to the MSG 3 via a CAN bus.The HSM 8 further comprises a plausibility checker 12. The plausibility checker 12 checks the signatures of the signals with the signed NOx content from the first sensor 4 and the second sensor 5 with the first session key 9 and the second session key 10, respectively.The motor vehicle 1 further comprises a programmable combined appliance (FPC) 13. the FPC 13 is also referred to as a switchboard, instrument cluster, instrument panel or the like in some cases. The FPC 13 includes an engine control lamp (MIL) 14.The FPC key 15 is also stored in the HSM 8. If the plausibility checker 12 determines that the signatures of the signals with the signed NOx content are trusted and plausible in content (i.e. are signed with the first session key 9 or the second session key 10), the HSM 8 signs a command for deactivation of the MIL 14 with the FPC key 15 for a secure onboard communication (SOK; also called SecOC in the AUTOSAR environment) and transmits 16 the command to the FPC 13 via the CAN bus.The FPC 13 receives the command to deactivate the MIL 14, checks the signature based on the FPC key 15, and controls the MIL 14 accordingly. If the FPC 13 determines during the check that the command for deactivating the MIL 14 is correctly signed (and thus trusted), then the MIL 14 goes out, otherwise the MIL 14 continues to light.An object of the concept illustrated in FIG. 1 is recognition of tampering. The NOx value is authentically transmitted from the sensors 4 and 5 to the MSG 3 via LSA. Session keys 9 and 10 are exchanged between MSG 1 and sensors 4 and 5 according to a lightweight offline key agreement (LOKA) after SFD release via a Diffie-Hellman protocol.However, the present technology is not limited to two (NOx) sensors 4 and 5, but the key exchange may be performed with any number of (e.g., NOx) sensors, for example, one sensor or three or more sensors. Signing and / or transmitting the MIL disable command is not limited to SOK / SecOC and may be performed in any other suitable manner.Embodiments of a method for exchanging the session keys 9 and 10 between the MSG 3 and the sensors 4 and 5 according to LOKA will be described below with reference to Figs. 2 to 4.FIG. 2 illustrates an embodiment of a summary of a method for key exchange between the MSG 3 and the sensors 4 and 5.At 21, SFD login is performed. In this case, a user logs on to an SFD backend with access data. For this purpose, the MSG 3 executes an SFD login routine 22. The SFD login routine 22 provides access to the MSG 3 based on the unified diagnostic services (UDS) protocol 23. The SFD login routine 22 identifies the user based on the credentials and determines a user enable for a secure diagnostic on the MSG 3, including a user enable for a key exchange between the MSG 3 and the sensors 4 and 5. If the user is enabled for the key exchange, the SFD login routine 22 activates a diagnostic routine start_keyexchange_sensor with which the user can initiate the key exchange between the MSG 3 and the sensors 4 and 5.At 24, key exchange is initiated between the MSG 3 and the sensors 4 and 5. During the production of the vehicle 1 (e.g. by an engineer, by a testing technique and / or by an automatic installation routine) or by the customer service, the key exchange on the MSG 3 is started by calling up the diagnostic routine start_keyexchange_sensor. The MSG 3 then sends a request for key exchange to the sensors 4 and 5.At 25, the first session key 9 is determined on the basis of a secret number 26 of the MSG 3 and a secret number 27 of the first sensor 4 via the Diffie-Hellman protocol and is persistent on both sides (i.e. in the HSM 8 of the MSG 3 and in the first sensor 4). The secret number 26 of the MSG 3 is generated with a random number generator of the HSM 8. For ascertaining the first session key 9, the MSG 3 generates a public key (an example of a partial key) on the basis of the common number 26 of the MSG 3, a predefined base curve and a predefined base point and transmits the public key to the first sensor 4. Likewise, the first sensor 4 generates a public key on the basis of the secret number 27 of the first sensor 4, the base curve and the base point and transmits the public key to the MSG 3. MSG 3 and the first sensor 4 then ascertain the first session key 9 on the basis of the common number 26 or 27 and the respectively received public key.At 28, the second session key 10 is determined on the basis of the secret number 26 of the MSG 3 and a secret number 29 of the second sensor 5 via the Diffie-Hellman protocol and is persistent on both sides (i.e. in the HSM 8 of the MSG 3 and in the second sensor 5). For the determination of the second session key 10, the HSM 8 can use the same secret number 26, on the basis of which the first session key 9 is determined, or generate a new secret number 26 with the random number generator. As described for 25, the MSG 3 and the second sensor 5 each generate a corresponding public key for the determination of the second session key 10 on the basis of the secret number 26 or 29, the base curve and the base point and transmit the public key to the second sensor 5 or to the MSG 3. The MSG 3 and the second sensor 5 then determine the second session key 10 on the basis of the secret number 26 or 29 and the respectively received public key.By determining the enabling of the key exchange function via SFD, in some exemplary embodiments only persons with SFD rights can learn a NOx sensor (e.g. the sensors 4 and 5) on the MSG 3.In some exemplary embodiments, external sensors can be incorporated only with SFD rights. As a result, a message for vehicle information and central identification tool (FAZIT) may be unnecessary. In some exemplary embodiments, the NOx sensor does not have to output a FAZIT ID and therefore also does not require diagnostic measured values.The sensor (e.g. the sensors 4 and / or 5) itself does not need to enable key exchange in some exemplary embodiments. The sensor 4 or 5 therefore does not have to be configured to determine an enable for key exchange. If someone other than the MSG 3 starts a training process (key exchange) on the sensor 4 or 5, the sensor 4 or 5 can lose its key 9 or 10 (e.g. delete it and replace it with a newly generated key), so that the MSG 3 can continue to recognize signatures from the sensor as implausible. Therefore, validation of NOxvalues from the corresponding sensor 4 or 5 by the MSG 3 may fail. The MSG 3 may then turn on the MIL 14.If the MSG 3 and / or the sensor 4 or 5 have an integrity problem of the key 9 or 10, then LSA can no longer verify messages.An exchange of sensors (e.g. sensors 4 and / or 5) may be possible without problems with renewed training via an SFD login.By descrambling a secret number (e.g., the secret numbers 26, 27 and / or 29), each sensor MSG link may receive an individual key 9 and 10, respectively. In some exemplary embodiments, the first sensor 4 and / or the second sensor 5 does not itself generate the secret number 27 or 29 and / or its public key, but rather receives the secret number 27 or 29 and / or the public key assigned from an external crypto server during production of the sensor 4 or 5. Thus, a secret key 27 or 29 and public portion (e.g. public key, partial key or partial diffie) of the sensor 4 or 5 can be written individually in the supplier production.Pre-provisioning the sensor 4 and / or 5 at the supplier with the secret number 27 or 29 (and / or with the corresponding public key) may reduce a key calculation time (e.g., a time required for key exchange between the MSG 3 and the sensor 4 or 5) in production at an OEM.As a result of persistence of the matched key 9 or 10, an influence on a heating time of the sensor 4 and / or 5 as in the case of VKMS can be omitted, since the key 9 and / or 10 can be permanently available. For example, LOKA can perform a faster checking of the keys 9 and / or 10 in a startup, and / or locking of the keys 9 and / or 10 during the checking can be omitted in the case of LOKA.A need for a diagnostic functionality in the sensor 4 or 5 can be dispensed with.Cyclical status information of the sensor 4 and / or 5 can pass on a key state of the session key 9 or 10 to the MSG 3.Logging MSG SFD releases in a backend may increase a risk of workshops being vendably involved in installing a man-in-the-middle (MitM) box.FIG. 3 illustrates an exemplary embodiment of the sequence of the method from FIG. 2 for a key exchange between the MSG 3 and the sensors 4 and 5.At 31, login occurs in MSG 3 as described for 21 in FIG. 2. An enabling for a key exchange takes place during the production 32 of the vehicle 1 via a production token. After production 32 (e.g. during a customer service or a repair), a diagnostic tester 33 is enabled for key exchange via an SFD backend 34.At 35, the diagnostic routine start_keyexchange_sensor is executed by a test technique or diagnostic tester 33, as described for 24 in FIG. 2.At 36, the MSG 3 identifies all connected NOx sensors, including the first sensor 4, the second sensor 5 and a further sensor 37. the MSG 3 dices the secret number 26, a random number, in the HSM 8 and discards all previously known session keys for the sensors 4, 5 and 37. the MSG 3 individually establishes a connection with each sensor 4, 5 and 37 and invokes a routine calculate_sessionkey( ) in the respective sensor 4, 5 and 37. The respective sensor 4, 5 or 37 then discards a previously known session key. The MSG 3 and the respective sensor 4, 5 and 37 perform key exchange according to the Diffie-Hellman protocol. The respective sensor 4, 5 and 37 persistences the session key 9 and 10 thus generated. the MSG 3 also persistences the key 9 and 10 respectively for the respective sensor 4, 5 and 37 and repeats the process at 36 for each other identified sensor 4, 5 and 37. the process at 36 is an example of key exchange at 25 and at 28 in FIG. 2.The LSA can now use the session keys 9 and 10 thus generated.FIG. 4 illustrates an embodiment of a method for key exchange between an MSG (e.g., the MSG 3 of FIG. 1 ) and a sensor (e.g., the sensor 4 and / or 5 of FIG. 1 ). The ECU 3 is configured to control an internal combustion engine (e.g., the internal combustion engine 2 of FIG. 1 ). The sensor 4 and / or 5 is configured to detect an emission value. The ECU 3, the sensor 4 and / or 5, and the engine 2 are included in a motor vehicle (e.g., in the motor vehicle 1 of FIG. 1 ).At 41, the MSG 3 detects an enable for key exchange. During production (production) of the motor vehicle 1, the MSG 3 receives access data at 42 for determining the activation and determines at 43 that a predefined production token indicates the activation for the access data. For key exchange after the production (production) of the motor vehicle 1, the MSG 3 receives access data at 44 for determining the activation, transmits the access data at 45 to an authorisation server (e.g. the SFD backend 34 in FIG. 3 ) and receives the activation from the authorisation server 34 at 46.At 47, the MSG 3 transmits a first partial key to the sensor 4 or 5, based on the activation. The sensor 4 or 5 receives the first partial key from the MSG 3.At 48, the MSG 3 receives a second partial key from the sensor 4 or 5, respectively. The second partial key is based on a random number (e.g., the secret number 27 or 29 in FIG. 2 ).At 49, the HSM 8 of the MSG 3 generates a session key (e.g. the session key 9 or 10 in FIG. 1 ) for communication with the sensor 4 or 5. the HSM 8 generates the session key 9 or 10 based on the second partial key (e.g. on a public key of the sensor 4 or 5 respectively) and on the random number 26. the sensor 4 or 5 generates the session key 9 or 10 based on the first partial key (e.g. on a public key of the MSG 3) and on the random number 27 or 29 respectively.At 50, the HSM 8 of the MSG 3 stores the session key 9 and 10, respectively. Storing the session key 9 and 10, respectively, at 50 is an example of persistence of the session key 9 and 10, respectively, at 36 in FIG. 3.At 51, the ECU 3 receives from the sensor 4 or 5 an emission value of the internal combustion engine 2 signed according to the session key 4 or 5, respectively. the reception of the emission value at 51 is an example of communication of the ECU 3 with the sensor 4 or 5, respectively.In some exemplary embodiments, the MSG 3 determines the enabling operation not according to 42 and 43 based on the production token, but according to 44 to 46 based on the authorisation server. In some exemplary embodiments, the MSG 3 determines the activation not according to 44 to 46 based on the authorisation server, but according to 42 and 43 based on the production token. In some embodiments, the MSG 3 receives the second subkey at 48 prior to transmitting the first subkey at 47.The method, MSG and motor vehicle described above, in some embodiments, enables off-line lightweight key exchange (LOKA) between the MSG and one or more sensors and may have advantages over alternative solutions.An alternative solution is based on using global initial secrets in a sensor.This alternative solution may have the disadvantage that after the global initial secret has become known, a symmetrical communication key to be exchanged between the MSG and the sensor can be intercepted. LOKA prevents in some exemplary embodiments the key exchange from being able to be intercepted by individual initial keys.In some cases, attempts are made to address the disadvantages of the alternative solutions by designing multiple concepts in parallel to address specific security disadvantages. In addition, an assessment of a feasibility of a standard solution of an OEM (e.g. VKMS) can take place. In this case, a balance can be made between costs and benefit.In general, the approach can be pursued to find a reasonable balance between improved security (security) and production costs (e.g., in terms of time and piece costs). LOKA may be suitable for this.The method, MSG and motor vehicle according to the invention can make it possible that diagnostic communication with a sensor is no longer necessary. In addition, a key negotiation can take place offline, so that in addition to a diagnosis enabling no back-end communication must be necessary. Further, keys may be sensor specific, such that an attack may be more difficult to scale, as an attack may require clicking each sensor individually. As a result, scalability can be limited to the execution of the attack. Additionally, as indicated by the term "lightweight", impact on production and service may be minimized in some embodiments.List of reference characters1 Motor vehicle 2 internal combustion engine 3 MSG 4 first sensor 5 second sensor 6 engine speed 7 further measured values 8 HSM 9 first session key 10 second session key 11 signing 12 plausibility checker 13 FPK 14 MIL 15 FPK key 16 MIL deactivation 21 SFD login 22 SFD login routine 23 UDS 24 start key exchange 25 key exchange first session key 26 secret number MSG 27 secret number first sensor 28 key exchange second session key 29 secret number second sensor 31 SFD login 32 production 33 diagnostic tester 34 SFD backend 35 execution diagnostic routine 36 key exchange 37 further sensor 41 enabling 42 production tokens received 43 ascertaining, indicating 44 Access Data Received 45 Access Data Transmitted 46 Release Received 47 First partial key Transmitted 48 Second partial key Received 49 Session key Generated 50 Session key Storing 51 Receive signed emission valueReferences included in the specificationThis list of documents cited by the applicant has been produced in an automated manner and is only included for the better information of the reader. The list is not part of the German patent application or utility model application. The DPMA does not take any adhesion for any faults or omissions.Patent Literature citedU.S. Pat. No. 8,913,747 B2

[0005] WO 2021 / 065754 A1

[0006] U.S. Pat. No. 8,675,875 B2

[0007] U.S. Pat. No. 11,650,935 B2

[0008] U.S. Pat. No. 10,893,057 B2

[0009]

Claims

Method for key exchange between an engine control unit (3), in particular an engine control unit (3) for controlling an internal combustion engine (2), and a sensor (4, 5, 37), in particular a sensor (4, 5, 37) for detecting an emission value, the method comprising: - determining (41) an enable for key exchange; - transmitting (47), based on the determined enable, a first partial key to the sensor (4, 5, 37), wherein the first partial key is based on a random number (26); and - generating (49) a session key (9, 10) for communication with the sensor (4, 5, 37), wherein the session key (9, 10) is based on the random number (26).The method of claim 1, wherein the method further comprises: receiving (48) a second partial key from the sensor (4, 5, 37); and wherein generating (49) the session key (9, 10) is further based on the second partial key.Method according to claim 1 or 2, wherein the engine control device (3) comprises a hardware security module (8); and wherein the generation (49) of the session key (9, 10) is performed by the hardware security module (8).The method according to any of the preceding claims, wherein the determining (41) of the clearance comprises: - receiving (42) access data; and - determining (43) that a predefined production token indicates the clearance for the access data.The method according to any of the preceding claims, wherein the determining (41) of the clearance comprises: - receiving (44) access data; - transmitting (45) the access data to an authorisation server (34); and - receiving (46) the clearance from the authorisation server (34).The method according to any of the preceding claims, further comprising: storing (50) the session key (9, 10) in the engine control device (3).Method according to any one of the preceding claims, wherein the engine control device (3) is configured to control an internal combustion engine (2); and wherein the communication with the sensor (4, 5, 37) comprises: receiving (51), from the sensor (4, 5, 37), an emission value of the internal combustion engine (2) signed according to the session key (9, 10).Method according to claim 7, wherein the emission value indicates a nitrogen oxide content in an exhaust gas of the internal combustion engine (2).Engine control unit (3), in particular for controlling an internal combustion engine (2), which is configured to carry out the method according to one of Claims 1 to 8.Motor vehicle (1) comprising: - the engine control unit (3) according to claim 9, and - a sensor (4, 5, 37); wherein the sensor (4, 5, 37) is configured to receive the first partial key from the engine control unit (3) and to generate the session key (9, 10) based on the first partial key.

Images