Information technology system for introducing cryptographic keys into computing units

Abstract

The invention relates to an information technology system (1) for introducing cryptographic keys (6) into computing units (RE) in a vehicle (8).The information technology system (1) is characterized by a central computing unit (7), comprising a communication database module (KOM-DB), a vehicle-internal management unit (MD), and a vehicle-internal key distribution unit (KDM), wherein the key distribution unit (KDM) is configured to receive and read a manifest (2) assigned to the computing unit (RE), and to generate a key hash for each message type contained in the manifest (2) by applying a predefined hash function to a concatenation of the key ID (5) assigned to the respective message type and a random value generated by the key distribution unit (KDM), and to send the key hashes back to the affected computing unit (RE) via the management unit (MD) in a cryptographically secured manner.

Description

[0001] The invention relates to an information technology system for introducing cryptographic keys into computing units in a vehicle according to the type defined in more detail in the preamble of claim 1.

[0002] Electronic control units (ECUs) in vehicles such as cars are highly networked. To prevent attacks, it must be ensured that the ECUs communicate exclusively with trusted partners. The AUTOSAR standard Secure Onboard Communication (SecOC) has become established for communication via the corresponding vehicle onboard networks. However, this standard only specifies the securing of messages to ensure integrity using cryptographic key material. How exactly these cryptographic keys are introduced into the respective processing units, also known as provisioning, and how many different keys should be used, are not part of the standard.

[0003] US patent 11,917,086 B2 discloses short-lived symmetric keys for autonomous vehicles. In this system, multiple computing units perform a joint authentication process after a vehicle restart or reboot. A key server acts as an intermediary between the computing units. A first and a second computing unit each receive a cryptographic key from the key server to execute a symmetric encryption algorithm and store it in volatile memory. The key server, also located in the vehicle, deletes the cryptographic key after it has been provided. The first and second computing units use the cryptographic key to encrypt and decrypt exchanged messages. Because the respective cryptographic keys are stored in volatile memory, they are deleted when the vehicle restarts.To ensure that information is exchanged between trusted communication partners, established integrity protection mechanisms can be used, such as certificates, signatures, Message Authentication Codes (MAC), and the like. Information exchanged between computing units via the communication network can be transmitted using the User Datagram Protocol (UDP). The key server maintains a list of all communication partners and the respective keys required. If changes occur in the system, for example, because one of the communication partners requires different keys due to a software update, the list maintained by the key server must also be updated. This involves considerable technical effort and carries the risk of inconsistencies between the information stored in the list and the keys required according to the respective software versions.If many communication partners are involved, and these partners require a large number of different keys, the corresponding list can become very large, negatively impacting its processability and the required storage space. This makes it difficult to protect the underlying flash memory from physical tampering or to store the list in a dedicated hardware security module. To verify a signature on the list, the list must be loaded into RAM. The larger the list becomes, the longer it takes to load it into RAM, and an increasingly larger portion of the RAM is occupied, thus becoming unavailable for other applications.

[0004] Furthermore, DE 10 2020 213 611 A1 discloses a method for applying cryptographic functions to data using different keys in a computing unit. The computing unit comprises a host system, a hardware security module, and an accelerator module configured to perform cryptographic functions.

[0005] German patent application DE 10 2023 129 310 B3 describes a system for authorizing messages in a service-oriented vehicle architecture. An electronic control unit or node is configured to use a single key to generate requests from a security peripheral for a Message Authentication Code (MAC). The security peripheral contains the stored shared key.

[0006] Furthermore, DE 10 2011 081 036 A1 discloses a method for sending messages with integrity protection using a hash chain of consecutive values. The values ​​of the hash chain are valid in successive validity periods in reverse order of their generation.

[0007] The present invention is based on the objective of providing an improved information technology system for introducing cryptographic keys into the computing units in a vehicle, which avoids the disadvantages mentioned above and allows compliance with the so-called need-to-know principle.

[0008] According to the invention, this problem is solved by an information technology system for introducing cryptographic keys into computing units with the features of claim 1. Advantageous embodiments and further developments are described in the dependent claims.

[0009] An information technology system of the generic type for introducing cryptographic keys into computing units in a vehicle, wherein a pair of communicating computing units use the same cryptographic key for encrypting and decrypting messages in the course of symmetric encryption, comprises according to the invention: - a central computing unit comprising a communication database module, wherein a communication database managed by the communication database module represents the communication structure in the vehicle, and wherein the communication database module is configured to generate a manifest for each computing unit, taking into account the communication structure, representing a computer-readable file containing a unique computing unit identifier, a list of all message types to be processed by the respective computing unit during operation, and a unique key ID for each message type; and - an in-vehicle management unit and an in-vehicle key distribution unit; wherein - a respective computing unit is set up to generate the manifest relating to the computing unit based on a control unit-specific communication database maintained locally in the computing unit; - the administrative unit is set up to receive the manifest generated by the computing unit and forward it to the key distribution unit; - the key distribution unit is configured to receive and read the manifest assigned to the computing unit and, for each message type contained in the manifest, to generate a key hash by applying a predefined hash function to a concatenation of the key ID assigned to the respective message type and a random value generated by the key distribution unit, and to send the key hashes back to the affected computing unit via the management unit in cryptographically secure form; wherein - the computing unit is further configured to receive and store the key hashes and to use at least a predetermined part of each key hash as a cryptographic key for message-type-specific encryption and decryption of the messages.

[0010] The information technology system according to the invention enables fine-grained key distribution among multiple participants in a communication network via a central key distribution system, here in the form of the key distribution device, while adhering to the need-to-know principle based on the respective manifests. In contrast to a decentralized approach, where the keys are derived in the individual control units after the distribution of a common secret, the information technology system according to the invention no longer distributes the secret information required to derive the actual keys to the individual instances. Rather, the respective processing units receive only those cryptographic keys that they need to encrypt and decrypt the messages to be processed during operation. Thus, processing units do not come into possession of cryptographic keys that they do not actually need.This reduces the potential for compromise of cryptographically relevant information in the event of a data leak.

[0011] The individual cryptographic keys, or rather the underlying key hashes, are generated by the key distribution unit based on the respective key IDs and a random value. This random value is preferably a 256-bit secret, which, due to its criticality, is generated by the key distribution unit using a true random number generator. The random value and the key hashes are stored, in particular, in a hardware security module within the key distribution unit.

[0012] The use of individual manifests eliminates the disadvantages described in the context of the prior art. The manifest for each computing unit is generated twice. Firstly, this occurs externally within the vehicle in the communication database module, which generates individual manifests for all computing units. The central computing unit can be a server or server cluster, often referred to as the backend. Secondly, the computing units themselves are aware of their operating mode and communication structure, so each unit generates its own manifest. Each computing unit can be reliably identified and referenced using its unique identifier. A dedicated update of a central key server is unnecessary. The manifest is participant-specific, meaning it is unique to each computing unit. This reduces the amount of data that needs to be processed at once.Instead of a complete key list, only the comparatively small, participant-specific manifest needs to be verified and processed. This simplifies the handling of key lists, especially in embedded systems, which tend to have relatively little RAM. The method performed by the information technology system according to the invention for introducing the cryptographic keys into the individual processing units can therefore be scaled particularly easily, allowing any number of participants to participate. Since each communication participant stores their own manifest, it prevents a situation where, as with a centralized approach, a corresponding key server has to provide more and more storage space.

[0013] In particular, the computing units in the vehicle are control units.

[0014] According to an advantageous embodiment of the information technology system according to the invention, this system comprises a manifest signature distribution module and a public key infrastructure, which is configured to generate a manifest certificate for each manifest, a computing unit certificate for each computing unit, and a key distribution facility certificate for the key distribution facility, and to send the manifest certificates to the manifest signature distribution module for retrieval by the management unit, the computing unit certificates to the respective computing unit, and the key distribution facility certificate to the key distribution facility, wherein the respective computing units, the management unit, and the key distribution facility are configured to perform a certificate-based authentication and integrity check.This further increases cybersecurity in key distribution, as each communication participant only accepts data from verified communication participants.

[0015] According to a further advantageous embodiment of the information technology system according to the invention, it includes a manifest signature distribution module which is configured to generate a manifest hash by applying a predefined hash function to each manifest generated by the communication database module and to store this hash for retrieval by the administrative unit. This reduces the storage space required by the central computing unit, particularly in the manifest signature distribution module. Each manifest hash allows for the unique referencing of different manifests, without requiring the underlying manifest to be stored in its original form. Thus, each manifest hash comprises fewer characters than the complete manifest, thereby reducing the file size.After the manifest hashes are generated, the manifests used in the central computing unit can be deleted, since the key distribution unit obtains the manifests for deriving the key hashes from the computing units themselves. However, the manifest hashes allow for the unique referencing of individual manifests, enabling the reliable verification and authentication of the keys and certificates used in certificate-based authentication and integrity checks that relate to those manifests.

[0016] A further advantageous embodiment of the information technology system according to the invention provides that the respective computing unit and the key distribution unit are configured to secure the communication required for exchanging the key hashes using the Elliptic Curve Diffie-Hellman method. This allows the communication taking place between the respective computing units and the key distribution unit via the management unit to be cryptographically secured with particular reliability.

[0017] According to a further advantageous embodiment of the information technology system according to the invention, it is further provided that at least a subset of the portion of a respective key hash not used as a cryptographic key represents a checksum, and the management system is configured to obtain, in order to verify successful key distribution by the key distribution system to the computing units, respective pairs of checksum and key ID from each computing unit for each message type and to compare the checksums of identical key IDs obtained from different computing units. If the checksums, also referred to as "checksums," of a considered key ID are identical, this is an indication of successful key distribution.However, if it is found that two or more of the checksums of a respective key ID are different, countermeasures can be taken, such as issuing warning messages to an administrator or canceling the key distribution.

[0018] A further advantageous embodiment of the information technology system according to the invention provides that the key distribution device and the respective computing units are configured to store the key hashes sorted according to their associated key ID. For example, each pair of key hash and key ID, i.e., each set consisting of cryptographic key, checksum, and key ID, can be stored in ascending order according to the key ID. In this way, each memory location can be assigned a key ID. Since each computing unit knows its own key IDs and the received key hashes are sorted in ascending order, a correct assignment to the memory location can take place.

[0019] According to a further advantageous embodiment of the information technology system according to the invention, the key distribution device is further configured to receive a key list, in which key IDs can be stored, to compare the key list with the manifest of the computing unit, and, if the key list is empty, to generate key hashes for all key IDs contained in the manifest, and, if the key list contains entries, to generate key hashes only for the key IDs contained in both the key list and the manifest. This reduces the amount of data to be transmitted.

[0020] A further advantageous embodiment of the information technology system according to the invention provides that the manifest signature distribution module contains tuples of versioned manifests with associated versioned manifest certificates, generated based on a versioned communication database. The management unit is configured to retrieve the corresponding manifest from the manifest signature distribution module and send it to the key distribution unit, taking into account a target version. This allows for the installation of software updates in the respective processing units and a rollback to the previous version in case of an error. The communication structure in the vehicle or the communication database can be versioned. This allows for the maintenance of a specific variant for different software versions.Updates can lead to changes in the vehicle's communication structure, meaning that individual processing units exchange different messages with the same or other processing units. This may also require adjustments to the respective manifests. However, it is also conceivable to continue using existing manifests. Accordingly, as needed, customized manifest certificates, and thus manifest signatures and certificate references, can be maintained for each version.

[0021] Generating the manifest in the processing unit requires mapping the unit's communication structure according to the software version intended for that unit. However, for the processing unit to be aware of this communication structure, the software must be installed. During updates, an online connection cannot always be guaranteed, making it necessary to provide all required information to the processing unit before starting the software installation. This also applies to the information required for a rollback. Since retrieving the respective manifest signatures and manifest certificates is also impossible without an interrupted online connection, special measures must be taken to ensure successful key distribution. Therefore, the manifest signature distribution module is designed to include the vehicle's versioned communication structure.Versioned manifests can be saved directly for this purpose. These manifests describe the message types, key IDs, and computing unit identifiers requested by the computing unit in question for the software version under consideration. This also allows a corresponding update server to query the appropriate signatures and certificates, taking into account the software version to be installed, and deliver them to the vehicle.

[0022] According to a further advantageous embodiment of the information technology system according to the invention, it is further provided that at least part of the communication in the vehicle is based on AUTOSAR PDUs. This applies in particular to the communication between the management unit, computing units, and the key distribution unit. Thus, the distribution of cryptographic keys can be implemented simply and reliably, since UDS is implemented in most passenger cars.

[0023] Preferably, according to the invention, the administrative device can be implemented using a diagnostic tester.

[0024] A further advantageous embodiment of the information technology system according to the invention provides that the public key infrastructure is configured to execute a vehicle-specific manifest certificate, in particular by integrating the vehicle identification number into the manifest certificate. Thus, manifest certificates can only be used by an individual vehicle, which prevents key generation in the event of a compromise of the respective manifest certificates on unauthorized systems. This further increases cybersecurity.

[0025] Further advantageous embodiments of the information technology system according to the invention for introducing cryptographic keys into computing units in a vehicle also result from the exemplary embodiments which are described in more detail below with reference to the figures.

[0026] This shows: Fig. 1 a schematic representation of an information technology system according to the invention for introducing cryptographic keys into the computing units in a vehicle; Fig. 2. A schematic representation of a manifesto used in the course of distribution; and Fig. 3 A schematic representation of the encrypted exchange of messages between computing units in the vehicle.

[0027] Fig. Figure 1 shows a schematic representation of an information technology system 1 according to the invention, comprising a central computing unit 7 and a vehicle 8. The information technology system 1 enables the reliable and secure distribution of [information / data] in [the following context]. Fig. The 3 cryptographic keys 6 shown can be used to send messages to the computing units RE in the vehicle 8. The computing units RE use the cryptographic keys 6 to encrypt and decrypt messages exchanged between them. The cryptographic keys 6 thus function as symmetric keys. Only those computing units RE that, according to the underlying communication structure in the vehicle 8, need to receive or send a message corresponding to the message type, possess the corresponding cryptographic keys 6. This fulfills the so-called need-to-know principle. This is demonstrated by Fig. 3 explains that the encryption of message 713 is carried out using a cryptographic key 6713 intended solely for encryption and decryption of this message type. Communication via a data bus 9, over which the encrypted messages are exchanged, can in particular be based on AUTOSAR PDUs.

[0028] The central computing unit 7 and the vehicle 8 are connected via a management unit MD. The management unit MD could also be referred to as a management device. For example, the management unit MD could be a diagnostic tester. In addition to the management unit MD, the vehicle 8 contains a number of computing units RE, of which only one is shown, as well as a key distribution unit KDM. Each computing unit RE can be implemented as a control unit of a vehicle subsystem. The key distribution unit KDM can also be referred to as a key distribution master.

[0029] The central computing facility 7 includes a communication database module KOM-DB, a public key infrastructure PKI-CA and a manifest signature distribution module VERT.

[0030] The communication database managed by the KOM-DB communication database module describes the communication structure in vehicle 8. The communication database thus maps which computing unit RE exchanges which message type with other computing units RE. Each message type is defined as follows: Fig. Figure 2 shows that a separate key ID 5 is assigned. The cryptographic key 6, used to encrypt and decrypt a message of the type under consideration, can be referenced using key ID 5.

[0031] During key distribution, the communication database module KOM-DB generates a separate manifest 2 for each computing unit RE, which is then stored in Fig.2 is shown in detail. Each manifest 2 includes a processing unit identifier 3, referred to here as "ECUInstanzName". ECU stands for Electronic Control Unit. Furthermore, for the processing unit RE to which the manifest 2 is assigned, a list 4 of the message types to be exchanged between other processing units RE is shown. The manifest 2 of a specific processing unit RE is also generated locally by the respective processing unit RE itself. For this purpose, the communication structure pertaining to the processing unit RE is implemented within the processing unit RE.

[0032] The Public Key Infrastructure (PKI) Certificate Authority (CA) issues a certificate for certificate-based authentication and integrity verification to each computing unit (RE) and the key distribution unit (KDM). These certificates are designated as the computing unit certificate RE-ZERT and the key distribution unit certificate KDM-ZERT. Specifically, these are X.509 certificates that confirm the identity of the computing unit RE and the key distribution unit KDM. For identification purposes, each certificate RE-ZERT / KDM-ZERT includes a unique identifier for the respective device; for computing units RE, this is the computing unit identifier 3.

[0033] Furthermore, the public key infrastructure issues a manifest certificate M-ZERT for all, a subset, or each manifest 2. Each manifest 2 is signed with the private key associated with the manifest certificate M-ZERT, thus assigning a signature SIGN to each manifest 2. This ensures the authenticity of the respective manifest 2. Additionally, the manifest certificate M-ZERT can be restricted to individual vehicles 8, for example, for testing or development purposes, by including the vehicle identification number.

[0034] The manifest signature distribution module VERT stores the signatures SIGN and the associated manifest certificate M-ZERT, as well as a reference to the private key used for later identification. Furthermore, as will be explained later, a manifest hash generated by applying a defined hash function to each manifest 2 is stored in the VERT manifest signature distribution module. This allows for the unique referencing of manifests 2. The storage space required for the manifest hash is less than the storage space required to store the complete manifest 2. However, manifests 2, particularly for different software versions of a given computing unit RE, can also be stored in the VERT manifest signature distribution module itself. Some time before the manifest certificate M-ZERT expires, a new manifest certificate M-ZERT is issued, and the regeneration of all signatures SIGN is initiated by the communication database module KOM-DB.

[0035] The administrative unit MD initializes the key distribution and handles the communication between the central computing unit 7 and the hardware in the vehicle 8.

[0036] The key distribution unit (KDM) is capable of deriving all necessary cryptographic keys 6 from their respective key IDs 5 and making them available to the computing units (RE) indirectly via the management unit (MD). The derivation is performed by applying a defined hash function to a concatenation of the respective key ID 5 and a random value generated by the KDM using a true random number generator. As a result, a key hash is obtained for each message type. Preferably, not the entire key hash is used as the cryptographic key 6, but only a portion of it. The remaining portion, or a subset thereof, is used as a checksum. The random value and the generated key hashes are securely stored in a hardware security module within the KDM.

[0037] First, the central computing unit 7 generates the aforementioned manifests 2 for the computing units RE based on the content of the communication database. For each message type to be exchanged by the considered computing unit RE, the message type, along with its associated key ID 5 and the computing unit identifier 3, is written into manifest 2. The computing unit identifier 3 is also written into the computing unit certificate RE-CERT to ensure that the computing units RE can only use their own certificate.

[0038] The tuples from the manifest hash, signature SIGN, manifest certificate M-ZERT and the reference to it are stored in the manifest signature distribution module VERT.

[0039] The key exchange in vehicle 8 is now initiated by the management unit MD. The management unit MD iteratively reads, for each computing unit RE, the locally generated manifest 2 and the contained computing unit identifier 3, as well as the associated computing unit certificate RE-ZERT. If the key transfer between the key distribution unit KDM and computing unit RE is cryptographically secured using the Elliptic Curve Diffie-Hellman method, the management unit MD also reads a public one-time key and a nonce of the computing unit RE. The public one-time key of the computing unit RE is signed with the private key of the computing unit RE, which is authenticated by the computing unit certificate RE-ZERT. The manifest 2 generated locally by the computing unit RE is also signed by the computing unit RE with its private key.This ensures that the read-out Manifest 2 belonging to the computing unit certificate RE-ZERT actually originates from the computing unit RE belonging to the computing unit certificate RE-ZERT and has not been manipulated.

[0040] The administrative unit MD then generates a manifest hash for the manifest 2 obtained from the computing unit RE and retrieves the information stored for this manifest hash in the manifest signature distribution module VERT. Subsequently, the administrative unit MD sends the manifest 2, the signature SIGN of the manifest 2, the manifest certificate M-ZERT, the public one-time key of the computing unit RE, the number used once (nonce), the computing unit certificate RE-ZERT, and a potentially empty list of key IDs 5 to the key distribution unit KDM.

[0041] The key distribution unit (KDM) now verifies the computing unit certificate RE-ZERT and, based on this, the signature using the computing unit RE's public one-time key and Manifest 2 with the computing unit certificate RE-ZERT. Next, the manifest certificate M-ZERT is verified, and the signature SIGN of Manifest 2 is verified with the public key stored in the manifest certificate M-ZERT. Subsequently, the unique computing unit identifier 3 in the computing unit certificate RE-ZERT and in Manifest 2 is compared. After successful completion of the previous steps, the KDM generates a one-time key pair consisting of a public and a private one-time key for the Elliptic Curve Diffie-Hellman method to create a shared secret.

[0042] The key distribution unit (KDM) now compiles the list of cryptographic keys 6 to be derived for the current computing unit (RE). If the received key list is empty, all keys specified in Manifest 2 are generated. If, however, the key list contains entries, a comparison is made to determine which key IDs 5 are present in both the key list and Manifest 2. Key generation then occurs for all key IDs 5 that are present in both the key list and Manifest 2. Key IDs 5 that are only present in Manifest 2 are not generated. To generate the cryptographic keys 6, the KDM applies a defined hash function to the concatenation of the key ID 5 and a random value, as described above. This yields the aforementioned key hashes. A portion of each key hash can be used as a checksum.The key hash and key ID 5 pairs are preferably sorted in ascending order based on key ID 5. The nonce, cryptographic key 6, and checksum are then symmetrically encrypted using the shared secret. The key distribution unit (KDM) then signs this data, along with its public one-time key, using its private key and sends this data, together with the KDM certificate (KDM-ZERT), indirectly via the administrative unit (MD) to the relevant computing unit (RE).

[0043] The processing unit (RE) then verifies the key distribution system (KDM) certificate and thus the data received from the KDM. The RE then derives the shared secret based on its own private one-time key and the KDM's public one-time key, using the Elliptic Curve Diffie-Hellman method. These one-time keys are also referred to as "ephemeral keys." Each iteration between the KDM and another RE results in a new ephemeral key. The KDM can process multiple iterations in parallel. The RE then decrypts the nonce and key hashes using the shared secret. It compares the decrypted nonce with the nonce generated in the first step. If they are identical, the RE stores the key hashes and key hashes.The cryptographic keys (6) and their corresponding checksums. Thanks to the sorting based on the key ID (5), easy assignment to designated storage areas is possible.

[0044] To verify whether the distribution of the cryptographic keys 6 was successful, the administrative unit MD reads the checksums and corresponding key IDs 5 from all computing units RE. The distribution, i.e., the provisioning, was successful if the checksums for each key ID 5 are identical in all affected computing units RE.

[0045] To save time in vehicle production, it is conceivable to transmit the random value generated by the key distribution unit (KDM) via broadcast message to all computing units (RE) in vehicle 8, and to generate the key hashes locally in the computing units (RE). For security reasons, the computing units (RE) only store the random value in volatile memory.

[0046] Over the lifetime of each vehicle (8), it may be necessary to implement software updates in the respective computing units (RE). This allows bugs to be fixed, new functions to be implemented, security vulnerabilities to be closed, and the like. As part of such a software update, the underlying communication structure may change. This means that the respective computing units (RE) will exchange different messages with each other. Accordingly, it is necessary to update the respective manifests (2) and the cryptographic keys (6) implemented in the computing units (RE).

[0047] Nowadays, such software updates are usually performed wirelessly. An internet connection is required to download the software update. This internet connection is not strictly necessary for installing the software update. This means that a software update can be installed even without a connection to the central computer unit 7. However, the connection to the central computer unit 7 is required for exchanging and verifying the relevant certificates and signatures. To resolve this issue, the relevant information is transferred to the vehicle 8 before the software update is initiated.

[0048] The manifest signature distribution module VERT extends existing tuples consisting of the manifest signature SIGN, the manifest certificate M-ZERT, and the certificate reference to include the communication database version (i.e., a variant adapted to the respective software version) and the computing unit identifier 3. The communication database version used in the newly installed software version is known in advance. With this information, the respective update server can query the appropriate signature SIGN from the manifest signature distribution module VERT and send it to vehicle 8. For rollbacks, the administrative unit MD must read the existing manifest 2 of the current software version and obtain the respective manifest signatures SIGN and certificates M-ZERT.

[0049] The update server assembles the update package, consisting of a reference to the manifest signature SIGN associated with the software contained within the update package. The determination of the appropriate manifest signature SIGN is carried out via an additional documentation system, which stores the computing unit identifier 3 and the communication database version for each software version. Using the software version and ECUInstanceName, the manifest signature SIGN can be retrieved from the manifest signature distribution module VERT.

[0050] After the administrative unit (MD) receives the update instruction with the update package, a rollback process reads the existing Manifest 2 of the computing unit (RE) to be updated and retrieves the corresponding signature from the manifest signature distribution module (VERT). To save bandwidth, only the manifest hash of Manifest 2 is sent to the VERT manifest signature distribution module. If the update is successful, however, the reference from the previous step is resolved to obtain the manifest signature (SIGN) and manifest certificate (M-ZERT) for the software update to be installed.

[0051] The administrative unit MD stores the expiry date associated with the obtained signatures SIGN. Well in advance of the expiry of the signatures SIGN, a new manifest signature SIGN and a new manifest certificate M-ZERT are obtained via the references.

[0052] The administrative unit MD now has all the necessary information to perform the software update and the subsequent key exchange. The software update will begin.

[0053] After a successful software update, the key generation process described above is executed. Based on the information transferred to vehicle 8, the currently required cryptographic keys 6 can now be generated, or, in the event of a rollback, the previously used cryptographic keys 6 can be restored. The procedure executed by information technology system 1 allows for a simple and error-resistant update process, particularly when updating the software of a computing unit RE. Inconsistencies between the key list and the software in vehicle 8 are avoided.

Claims

[1] Information technology system (1) for introducing cryptographic keys (6) into computing units (RE) in a vehicle (8), wherein a pair of communicating computing units (RE) use the same cryptographic key (6) for encrypting and decrypting messages in the course of symmetric encryption, wherein: - a central computing unit (7) comprising a communication database module (COM-DB), wherein a communication database managed by the communication database module (COM-DB) represents the communication structure in the vehicle (8), and wherein the communication database module (COM-DB) is configured to generate a manifest (2) for each computing unit (CU), taking into account the communication structure, representing a computer-readable file containing a unique computing unit identifier (3), a list (4) of all message types to be processed by the respective computing unit (CU) during operation, and a unique key ID (5) for each message type; and - an in-vehicle management unit (MD) and an in-vehicle key distribution unit (KDM); wherein - a respective computing unit (CU) is set up to generate the manifest (2) relating to the computing unit (CU) based on a control unit-specific communication database maintained locally in the computing unit (CU); - the administrative unit (MD) is set up to receive the manifest (2) generated by the computing unit (RE) and forward it to the key distribution unit (KDM); - the key distribution unit (KDM) is configured to receive and read the manifest (2) assigned to the computing unit (RE) and to generate a key hash for each message type contained in the manifest (2) by applying a predefined hash function to a concatenation of the key ID (5) assigned to the respective message type and a random value generated by the key distribution unit (KDM) and to send the key hashes back to the affected computing unit (RE) via the management unit (MD) in a cryptographically secured manner; wherein - the computing unit (CU) is further equipped to receive and store the key hashes and to use at least a predetermined part of each key hash as a cryptographic key (6) for message-type-specific encryption and decryption of the messages. [2] Information technology system (1) according to claim 1, characterized bya manifest signature distribution module (VERT) and a public key infrastructure (PKI-CA) configured to generate a manifest certificate (M-CERT) for each manifest (2), a compute unit certificate (RE-CERT) for each compute unit (RE), and a key distribution facility certificate (KDM-CERT) for the key distribution facility (KDM), and to send the manifest certificates (M-CERT) to the manifest signature distribution module (VERT) for retrieval by the management facility (MD), to send the compute unit certificates (RE-CERT) to the respective compute unit (RE), and to send the key distribution facility certificate (KDM-CERT) to the key distribution facility (KDM), wherein the respective compute units (RE), the management facility (MD), and the key distribution facility (KDM) are configured to perform certificate-based authentication and integrity checks. [3] Information technology system (1) according to claim 1 or 2, characterized bya manifest signature distribution module (VERT) which is set up to generate a manifest hash by applying a predefined hash function to a respective manifest (2) generated by the communication database module (KOM-DB) and to store this hash for retrieval by the management unit (MD). [4] Information technology system (1) according to any one of claims 1 to 3, characterized by that the respective computing unit (CU) and the key distribution unit (CDM) are set up to secure the communication to be carried out for the exchange of key hashes using the Elliptic Curve Diffie-Hellman method. [5] Information technology system (1) according to any one of claims 1 to 4, characterized by, that at least a subset of the part of a respective key hash not used as a cryptographic key (6) represents a checksum and the management unit (MD) is set up to obtain, in order to verify a successful key distribution by the key distribution unit (KDM) to the computing units (RE), respective pairs of checksum and key ID (5) from each computing unit (RE) for each message type and to compare the checksums of the same key IDs (5) obtained from different computing units (RE). [6] Information technology system (1) according to any one of claims 1 to 5, characterized by , that the key distribution device (KDM) and respective computing units (RE) are set up to store the key hashes sorted according to the associated key ID (5). [7] Information technology system (1) according to any one of claims 1 to 6, characterized by, that the key distribution device (KDM) is further configured to receive a key list, wherein key IDs (5) can be stored in the key list, to compare the key list with the manifest (2) of the computing unit (RE) and, in the case of an empty key list, to generate key hashes for all key IDs (5) contained in the manifest (2) and, in the case of a key list containing entries, to generate key hashes only for the key IDs (5) contained in the key list and in the manifest (2). [8] Information technology system (1) according to any one of claims 2 to 7, characterized by, that the manifest signature distribution module (VERT) contains tuples generated from a versioned communication database consisting of a versioned manifest (2) with an associated versioned manifest certificate (M-ZERT), and that the management unit (MD) is set up to obtain the corresponding manifest (2) from the manifest signature distribution module (VERT) and send it to the key distribution unit (KDM), taking into account a target version. [9] Information technology system (1) according to any one of claims 1 to 8, characterized by , that at least part of the communication in the vehicle (8) is based on AUTOSAR PDUs. [10] Information technology system (1) according to claim 9, characterized by that the administrative body (MD) is a diagnostic tester. [11] Information technology system (1) according to any one of claims 2 to 10, characterized bythat the Public Key Infrastructure (PKI-CA) is set up to execute the manifest certificate (M-ZERT) on a vehicle-specific basis.

Images