Method for protected communication of a vehicle

Abstract

Method for secure communication of a vehicle (14), comprising the steps: - Generating a key pair (22) consisting of a private key and a public key and / or one or more symmetric keys for the vehicle (14) or for a control unit (28, 30, 32) of the vehicle (14) within the vehicle manufacturer's sphere of influence, - Generating an initial certificate (24) using the key pair (22), - Inserting the key pair (22) and the first certificate (24) and / or the symmetrical key(s) into the vehicle (14) or the control unit (28, 30, 32), - Authenticating the vehicle (14) or the control unit (28, 30, 32) to a new communication partner (38, 40) by generating a new key pair (50) for this communication path and sending a signed message together with the certificate (24), wherein a master key (58) is generated within the vehicle manufacturer's sphere of influence and all keys used in vehicles are generated by deterministic derivation from the master key (58), and - Authenticating the new communication partner (38, 40) to the vehicle or control unit (28, 30, 32) with a signed message and a public key created by the new communication partner based on certification by the vehicle manufacturer.

Description

[0001] The invention relates to a method for secure communication of a vehicle.

[0002] For an increasing number of vehicle functions that require cryptographic protection, cryptographic key material must be provided for each of these functions. For current functions, either standalone solutions are developed or existing systems are used that are not ideally suited for this purpose.

[0003] DE 100 08 973 A1 discloses a method for ensuring the data integrity of software for a motor vehicle control unit, in which software to be installed into the control unit is authenticated by means of a control unit key pair and certificates.

[0004] DE 10 2009 038 035 A1 discloses a method for configuring infotainment applications in a motor vehicle by changing the software scope.

[0005] DE 10 2009 037 193 A1 discloses a method for carrying out an exchange of an asymmetric key between a vehicle and a remote facility, wherein a public key generated by the vehicle and descriptive data are stored at a location that the remote facility can access.

[0006] DE 10 2010 005 422 A1 relates to a method for establishing a secure connection with a mobile device configured to store a first private key that is mathematically equivalent to a first public key. DE 10 2007 058 975 A1 relates to an on-board network system of a motor vehicle with control units that communicate with each other via a data bus. To detect tampering with the on-board network of a motor vehicle and to derive suitable measures, a master security module is provided in a first control unit and a client security module is provided in a plurality of the further second control units, wherein the master security module of the first control unit signs a message and sends the signed message to at least one of the second control units via the data bus.

[0007] DE 10 2007 041 177 B4 discloses a method for ETCS online key management for a radio train control system, in which entity-specific authentication keys are used for establishing each new radio connection between the entities trackside control center (RBC) and ETCS vehicle, which are transmitted from a key center to the entities via a data connection.

[0008] The above-mentioned methods authenticate the software to be installed, but not the establishment of authenticated communication.

[0009] The invention is based on the objective of providing a secure key insertion system and key management system.

[0010] This problem is solved by a method according to claim 1.

[0011] The inventive method for protected communication of a vehicle comprises the following steps: - Generating a key pair consisting of a private key and a public key and / or one or more symmetrical keys for the vehicle or for a control unit of the vehicle within the vehicle manufacturer's sphere of influence, - Generating an initial certificate using the key pair, - Inserting the key pair and the first certificate and / or the multiple symmetrical keys into the vehicle or the control unit, - Authenticating the vehicle or control unit to a new communication partner by generating a new key pair for this communication channel and sending a signed message along with the certificate, and - Authenticating a new communication partner to the vehicle or control unit with a signed message and a public key created by the new communication partner based on certification by the vehicle manufacturer.

[0012] The invention essentially creates a circle of trust that allows bidirectional communication, meaning communication from the vehicle to another participant and from a participant to the vehicle. The other participant or communication partner can be another vehicle, a fixed location such as the production facility or a server belonging to a workshop or third-party provider, external services and new service providers, or even a control unit within the vehicle.

[0013] According to the invention, a master key is generated within the vehicle manufacturer's sphere of influence, and all keys used in vehicles are generated from this master key by deterministic derivation. This approach simplifies the organization of key management. A simple representation of this master key can be created in a central database. This master key then serves as the basis for deriving all keys for all vehicles or a specific group of vehicles, such as a model or model series from the manufacturer.

[0014] The method according to the invention has the advantage that a key insertion system and key management system are provided, which enables process-reliable key distribution with a uniform application programming interface (API). The use of key material is possible without further communication beyond authentication verification with various control units of the vehicle, even with new, i.e., previously unknown, external participants. The basis of trust originates from the vehicle manufacturer, and the manufacturer has complete control over the trust chains. Thus, the manufacturer directly controls the trust relationships of the vehicles. For the first time, the method therefore allows for a multitude of authentication concepts.

[0015] Within the scope of the invention, asymmetric and symmetric keys can be used. The keys can be used individually or in multiple copies per control unit or vehicle. Even if, for the sake of clarity, only one variant, such as an asymmetric key pair, is mentioned in some places, both variants, i.e., asymmetric and symmetric keys, are always included. The signed message to the new communication partner, or to the vehicle or control unit, can be signed with a signature or a certificate. The signature enables verification that the message was sent by an authentic sender.

[0016] The key insertion and management system can advantageously support various applications, such as secure communication within the vehicle. Only by using different keys for the cryptographic authentication of messages on the vehicle's internal bus can authentic differentiation between communication participants be achieved. Adhering to the classic requirements of cryptography (security is based on keys), it is ensured that a control unit, which is a participant in the trusted circle and secure communication but is not in the same trusted group as other control units, cannot derive the key material necessary to impersonate a participant in that other trusted group.

[0017] Mobile online services are also supported by the method according to the invention. Often, these mobile online services are subsequently connected to the vehicle manufacturer's backend systems, for example, via existing systems. While this approach fulfills all security-relevant requirements, it repurposes the existing systems, which can have negative consequences for them. This disadvantage is eliminated with a dedicated PKI, in which the vehicles are the participants. A particular advantage is that the vehicles can be authenticated upon initial contact with a backend or unit for mobile online services, even before being forwarded to internal IT systems.

[0018] Similarly, authentication of communication services or networks such as Car2X or vehicle to grid can be implemented.

[0019] Further future use cases are characterized by the need for vehicle systems to authenticate themselves to external communication partners. Asymmetric cryptography is suitable for such use cases because cryptographic operations can be performed between participants without prior dedicated key exchange due to the public key components. A Public Key Infrastructure (PKI) further enables participants to trust the corresponding public keys. Currently available methods do not allow for the introduction of asymmetric keys, nor do they allow for the integration of vehicles into a PKI and secure communication with external participants.

[0020] There are use cases for mobile devices where initial pairing is not possible from inside the vehicle (with additional out-of-band user confirmation), as is currently the case. One such example is key handover to smartphones for car sharing. Without confirmation of the pairing process on both the vehicle and the mobile phone, the transmitted or agreed-upon keys are not authentic and therefore vulnerable to man-in-the-middle attacks. The PKI presented here addresses this issue by ensuring that security does not rely on the authenticity of the technology-specific pairing mechanism, but rather on an overarching, secure connection between participants based on the certificates of the trusted network.

[0021] Even when connecting future external services or apps, there are several use cases that are only possible with the method according to the invention. For apps and services that are not operated from the company's own backend, an authentic connection with appropriate authentication mechanisms (e.g., OAuth) is necessary. Depending on the criticality of the services, end-to-end security is required for services hosted by the vehicle manufacturer itself. Here, the presented key insertion and key management system offers great flexibility and scalability.

[0022] The method according to the invention offers centrally controlled control unit authentication. This is particularly advantageous when control units from external manufacturers, such as infotainment systems from other manufacturers, need to be identified. This is made possible by the use of the protected communication within the vehicle presented here, based on independent keys from the trusted circle. Here, other devices detect that a participant is not authentic, instead of the participant itself detecting that it is in the wrong vehicle.

[0023] According to this method, the vehicle, or rather one of its control units, functions as its own certification authority within a Public Key Infrastructure (PKI). This is particularly advantageous when an online connection is not always and everywhere available. This applies to all mobile devices that are not originally designed to establish an online connection.

[0024] A key record can be used to input the key pair, the symmetric key, and the certificate. This allows for a standardized interface for input, which simplifies the process. The process is not limited to the use of asymmetric keys; symmetric keys can also be used. The key record can include all of the aforementioned components or only some of them.

[0025] The key data record can contain information regarding an identification number of the vehicle and / or control unit and / or the key type. The identification number can be, for example, the vehicle identification number (VIN or FIN). The vehicle and / or the control unit, or other participants, are configured using encrypted and signed key data records. Beyond its cryptographic key material, the control unit can then obtain information about the encryption network in which it is integrated, as well as metadata about its keys for the application using them, if required.

[0026] During the manufacturing of a vehicle's control unit, an initial key can be stored within the unit. This initial key can be invalidated by the key pair and / or the symmetrical key. The initial key is stored in the control unit during or after manufacturing, thus extending the security and authentication scope to components before they are installed in the vehicle. This further enhances security. The initial key can also be deleted.

[0027] A key for functions that span multiple control units can be generated and implemented in several of the vehicle's control units. Since such a group key can operate a group of control units, the number of keys and the overall effort can be reduced. For example, a navigation control unit and a GPS control unit can be assigned to the same group key, allowing both to be addressed using this group key when a GPS navigation function is activated.

[0028] Multiple key pairs and / or keys can be integrated into a vehicle's control unit. This allows for an expansion of the encryption's functionality. For example, one key can be used for a single control unit, one key for functions across multiple control units, and one or more communication keys. Each key or key pair is assigned a specific area of ​​application and / or a particular group of users or communication channels.

[0029] The new communication partner can be another control unit in the vehicle or an external device. For example, the vehicle may have a master-slave configuration in which one control unit assumes the master role with regard to encryption and encrypted communication, while other control units assume slave roles. The external device could be, for example, another vehicle, a workshop, or a service provider's server. The generally applicable procedure can work with any communication partner that is reachable via a wired or wireless communication channel, such as a mobile network connection, and is configured to communicate using encryption, for example, asymmetric encryption.

[0030] The vehicle manufacturer's sphere of influence can encompass a vehicle production site and / or the manufacturer's backend. The term "sphere of influence" can be interpreted in terms of security and not solely geographically. For example, keys, certificates, and download containers that are installed in the vehicle at the production site can be created securely in a backend. Key generation can also occur directly in the vehicle during production.

[0031] A manufacturer's root certificate can be installed in the vehicle and sent to the new communication partner. The root certificate can then be used to validate the validity of all subordinate certificates. It serves as the common trust anchor for all certificates under its control. This approach enables the implementation of a fully hierarchical Public Key Infrastructure (PKI).

[0032] A vehicle manufacturer's certification authority can generate a manufacturer's certificate and transmit it to the new communication partner. The new communication partner can then verify the second certificate received from the vehicle against the root certificate, the manufacturer's certificate, the certificate itself, and the message signature. This allows for the verification of the entire certification chain and provides significant flexibility in key creation and management.

[0033] When generating a key pair and / or a symmetrical key for the vehicle or for a vehicle control unit, a serial number for the vehicle and / or the control unit can be stored within the vehicle manufacturer's sphere of influence. Such recording or storage of the serial number in a database or backend system facilitates the organization of the trusted third party.

[0034] When a key pair and / or key is requested again, if the serial number of the vehicle or control unit does not match the stored serial number, a key identity counter for the key pair can be incremented before a new key pair and / or key is calculated and transferred to the vehicle or control unit. All other system participants in the encryption network that contain these keys will also receive corresponding key pairs or key data records containing these new keys. In this way, keys or key pairs can be replaced easily and securely, ensuring the process security of the keys throughout their entire lifecycle.

[0035] The vehicle or control unit can only accept the new key pair and / or key if the included key identity counter is greater than or equal to the currently stored key identity counter. This security check allows for simple and effective implementation of the key identity counter and increases process reliability. Another option is to replace all keys or key pairs.

[0036] Further preferred embodiments of the invention result from the other features mentioned in the dependent claims.

[0037] Unless otherwise stated in individual cases, the various embodiments of the invention mentioned in this application can be advantageously combined with one another.

[0038] The invention is explained below using exemplary embodiments with reference to the accompanying drawings. These show: Fig. 1 a schematic representation of a PKl trust circle; Fig. 2. A schematic overview of the keys brought in; and Fig. 3 A schematic representation of key functions in control units.

[0039] Fig. Figure 1 shows a schematic representation of a PKI trust circle 10, which can also be referred to as a vehicle key management system. A root certificate authority (CA) 12 serves as the trust anchor for the entire public key infrastructure (PKI). The root certificate authority 12 is located within the responsibility of the vehicle manufacturer 14, for example, in a data center. Several sub-CAs exist, which issue certificates for the various use cases. For example, a vehicle CA 16 signs the certificates for the asymmetric vehicle identities. The entire PKI 10 comprises the common root CA 12 and several sub-CAs for dedicated use cases. Furthermore, all issued certificates belong to the PKI 10.

[0040] A key database 18 is used to generate, store, manage, and provide new keys or key pairs. The key database 18 can be integrated into the manufacturer's existing database systems. It is also possible to outsource key management to an affiliated or contracted company.

[0041] In a backend unit 20, such as a computing unit or data center, the keys or key pairs 22 are derived, combined with the certificates 24, and made available as a key data record 26. The units Root CA 12, Vehicle CA 16, Key Database 18, and Backend Unit 20 can also be combined into a single unit or a few units. They are shown separately here for logical separation. All units described so far are logically located prior to the production of the vehicles 14; this is commonly referred to as the backend. A backend of a telematics service provider, for example, can also be considered a backend.

[0042] The central backend generates the required cryptographic keys 22 for a vehicle 14 and its control units 28, 30, 32 upon request. For initial configuration, the backend receives both the vehicle identification number (VIN) of vehicle 14 and a list of the control units 28, 30, 32 to be configured, as well as the keys to be provided. After key generation, this data is stored in the key database 18 for later reference.

[0043] The backend provides interfaces for both initial data entry processes during the production of vehicle 14 and subsequent data entry processes during field operation. The latter interface is particularly necessary for exchange and spare parts processes.

[0044] The vehicle CA 16, as part of the PKI 10, provides individual control units with signed certificates 24 based on the key material. These certificates can be used to identify the vehicle 14, or its control units 28, 30, 32, to other entities. The PKI 10 contains at least the following entities: The root CA 12 serves as the trust base; other function-dependent CAs, such as the vehicle CA 16 or a CA for mobile online services 34 to support mobile online services, are present; and a bridge or interface 36 serves as an interface for external participants 38. The bridge or interface 36 is used to sign the certificates of the external participants 38 from the manufacturer's PKI 10, thus enabling authentication of the external services 38 to the vehicle 14.

[0045] At least one internal service provider 40 for providing internal services is also part of the PKI or the circle of trust 10. "Internal" here means that the vehicle manufacturer 14 offers these services, such as mobile online services. This internal service provider 40 is connected to the root CA 12 via the CA for mobile online services 34.

[0046] Since the internal and external services, as well as vehicle 14 with its control units 28, 30, and 32, each possess a complete certification path to the root CA 12, the vehicle can authenticate itself to the internal and external services using asymmetric cryptographic methods. Likewise, the internal and external services can authenticate themselves to vehicle 14 and its control units 28, 30, and 32. This is in Fig. 1 is represented by the bidirectional connections 42 and 44 between the vehicle 14 and the external participant 38, as well as the internal service provider 40. Thus, the PKI as a whole has a circle of trust 10, which can always be traced back to the root CA 12.

[0047] Based on Fig. Section 2 below describes the key hierarchy and key derivation. The generation of cryptographic keys for a participant in the trust circle generally distinguishes between two types of keys: keys that are unique to each electronic control unit (ECU) and keys that are distributed among multiple ECUs within a vehicle. In this description, an ECU is used to represent a participant in the trust circle. Other vehicle components, such as other processing units, can also be used.

[0048] The following describes the fundamental keys of the trust circle. Several keys are shown that are assigned to, or have been assigned to, individual control units 20, 30, and 32 of the vehicle. In this example, control unit 32 serves as the master control unit for communication and / or encryption. The master control unit can act as the vehicle's internal CA for signing asymmetric keys for other control units in the vehicle or as a time master for a CAN bus. It is also possible for each control unit to act as its own internal CA.

[0049] The initial key 56 is the key of a participant in the trusted circle, provided by the supplier or manufacturer of the control unit or participant. This initial key 56 is used to encrypt and sign the key data record during the initial configuration of the control unit. It can be replaced during the configuration process by a key specific to that control unit. This new key can then be used to encrypt and sign all subsequent key data records and for other administrative functions related to the control unit within the trusted circle.

[0050] The data entry by the supplier takes place in a protected environment, thus preventing the initial key 56 from becoming known.

[0051] From the vehicle manufacturer's perspective, a base key 58 is first generated. This base key 58 is derived and stored in database 18. All other keys for all vehicles or a group of vehicles are derived from this base key 58.

[0052] A master communication key 60 is derived from the base key 58. It serves to equip both the master and slave in a master-slave network with shared keys, enabling them to communicate securely with each other.

[0053] For this purpose, further communication keys for control units 62 are derived from the master communication key 60 and distributed to the slaves 28, 30.

[0054] From the base key 58, further keys for control units 64 are generated. Each such key 64 is known only to that one control unit in the vehicle. Every function that requires such a key receives its own key 64.

[0055] Keys for cross-unit functions 66 are generated from the base key 58. These keys 66 are derived from the vehicle identification number (VIN) or vehicle identification number (FIN) of the trusted network. Unlike keys for control units 64, a cross-unit key 66 is distributed to multiple participants, thus enabling distributed functions to access the same key material. The cross-unit key 66 can therefore be used, for example, for function-related secure communication within the vehicle.

[0056] All data entry processes are recorded in the backend, specifically in database 18, and are therefore traceable. The backend maintains a history of the installed components for each vehicle, containing all the information necessary to generate the keys associated with each component. Data entry processes include both initial data entry and multiple data entry, meaning the re-data entry of a component that has already been entered. Multiple data entry is necessary, for example, if an already entered control unit is to be replaced in a different group of components, or if a component's key needs to be replaced.

[0057] The authentication of participants within the trusted network is carried out using encrypted and signed key data sets. Beyond its cryptographic key material, the control unit receives information about the network in which it is installed, as well as optional metadata about its keys for the application using them, if required.

[0058] To create a network or trust group, the backend is informed which assemblies or control unit classes are participating in the network, which functionality is to be provided in the form of key material, how the corresponding derivation paths are organized, and what the vehicle identification number (VIN) or vehicle identification number (FIN) of the target vehicle is. Only then can the backend derive the necessary keys and provide them to the relevant participants in the form of key data records. The network configuration is stored in the backend. Requests for key data records for a control unit class or for keys that have not been reported as part of the network are rejected.

[0059] The terms "assemblies" and "control unit classes" are used here as examples of possible participants in PKI Trust Circle 10. Other possible participants include individual components, control units, or other elements and component groups. A control unit class, for example, is a class for navigation control units. This class would then include, for example, several or all navigation control units, which could be of different designs.

[0060] After a vehicle assembly is created, no control units are yet assigned to it; only control unit classes that will be part of the assembly are assigned. When a key data record is requested for a module for which no control unit has yet been registered—that is, an initial request—the necessary keys are generated in the backend based on the data stored there. The control unit for which the request was made is then registered as belonging to the assembly with its serial number.

[0061] Modifying a control unit group involves replacing an existing member of the group with a different control unit. When a key record is requested for a control unit class for which a control unit has already been registered as belonging to the group, and the serial number does not match the registered serial number, a replacement process is initiated. Before calculating the new keys to be transferred to the control unit, the key identity counters of all keys that the control unit will receive and that need to be replaced are incremented by 1. This indicates that the key needs to be replaced and allows for its assignment to the currently used key. It is guaranteed that the keys of the old member are no longer valid in the vehicle.All other participants in the consortium that contain these keys must also receive corresponding key records containing these new keys.

[0062] When a key record is entered for a key, the control unit only accepts this key record if the contained key identity counter is greater than or equal to the currently stored key learning counter.

[0063] As part of the data acquisition process, a participant can receive a signed certificate that serves this control unit either as an internal sub-CA or can be used directly as an identification feature. This certificate was signed by the backend as a vehicle identity CA.

[0064] In Fig.Figure 3 shows control units 28, 30, and 32, as well as the functions of their keys. Control unit 32 is a master control unit and therefore contains a master communication key 60. Two keys or key pairs, 46 and 48, are generated from the master communication key 60 for communication with control units 28 and 30. In this way, control unit 32 and control unit 28 can communicate with each other using key 48 and the communication key 62 of control unit 28. Similarly, control unit 32 and control unit 30 can communicate with each other using key 46 and the communication key 62 of control unit 30.

[0065] A key for cross-control-unit functions 66 allows all three control units 28, 30, and 32 in a group 68 to communicate securely with each other, and another key for cross-control-unit functions 66 allows the two control units 28 and 30 in a group 70 to communicate securely with each other. As can be seen, there are several keys or key pairs for different functions and / or communication circuits per control unit.

[0066] Control units 28, 30 and 32 show further examples of key functions, here of keys for a control unit 64.

[0067] In control unit 32, for example, an asymmetric ECC key pair 50 is generated from the individual key 64. Methods based on elliptic curves are called ECC methods (Elliptic Curve Cryptography) and allow for faster and more efficient cryptographic methods than the simple Diffie-Hellman method. The master control unit 32 can therefore generate further key pairs from its individual key 64 for other tasks, even those unknown when the control unit is programmed.

[0068] In control unit 28, for example, incoming encrypted data is decrypted using the key 64, which is unique to this control unit 28, and made usable for the control unit 28. This data can include instructions or messages from the backend, a key data set, or other information.

[0069] In control unit 30, 64 additional keys 54 are generated from the key 64 that is unique to this control unit 30. Thus, it is evident that a slave control unit 28, 30 can also generate new keys or key pairs from its respective unique key 64.

[0070] The advantage is that all keys in the vehicle are deterministic and can therefore be traced by the backend. Reference symbol list 10 PKI Trust Circle 12 Root CA 14 vehicles 16 Vehicle CA 18 key database 20 Backend Unit 22 keys 24 Certificate 26 Key data set 28 Control unit 30 Control unit 32 Control unit 34 CA for mobile online services 36 Bridge 38 external participants 40 internal service providers 42 connection 44 connection 46 keys 48 keys 50 asymmetric ECC key pairs 52 encrypted data 54 more keys 56 initial key 58 master keys 60 master communication keys 62 communication keys 64 keys for a control unit 66 keys for cross-control unit functions Group 68 Group 70

Claims

[1] Method for secure communication of a vehicle (14), comprising the steps: - Generating a key pair (22) consisting of a private key and a public key and / or one or more symmetric keys for the vehicle (14) or for a control unit (28, 30, 32) of the vehicle (14) within the sphere of influence of the vehicle manufacturer, - Generating an initial certificate (24) using the key pair (22), - Inserting the key pair (22) and the first certificate (24) and / or the symmetrical key(s) into the vehicle (14) or the control unit (28, 30, 32), - Authenticating the vehicle (14) or the control unit (28, 30, 32) to a new communication partner (38, 40) by generating a new key pair (50) for this communication path and sending a signed message together with the certificate (24), wherein a master key (58) is generated within the vehicle manufacturer's sphere of influence and all keys used in vehicles are generated by deterministic derivation from the master key (58), and - Authenticating the new communication partner (38, 40) to the vehicle or control unit (28, 30, 32) with a signed message and a public key created by the new communication partner based on certification by the vehicle manufacturer. [2] Method according to any one of the preceding claims, characterized by, that a key record (26) is used to introduce the key pair (22), the symmetric keys and the certificate (24). [3] Method according to claim 2, characterized by , that the key data set (26) contains information relating to an identification number of the vehicle (14) and / or control unit (28, 30, 32) and / or the key type. [4] Method according to any one of the preceding claims, characterized by , that during the manufacture of a control unit (28, 30, 32) of the vehicle (14) an initial key (56) is stored in the control unit (28, 30, 32) and that the initial key (56) is rendered invalid by the key pair and / or the symmetrical key. [5] Method according to any one of the preceding claims, characterized by , that a key for cross-control unit functions is generated and introduced into several control units (28, 30, 32) of the vehicle (14). [6] Method according to any one of the preceding claims, characterized by , that several key pairs and / or symmetrical keys are inserted into a control unit (28, 30, 32) of the vehicle (14). [7] Method according to any one of the preceding claims, characterized by , that the new communication partner is another control unit (28, 30, 32) in the vehicle (14) or an external device to the vehicle (38, 40). [8] Method according to any one of the preceding claims, characterized by , that the vehicle manufacturer's sphere of influence includes a production site of the vehicle (14) and / or a backend of the manufacturer. [9] Method according to any one of the preceding claims, characterized by , that a manufacturer's root certificate is installed in the vehicle and that the root certificate is sent to the new communication partner (38, 40). [10] Method according to claim 9, characterized by, that a certification authority of the vehicle manufacturer generates a manufacturer certificate and transmits it to the new communication partner (38, 40) and that the new communication partner (38, 40) verifies the certificate received from the vehicle (14) with the root certificate, the manufacturer certificate, the certificate and the signature of the message. [11] Method according to any one of the preceding claims, characterized by , that when the key pair (22) and / or the symmetrical key for the vehicle (14) or for a control unit (28, 30, 32) of the vehicle (14) is generated, a serial number of the vehicle (14) and / or the control unit (28, 30, 32) is stored within the sphere of influence of the vehicle manufacturer. [12] Method according to claim 11, characterized by, that if a new request for a key pair and / or key is made, and a serial number of the vehicle (14) or the control unit (28, 30, 32) does not match the stored serial number, before calculating a new key pair and / or key to be transferred to the vehicle (14) or to the control unit (28, 30, 32), a key identity counter of the key pair and / or key is incremented and a new key is generated. [13] Method according to claim 12, characterized by , that the vehicle (14) or the control unit (28, 30, 32) will only accept the new key pair and / or key if the included key identity counter is greater than or equal to the currently stored key identity counter.

Images