Method for equipping a vehicle with a unique certificate

Abstract

The invention relates to a method for securely equipping a vehicle (1) with a dedicated certificate, wherein the vehicle (1) has at least one control device (2) and a communication unit configured to establish communication between the at least one control device (2) and an off-board server (3) as required. The invention is characterized in that a vehicle certification authority (FCA) and a control device certification authority (GCA) with corresponding public key infrastructures are each established based on an asymmetric key pair (FzgRootPub, FzgRootPriv; GerRootPub, GerRootPriv), wherein the corresponding private key (FzgRootPriv; GerRootPriv) is retained in the corresponding certification authority (FCA; GCA) and the corresponding public key (FzgRootPub; GRootPub) is distributed to users who need it. The control unit (2) is provided with initial cryptographic material in the following manner: a control unit-specific key pair (GerIndPub, GerIndPriv) is generated for the control unit (2), and the identity (GerID) of the control unit and its public key (GerIndPub) are transmitted to a control unit certification authority (GCA). There, a control unit-specific certificate (GerIndCert) is subsequently generated for the transmitted data (GerID, GerIndPub) using the private key (GerRootPriv) of the control unit certification authority (GCA) and transmitted back to the control unit (2). In addition, the public key (FzgRootPub) of the vehicle certification authority (FCA) is stored in the control unit (2) in a tamper-proof manner. The vehicle identity (FzgID) associated with the identity (GerID) of the control unit (2) is determined and stored in a tamper-proof manner.

Description

Technical Field

[0001] The present invention relates to a method for securely equipping a vehicle with an exclusive certificate, wherein the vehicle has at least one control device and a communication unit, which is configured to establish communication between at least one control device and an off-vehicle server as needed, wherein the control device and the off-vehicle server implement an asymmetric encryption mechanism for security authentication. Background Art

[0002] Modern vehicles are characterized by an increasing degree of networking. These vehicles are connected not only to systems such as the World Wide Web, but also to systems and servers operated by the vehicle manufacturer or OEM, such as the manufacturer's own applications and servers, often referred to as the vehicle backend. These are developed, marketed, and operated solely by the manufacturer for its own fleet. This collective term is also referred to as the vehicle ecosystem.

[0003] In practice, the diverse communication relationships between the various system components within this vehicle ecosystem create numerous new interfaces and applications, all of which must be protected by suitable cryptographic methods, such as mechanisms, protocols, etc. This protection serves, on the one hand, to maintain the privacy of vehicle users and, on the other hand, to prevent external access to data communications, which, in particular when transmitting data related to vehicle control, could be used by hackers to attack the vehicle and manipulate critical functions.

[0004] It's clear here that the vehicle itself cannot communicate with an off-board server or backend. In practice, several individual control devices are always installed in the vehicle, which establish or maintain connections with the backend. However, from the backend's perspective, it primarily identifies the vehicle as a whole, not the individual control devices installed within it. Therefore, for the backend, it's more important to reliably know in which vehicle the control device with which it's communicating is installed, rather than knowing exactly which control device it is without being able to identify the associated vehicle.

[0005] Both standard methods (TLS, IPSec) are based on asymmetric cryptography, specifically asymmetric private keys and certificates for the associated public keys issued by a trusted central authority (Certification Authority (CA)). The following requirements are necessary for secure communication between the vehicle and the backend:

[0006] The certificates used by the vehicle or its control devices must be unique, i.e. each vehicle must have at least one private key of its own, and

[0007] The relevant certificates must be issued by a trusted central certification authority (CA) within the vehicle ecosystem

[0008] Based on a unique vehicle identity, for example based on the vehicle identification number (VIN), also known as the vehicle frame number

[0009] Vehicle Identification Number).

[0010] Ideally, the private key should be generated together with the associated public key in a secure hardware area (e.g., a hardware security module / HSM) of the control unit in the vehicle to which the certificate is assigned, and should never leave the secure area of ​​the control unit. This ensures that the private key is virtually untraceable to an intruder.

[0011] One conceivable solution is to assign the manufacturer of the control device that is to have its own private key the task of generating a vehicle-specific key pair in the control device during its manufacture. The public key can then be read from the control device and a certificate generated for this purpose, while the private key remains unreadable and remains in the control device for its entire service life. However, this approach is problematic for two reasons.

[0012] First, the identity of the vehicle for which the certificate is to be issued is not known at the time the control device is manufactured, since it is not known at that time in which vehicle, or in which vehicle, the control device will later be installed at the OEM. Second, the control device is often manufactured by a company different from the OEM. However, the vehicle-specific certificate used to protect communication between the vehicle and the OEM's own backend or other users of the OEM's vehicle ecosystem should be issued by the OEM itself, not by the control device manufacturer, to further prevent the potential misuse of the certificate issued by the control device manufacturer. While it is theoretically possible to securely tie the OEM's own certification authority (CA) to the control device manufacturer's production line, this is a cost-intensive solution.

[0013] The applicant's publication DE 10 2009 009 310 A1 discloses a method for enabling secure communication between a user device equipped with a vehicle control unit and a remotely located backend via a publicly accessible network using digital certificates. The method comprises the following steps: the backend generates a non-proprietary certificate and sends it to the control unit; the control unit receives and stores the non-proprietary certificate; and then establishes initial communication between the control unit and the backend using the non-proprietary certificate as an identifier. The backend only accepts the initial communication if the identifier is the non-proprietary certificate. Finally, the backend requests vehicle identification information, which is sent back from the control unit to the backend. The backend then generates a proprietary certificate based on the identification information and sends it to the control unit, where it is received and stored. Encrypted working communication can then be established.

[0014] The method proposed in DE 10 2009 009 310 A1 suffers from several drawbacks stemming from its principle. First, the issuing authority generates not only a unique vehicle certificate but also a vehicle-specific key pair for which the certificate is issued. This includes, in particular, the vehicle-specific private key. Therefore, the vehicle-specific private key is not only available to the control unit or vehicle for which it is intended but is also known at least to the issuing authority that generated it. Second, the key and certificate must be transmitted from the issuing authority to the vehicle via relatively insecure communication. This is because the vehicle does not yet possess a secure unique certificate. Furthermore, the issuing authority cannot always ensure that it has actually transmitted the newly generated vehicle-specific certificate, and in particular the unique private key that warrants protection, to a vehicle with the correct identity. Conversely, an unauthorized third party merely impersonating that identity could also be the requester or recipient of the certificate, since the vehicle-specific certificate does not yet exist and, therefore, the requester or recipient has not yet been securely authenticated. Summary of the Invention

[0015] It is therefore an object of the present invention to provide an improved method for securely equipping a vehicle with an individual certificate, which method makes the prerequisites and the process more secure.

[0016] According to the invention, this object is achieved by a method having the features described below. Advantageous embodiments and improvements of the method are also described below.

[0017] As mentioned above, at the time of manufacture of a control device, which is to have a vehicle-specific certificate and, in particular, a vehicle-specific key, a certificate for the vehicle's identity cannot be issued because the vehicle's identity is not yet known. In the method according to the present invention, a certificate for the control device's identity is therefore issued at this time. This can be, for example, an unambiguous and forgery-proof certificate for the control device, which is write-protected, for example, if a hardware security module (HSM) is installed. The private key associated with the vehicle-specific certificate is then to be securely stored in the hardware security module.

[0018] To achieve this, the method according to the present invention creates a separate certification authority (CA) based on asymmetric key pairs for the vehicle and the control unit, each of which has a public key infrastructure (PKI). The corresponding private key of the certification authority is stored in the respective certification authority, while the public key is distributed to users who require it. For example, an off-board server designed as a backend is associated with this.

[0019] The control device can now be equipped with initial cryptographic material, particularly during its manufacture, by generating a control device-specific key pair for the control device and transmitting the control device's identity and its public key to the control device certification office. The control device certification office then generates a control device-specific certificate for the transmitted data using the control device certification office's private key and enters the control device. The vehicle certification office's public key is stored in the control device in a tamper-proof manner, and the vehicle identity associated with the control device's identity is ascertained and stored in a tamper-proof manner. This system can thus be prepared for requesting and issuing certificates in a highly secure and efficient manner. A vehicle, or more precisely, a specific, suitable control device installed in a vehicle, can be securely equipped with a vehicle-specific certificate issued based on the vehicle's identity.

[0020] According to a particularly advantageous embodiment of the method according to the invention, the control device type can also be transmitted to the control device certification authority. It is therefore proposed to add the control device type associated with the control device (e.g., head unit (HU), telematic communication unit (TCU), rear seat unit (RSU), etc.) to the control device-specific certificate, provided that this type cannot be derived from the identity of the control device.

[0021] Furthermore, a corresponding advantageous development provides that the identity of the control unit is entered as part of the subject in the control unit-specific certificate, and the control unit type is entered in an additional field of the certificate, a so-called certificate extension. This allows multiple control units installed in the same vehicle to be issued their own vehicle-specific certificates, and these different vehicle-specific certificates can be kept separate from one another as required.

[0022] In order to determine the vehicle identity associated with the identity of the control unit, a particularly advantageous embodiment of the method according to the present invention can provide for a data packet consisting of the vehicle identity and the identity of the control unit to be collected in a forgery-proof manner when the control unit is installed in the vehicle and subsequently transmitted in a tamper-proof manner to an off-board server, which stores the data packet in a tamper-proof manner. Furthermore, according to an advantageous refinement of this concept, the data packet can also include the type of the control unit.

[0023] The device-specific private key and the device-specific certificate can then be used by the control unit during operation in order to transmit, in accordance with an extremely important and advantageous development of the method according to the invention, a certificate signing request (CSR: Certificate Signing Request) containing the vehicle-specific public key as part of a vehicle-specific key pair generated by the control unit to a certification authority in a tamper-proof manner in order to subsequently obtain a vehicle-specific certificate from there, without the vehicle-specific private key having to leave the control unit.

[0024] To this end, the control unit can specifically ascertain the identity (FzgID) of the vehicle in which it is installed and generate a vehicle-specific key pair for a dedicated vehicle certificate within the control unit's secure environment. The vehicle-specific private key remains in the secure environment. A certificate signing request (CSR) is generated, containing at least the vehicle identity and the vehicle-specific public key, and according to a highly advantageous refinement, the control unit type. Furthermore, a signature is generated by signing the certificate signing request with the control unit's specific private key. The resulting data packet is then sent to an off-board server along with the control unit's specific certificate. This server receives the data packet and verifies the correctness of the received control unit-specific certificate using the public key stored therein by the control unit's issuing authority. The correctness of the data packet signature is then verified using the control unit's public key contained in the accompanying control unit-specific certificate.

[0025] The off-board server then extracts the vehicle identity from the certificate signing request and the control unit identity and, according to one advantageous embodiment, the control unit type from the control unit-specific certificate. The off-board server then checks whether an entry for the data is stored. If one of these checks fails, the process is terminated by the off-board server. Otherwise, the off-board server sends a certificate signing request for the vehicle identity and the vehicle-specific public key via a protected transmission path to the vehicle issuing authority. Based on the certificate signing request, the authority issues a vehicle-specific certificate signed with its private key and transmits it back to the off-board server.

[0026] The off-board server then transmits the vehicle-specific certificate to a control unit installed in the vehicle. The control unit checks the received vehicle-specific certificate by at least checking the correctness of its signature using the public key and further checking whether the received vehicle-specific certificate corresponds to the sent certificate signing request—that is, whether the vehicle identity and vehicle-specific public key in the two data structures are consistent. If the check result is positive, the vehicle-specific certificate is now stored locally. It is therefore available for future communications and can be updated as needed in the manner described.

[0027] The vehicle-specific private key is thus generated within the control unit and never leaves it, a significant advantage and security gain compared to existing technologies. In particular, the vehicle-specific private key does not have to be transmitted from an off-board server or backend to the vehicle via a relatively insecure communication channel. Another advantage is that the off-board server in this method design can reliably assume that the certificate requester is the vehicle for which the certificate is actually to be issued.

[0028] A very advantageous embodiment of this variant of the method according to the invention also provides that the control unit-specific and / or vehicle-specific key pair is generated by the control unit, after which the control unit-specific and / or vehicle-specific private key is securely stored and does not leave the control unit. This ensures high security, particularly if this is done for both key types.

[0029] Preferably, provision can be made here for the corresponding individual key pair to be generated by the control unit in a hardware security module (HSM) and / or at least securely stored there and not to leave the HSM. This also preferably applies here to both key types, but is particularly important for vehicle-specific private keys and offers particular security advantages.

[0030] A particularly advantageous refinement of the method according to the present invention further provides for a unique, forgery-resistant digital vehicle fingerprint to be acquired during vehicle manufacturing, and for a data packet containing the vehicle identity and fingerprint to be transmitted in a tamper-proof manner to an off-board server and stored there in a tamper-proof manner. When generating a certificate signing request, the control device determines its own, control-device-specific vehicle fingerprint by collecting the necessary information in the vehicle and subsequently generating a signature by signing the data packet containing the control-device-specific vehicle fingerprint with a control-device-specific private key. The resulting data packet, expanded with the device-specific vehicle fingerprint, is then transmitted to the off-board server in place of the aforementioned data packet and further processed there. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Further advantageous embodiments of the method according to the invention become apparent from the exemplary embodiments described in detail below with reference to the accompanying drawings.

[0032] The single FIGURE shows a schematic diagram for explaining the method according to the invention. DETAILED DESCRIPTION

[0033] The schematic diagram shows the illustrated vehicle 1 twice, namely once during manufacture with the designation 1' and once during operation with the designation 1". The control device 2 is also shown several times, once during manufacture with the designation 2', once in the vehicle 1' during manufacture with the designation 2", and once again in the vehicle 1" during operation. There, the control device 2 is then designated 2'". Furthermore, an off-board server 3, for example a back-end server of a corresponding OEM, a control device certification office GCA, and a vehicle certification office FCA are shown.

[0034] Now, the following steps are specifically performed, and their paragraph numbers can therefore also be seen in the accompanying drawings:

[0035] A: A vehicle infrastructure for public keys, a so-called public key infrastructure (PKI) for vehicle-specific certificates, is set up. This is done once for each fleet.

[0036] 1. The vehicle certification office or vehicle CA, ie, FCA, generates an asymmetric key pair FzgRootPub, FzgRootPriv, which can also be called a vehicle root key pair.

[0037] 2. The private key FzgRootPriv is stored within the FCA in a secure environment and is used by the FCA to issue / sign the vehicle-specific certificate.

[0038] 3. The public key FzgRootPub is distributed to all systems, such as the backend 3, that should be able to check the certificates issued by the FCA.

[0039] B: Setting up a control device infrastructure (PKI) for control device-specific certificates. This is done once for each control device manufacturer and a certain number of control devices that can be manufactured by the manufacturer.

[0040] 1. For the control device issuing office or control device CA, that is, GCA, an asymmetric key pair GerRootPub and GerRootPriv is generated.

[0041] 2. The private key GerRootPriv is stored in the GCA in a secure environment and is used by the GCA to control the issuance / signing of device-specific certificates.

[0042] 3. The public key GerRootPub is distributed to all systems, such as backends 3, that should be able to check certificates issued by the GCA.

[0043] C: Equip the control device 2 with initial cryptographic data, in particular a control device-specific certificate. This is done once for each control device 2 with a unique identity GerID, type GerTyp, for example, during its manufacture. The control device 2 is denoted by 2' in the figures.

[0044] 1. A control unit-specific key pair GerIndPub, GerIndPriv is generated for a control unit having the identity GerID, preferably in a hardware security module (HSM) installed in the control unit 2 .

[0045] 2. If the key pair is generated in the control device 2, the private key GerIndPriv remains there. If the key pair is generated outside the control device 2, GerIndPriv is introduced into the control device 2 in a manner that is as secure as possible and does not leave the control device.

[0046] 3. The identity GerID, the control device type GerTyp, and the public key GerIndPub are transmitted to the GCA, where a certificate GerIndCert is generated for the data GerID, GerIndPub, and GerTyp using GerRootPriv. For example, the GerID is included as part of the body and the GerTyp is entered as an additional field (extension) in the certificate GerIndCert. All data is then signed using GerRootPriv.

[0047] 4. GerIndCert is transmitted back by the GCA to the control unit 2 and stored there.

[0048] 5. FzgRootPub, the public key of FCA, is stored in the control device in a tamper-proof manner.

[0049] D: Acquisition of vehicle identity FzgID and vehicle fingerprint FzgFA This is done once for each control unit 2 of type GerTyp with identity GerID when it is installed in a vehicle 1 with identity FzgID, for example during vehicle production at an OEM.

[0050] 1. When a control unit 2 of the GerTyp type with a GerID is installed in a vehicle 1 with an FzgID, the data packet FzgID, GerTyp, GerID is recorded in a forgery-proof manner and subsequently transmitted in a forgery-proof manner to the OEM's own backend 3 .

[0051] 2. The backend 3 stores the data packet FzgID, GerTyp, and GerID in a tamper-proof manner.

[0052] 3. During the manufacture of the vehicle 1 , the unique digital fingerprint FzgFA of the vehicle 1 is collected in a secure environment to prevent forgery, and the data packets FzgID and FzgFA are transmitted to the backend 3 in a tamper-proof manner.

[0053] 4. Various vehicle-specific data (eg the specific identities of the various control devices installed in the vehicle, preferably non-reconstructed data) can be incorporated into the vehicle fingerprint FzgFA so that it cannot be easily reproduced manually.

[0054] 5. The vehicle fingerprint FzgFA must be designed in such a way that it can be at least partially “copied” by the control unit 2 installed in the vehicle 1 during its operation, by the data included in the vehicle fingerprint FzgFA being aggregated, for example, by other control units installed in the vehicle 1, for example via different vehicle buses.

[0055] 6. The backend 3 stores the data packets FzgID and FzgFA in a tamper-proof manner.

[0056] E: If the vehicle 1 requires a certificate or a new certificate from the perspective of the control device 2 , the following steps are performed.

[0057] 1. Control device 2

[0058] a. Thus, the vehicle fingerprint FzgFAGerSpez unique to the control device is determined, ie, the control device aggregates the information required for this purpose,

[0059] b. Find out the identity of the vehicle it is in, FzgID,

[0060] c. Generate a key pair FzgIndPub, FzgIndPriv for a vehicle-specific certificate FzgIndCert of a vehicle 1 having an identity FzgID in a secure environment, wherein the vehicle-specific private key FzgIndPriv remains in the secure environment,

[0061] d. Create a certificate signing request or certificate signing requirement (CSR) for FzgID, FzgIndPub, and GerTyp.

[0062] e. Generate a signature Sign, i.e., data packet (CSR (FzgID, FzgIndPub,

[0063] GerTyp), FzgFAGerSpez) is signed using the control device's exclusive private key GerIndPriv,

[0064] f. Send data packet ((CSR(FzgID,FzgIndPub,GerTyp),FzgFAGerSpez),Sign,GerIndCert(GerID,GerIndPub,GerTyp)) to backend 3.

[0065] 2. Backend 3 receives the data packet, and

[0066] a. Using the public key stored in the GCA of the control device issuing office

[0067] GerRootPub checks the correctness of the control device's exclusive certificate GerIndCert.

[0068] b. Using the public key contained in the accompanying control device-specific certificate GerIndCert

[0069] GerIndPub checks the correctness of the signature Sign of the data packet.

[0070] c. Extract the vehicle identity FzgID from the CSR and the control device exclusive certificate

[0071] Extract the identity GerID and control device type of control device 2 from GerIndCert

[0072] GerTyp, and check if there is a record stored in the backend 3 for FzgID, GerTyp and

[0073] GerID entries,

[0074] d. Check whether the entry FzgID, FzgFA is stored for the identity FzgID of vehicle 1,

[0075] e. Check the vehicle fingerprint unique to the control device contained in the received message

[0076] Does FzgFAGerSpez match the general vehicle fingerprint FzgFA?

[0077] f. If one of the above checks fails, it aborts the process,

[0078] g. Otherwise, it sends CSR(FzgID, FzgIndPub, GerTyp) for the vehicle identity FzgID and the public key FzgIndPub to the vehicle CA, ie FCA, via a protected channel,

[0079] h. FCA issues a vehicle-specific certificate FzgIndCert signed with FzgRootPriv based on the CSR (FzgID, FzgIndPub, GerTyp) for the vehicle identity FzgID and the public key FzgIndPub, and

[0080] i. FCA sends the vehicle-specific certificate FzgIndCert back to backend 3,

[0081] j. It sends back the vehicle-specific certificate FzgIndCert to the control device 2 installed in the vehicle 1.

[0082] 3. Control device 2

[0083] a. Check the received certificate FzgIndCert, ie,

[0084] i. Use FzgRootPub to check the correctness of the certificate signature,

[0085] ii. Check whether the received certificate corresponds to the sent CSR, that is, whether the FzgID, FzgIndPub, and GerTyp in the two data structures are consistent,

[0086] b. Locally store the vehicle-specific certificate FzgIndCert.

[0087] 4. From now on, the control device 2 with the identity GerID possesses the vehicle-specific certificate FzgIndCert and the associated vehicle-specific private key FzgIndPriv issued based on the vehicle identity FzgID and can securely execute the tasks transmitted by the vehicle 1 to the control device 2 .

Claims

1. A method for equipping a vehicle with a dedicated certificate, wherein: The vehicle comprises at least one control device and a communication unit, wherein the communication unit is configured to establish communication between the at least one control device and an off-vehicle server as required, wherein the control device and the off-vehicle server implement an asymmetric encryption mechanism for secure authentication. A vehicle certification office (FCA) with a vehicle infrastructure (PKI) for public keys is established based on an asymmetric key pair (FzgRootPub, FzgRootPriv) of the vehicle certification office (FCA), wherein the private key (FzgRootPriv) of the key pair (FzgRootPub, FzgRootPriv) of the vehicle certification office (FCA) remains in the vehicle certification office (FCA), and the public key (FzgRootPub) of the key pair (FzgRootPub, FzgRootPriv) of the vehicle certification office (FCA) is distributed to users who need it, wherein a control device certification office (GCA) with a control device infrastructure (PKI) for public keys is established based on an asymmetric key pair (FzgRootPub, FzgRootPriv) of the control device certification office (GCA). tPub, GerRootPriv), wherein the private key (GerRootPriv) of the key pair (GerRootPub, GerRootPriv) of the controller certification authority (GCA) remains in the controller certification authority (GCA), and the public key (GerRootPub) of the key pair (GerRootPub, GerRootPriv) of the controller certification authority (GCA) is distributed to users who require it, wherein the controller is provided with initial cryptographic material in the following manner: a controller-specific key pair (GerIndPub, GerIndPriv) is generated for the controller and the identity (GerID) of the controller and its public key (GerIndPub) are transmitted to the controller certification authority (GCA), In the controller certification authority (GCA), a controller-specific certificate (GerIndCert) is generated for the transmitted data (GerID, GerIndPub) using the private key (GerRootPriv) of the controller certification authority (GCA). The controller-specific certificate (GerIndCert) is then transmitted back to the controller, where it is inserted and stored in a tamper-proof manner. It is characterized by: The public key (FzgRootPub) of the vehicle certification authority (FCA) is stored in the control device in a tamper-proof manner, wherein To request a first or new certificate, perform the following steps: The control device ascertains the identity of the vehicle in which it is installed (FzgID), In this case, a vehicle-specific key pair (FzgIndPub, FzgIndPriv) for a dedicated vehicle certificate is generated in the secure environment of the control device, wherein the vehicle-specific private key (FzgIndPriv) remains in the secure environment, and subsequently a certificate signing request (CSR) is generated for at least the vehicle identity (FzgID) and the vehicle-specific public key (FzgIndPub). The signature (Sign) is then generated as follows: the certificate signing request (CSR(FzgID, FzgIndPub)) is signed using the control unit's control unit-specific private key (GerIndPriv), and the resulting data packet (CSR(FzgID, FzgIndPub), Sign, GerIndCert(GerID, GerIndPub)) is then sent to the off-board server. The off-board server receives the data packet (CSR (FzgID, FzgIndPub), Sign, GerIndCert (GerID, GerIndPub)) and subsequently checks the correctness of the control unit-specific certificate (GerIndCert) with the help of the public key (GerRootPub) of the control unit certification authority (GCA) stored in the off-board server. The off-vehicle server extracts the vehicle identity (FzgID) from the certificate signing request (CSR) and the control device identity (GerID) from the control device-specific certificate (GerIndCert) and checks whether entries (FzgID, GerID) for the vehicle identity (FzgID) and the control device identity (GerID) are stored. wherein if one of the checks fails, the process comprising the steps executed to request the first certificate or the new certificate is aborted by the off-board server, The off-board server (3) then checks the correctness of the signature (Sign) of the received data packet using the public key (GerIndPub) of the control unit (2) contained in the accompanying control unit-specific certificate (GerIndCert). Subsequently, the off-vehicle server sends a certificate signing request (CSR(FzgID, FzgIndPub)) for the vehicle identity (FzgID) and the vehicle-specific public key (FzgIndPub) to the vehicle certification authority (FCA) via a protected transmission path. The vehicle certification authority issues a vehicle-specific certificate (FzgIndCert) signed with the private key (FzgRootPriv) based on the certificate signing request (CSR(FzgID, FzgIndPub) for the vehicle identity (FzgID) and the vehicle-specific public key (FzgIndPub) and transmits it back to the off-vehicle server. Subsequently, the off-vehicle server transmits the vehicle-specific certificate (FzgIndCert) to the control device installed in the vehicle. The control device checks the received vehicle-specific certificate (FzgIndCert) in the following manner: i.e., it checks at least the correctness of the signature of the vehicle-specific certificate (FzgIndCert) using the public key (FzgRootPub) and checks again whether the received vehicle-specific certificate (FzgIndCert) corresponds to the sent certificate signing request (CSR), i.e., whether at least the vehicle identity (FzgID) and the vehicle-specific public key (FzgIndPub) in the two data structures are consistent. The vehicle-specific certificate (FzgIndCert) is then stored locally in the event of a positive check result.

2. The method according to claim 1, characterized in that The control equipment type (GerTyp) is also transmitted to the control equipment certification authority (GCA).

3. The method according to claim 2, characterized in that The controller's identity (GerID) as part of the body and the controller type (GerTyp) as an additional field are entered into the controller-specific certificate (GerIndCert), and all data are signed using the private key (GerRootPriv) of the controller certification authority (GCA).

4. The method according to any one of claims 1 to 3, characterized in that In order to ascertain the vehicle identity (FzgID) associated with the identity (GerID) of the control unit, a data packet consisting of the vehicle identity (FzgID) and the identity (GerID) of the control unit is collected in a forgery-proof manner when the control unit is installed in the vehicle and then transmitted in a tamper-proof manner to an off-vehicle server, which stores the data packet (FzgID, GerID) in a tamper-proof manner.

5. The method according to claim 4, characterized in that The control device type (GerTyp) is also included in the data packet.

6. The method according to any one of claims 1 to 3, characterized in that A control device-specific key pair (GerIndPub, GerIndPriv) is generated by the control device, after which the control device-specific private key (GerIndPriv) is securely stored and does not leave the control device.

7. The method according to any one of claims 1 to 3, characterized in that The vehicle-specific key pair (FzgIndPub, FzgIndPriv) is generated by the control unit, and the vehicle-specific private key (FzgIndPriv) is subsequently stored securely and does not leave the control unit.

8. The method according to claim 6, characterized in that The corresponding individual key pair (GerIndPub, GerIndPriv; FzgIndPub, FzgIndPriv) is generated by the control device in the hardware security module (HSM) and / or is at least securely stored in the hardware security module, and the corresponding private key (GerIndPriv, FzgIndPriv) does not subsequently leave the hardware security module (HSM).

9. The method according to any one of claims 1 to 3, characterized in that During vehicle production, a unique, forge-proof digital vehicle fingerprint (FzgFA) is collected and a data packet containing the vehicle identity (FzgID) and the vehicle fingerprint (FzgFA) is transmitted in a tamper-proof manner to an off-board server and stored there in a tamper-proof manner. In this case, the control device determines its own control device-specific vehicle fingerprint (FzgFAGerSpez) when generating a certificate signing request (CSR) in the following manner: the control device collects the information required for this purpose in the vehicle and then generates a signature (Sign) in such a way that a data packet (CSR(FzgID, FzgIndPub), FzgFAGerSpez) containing the control device-specific vehicle fingerprint (FzgFAGerSpez) is signed using a control device-specific private key (GerIndPriv); the data packet generated thereby and extended with the control device-specific vehicle fingerprint (FzgFAGerSpez) is then transmitted to an off-vehicle server instead of the data packet (CSR(FzgID, FzgIndPub), Sign, GerIndCert(GerID, GerIndPub)) and processed further there.

10. The method according to any one of claims 1 to 3, characterized in that The control device type (GerTyp) is taken into account when generating a certificate signing request (CSR), producing a vehicle-specific certificate (FzgIndCert), extracting data from a certificate signing request (CSR) and / or checking a certificate signing request (CSR) or a signed vehicle-specific certificate (FzgIndCert).

Images