Method for securely equipping control units produced by a supplier with cryptomaterial

Abstract

The invention relates to a method for securely equipping control units (ECU) manufactured by a supplier (SUP) for vehicles of a vehicle manufacturer (OEM) with an individual key pair (KeyPairECU) and a certificate (ZertECU), for which, in a first step, a key pair (KeyPairSUP) is securely negotiated between the vehicle manufacturer (OEM) and the supplier (SUP), wherein, in a second step, during production at the supplier (SUP), each of the control units (ECU) generates a unique random key pair (KeyPairECU) and stores it within the control unit (ECU), after which, in a third step, the control unit (ECU) generates a certificate signing request (CSR) and signs it with the public key from the generated key pair (KeyPairECU), after which, in a fourth step, the supplier (SUP) delivers the control unit (ECU) and the certificate signing request (CSR) to the vehicle manufacturer (OEM), after which, in a fifth step, the vehicle manufacturer (OEM) verifies the certificate signing request (CSR) in its public key infrastructure (PKI) and, in the event of a positive verification, issues a certificate (ZertECU) for the control unit (ECU), and after which, in a sixth step, the certificate (ZertECU) belonging to the control unit (ECU) is installed in the control unit (ECU) in the production department of the vehicle manufacturer (OEM).

Description

[0001] Method for securely equipping control units manufactured by a supplier with crypto material

[0002] The invention relates to a method for securely equipping control units manufactured by a supplier for vehicles of a vehicle manufacturer with an individual key pair and a certificate.

[0003] Electronic control units (ECUs) in modern vehicles are highly networked and communicate with other systems both inside and outside the vehicle. Since these ECUs influence numerous parameters that are crucial for the vehicle's functionality, their communication is considered safety-critical. For example, if communication were intercepted by a hacker, control commands to the vehicle could be corrupted or not transmitted, affecting the functionality of driver assistance systems, acceleration, braking, steering, and other aspects of the vehicle. Therefore, the ECUs and other systems involved in the communication must be certain that they are only communicating with trusted partners.Typically, trustworthiness is ensured via an asymmetric key pair and a public key infrastructure, whereby the key pair is generated and stored in the control unit, which sends a certificate signing request to the public key infrastructure, which then issues a corresponding certificate, also known as an End Entity Certificate, to the requesting party.

[0004] If, as is the case in the vast majority of instances, the electronic control units (ECUs) for vehicles are not manufactured by the vehicle manufacturer (OEM) itself but by a supplier, then it is necessary that the corresponding keys are generated during the ECU manufacturing process, i.e., at the supplier's site. This requires a public key infrastructure (PKI) at the supplier's site. Such a procedure is described, for example, in German patent DE 102020 004 832 A1. This approach has two main disadvantages. Firstly, from the vehicle manufacturer's perspective, it means relinquishing control of its private key to the supplier. Secondly, it is very complex overall, as each ECU manufacturer must implement its own PKI. This PKI is subject to very high security requirements, making it a far from trivial task.The implementation of a separate public key infrastructure at each manufacturer therefore leads to high costs and personnel expenses for both the suppliers and the vehicle manufacturer, who incurs additional expenses due to appropriate security briefings, training and monitoring of compliance with security requirements.

[0005] Similarly, in vehicle production, production line downtime must be avoided at all costs, as it incurs significant expenses. This necessitates exceptionally high availability of the public key infrastructure (PKI) and its associated subsystems. Therefore, it is essential to install a highly available, fail-safe PKI. The more frequently such a PKI needs to be maintained, the more complex this requirement becomes.

[0006] The method according to the invention now has the task of enabling a cost-effective solution with high availability, which at the same time leaves control over the private key with the vehicle manufacturer.

[0007] According to the invention, this problem is solved by a method with the features in claim 1. Advantageous embodiments and further developments of the method according to the invention are set forth in the dependent claims.

[0008] The method according to the invention, unlike the prior art method, provides in a first or preliminary step that a key pair is securely negotiated between the vehicle manufacturer and the supplier, so that the supplier can be authenticated via this key pair and is authorized to send data to the vehicle manufacturer. Then, in a second step, each of the control units can generate a unique random key pair and store it within the control unit. According to a particularly advantageous embodiment, this storage can take place within the control unit in a secure environment, such as a hardware security module. Subsequently, the control unit generates a certificate signing request, also known as a CSR.This is then signed with the public part of the generated key pair of the control unit. All of this takes place during the supplier's production process.

[0009] In the next step, the manufactured control unit and the Certificate Signing Request are delivered to the vehicle manufacturer, whereby various possibilities are conceivable, which will be discussed in detail later.

[0010] Following this, the Certificate Signing Request is verified by the vehicle manufacturer in its public key infrastructure (PKI). Only this single PKI at the vehicle manufacturer is required for the entire process. If the verification is successful, the PKI issues a certificate for the electronic control unit (ECU). During the ECU's installation in the respective vehicle, the certificate issued for that ECU can then be installed. Once the certificate, along with the key pair generated by the ECU, is installed on the ECU, the necessary cryptographic material for communication is available within the ECU.

[0011] Because the vehicle manufacturer operates its own public key infrastructure, it has full control over the key material used there. This is crucial for keeping all the cryptographic material required for the safety-critical communication between the control unit and other systems under the manufacturer's control. This ensures a high level of security for the subsequent communication between the control unit and the vehicle. It also helps to make so-called supply chain attacks more difficult or, ideally, to prevent them altogether. These are attacks in which malware is introduced at suppliers or in which cryptographic material that enables the subsequent introduction of malware is stolen from suppliers.In addition to this advantage regarding security aspects, cost advantages also play a crucial role here, since only a single manufacturer-owned public key infrastructure is required, and the need to build such a security-critical component with multiple suppliers, with the additional effort described above, can be avoided.

[0012] Furthermore, the vehicle manufacturer is now responsible not only for controlling the public key infrastructure but also for its operation. This allows responsibilities for reliable and fail-safe operation to be consolidated, and because the public key infrastructure exists only once, redundancies can be more easily implemented, enabling a rapid resumption of operation in the event of a failure.

[0013] The first of the previously mentioned options regarding the delivery of the control unit and the certificate signing request involves delivering them simultaneously. For this to work, the certificate signing request is read from the control unit during production at the supplier's facility and temporarily stored there. The control unit can then be delivered from the supplier's production facility to the vehicle manufacturer's via established logistics chains. Simultaneously, the temporarily stored certificate signing request is sent by the supplier to the vehicle manufacturer's public key infrastructure (PKI). The previously negotiated key pair is used for authentication, allowing the vehicle manufacturer and its PKI to verify that the shipment originated from the supplier who authenticated the certificate signing request.The vehicle manufacturer's public key infrastructure now verifies the authentication and, if this verification is successful, allows the public key infrastructure to generate the corresponding certificate and make it available for installation in the control unit, as explained above.

[0014] The main advantage of this approach is that the vehicle manufacturer's IT systems in production, such as a production server or the public key infrastructure, can, in principle, fail for a maximum of the time required for the delivery of the control units. This would have no impact on the manufacturer's production. With appropriate monitoring of the relevant IT systems, the appropriate contacts can be notified very quickly in the event of a failure, enabling the systems to be restored to working order. In practice, this means that an IT system failure for the shortest possible delivery time of the control units would be tolerable, as it would not lead to a production stoppage, i.e., the dreaded "assembly line shutdown." This offers a significant advantage for the vehicle manufacturer.

[0015] However, this described variant of the inventive method is highly dependent on the reliable transmission of the Certificate Signing Request to the vehicle manufacturer's public key infrastructure. If this is not the case, and if the problem cannot be rectified while the control unit is en route from the supplier to the vehicle manufacturer, disadvantages could arise because the control unit cannot be fully integrated into the vehicle.

[0016] An alternative delivery method allows for even greater reliability. In this alternative delivery procedure for the control unit and the certificate signing request, the supplier uses the key pair negotiated between them and the vehicle manufacturer to create a signature for the certificate signing request and writes this signature to the non-volatile memory of the control unit. The control unit itself now contains not only the certificate signing request but also its signature, using the key pair negotiated between the vehicle manufacturer and the supplier. The control unit is then delivered to the vehicle manufacturer in this state. The vehicle manufacturer is therefore able to read the certificate signing request and the signature from the control unit at any time after receiving it from the supplier.He can then transmit this data internally, for example, via a production server of his public key infrastructure. This infrastructure can then validate the signature using the negotiated key pair, which it also knows. After successful signature validation, the procedure described at the beginning can continue. In this way, the supplier no longer needs to transmit the certificate signing request directly to the vehicle manufacturer's public key infrastructure. Instead, the certificate signing request is only read from the control unit at the vehicle manufacturer's production plant and forwarded internally to the public key infrastructure. Even within the production process at the vehicle manufacturer, it remains protected by the signature, thus reducing security requirements and ultimately production costs for the vehicle manufacturer.This allows, for example, access controls and personnel authentication in the vehicle manufacturer's production, resulting in cost advantages. Parts of the production process can also be outsourced more easily without increasing the vulnerability of the vehicle manufacturer's security-relevant systems.

[0017] In both process variants, it can now be stipulated that the certificate issued by the public key infrastructure for the respective control unit is sent to a production server or, in principle, to all production servers of the vehicle manufacturer. It is then immediately available at every production site.

[0018] Furthermore, in one variant of the inventive method, the certificate signing request can be read from the currently installed or to-be-installed control unit in order to uniquely identify it. Based on this certificate signing request, the certificate, which is temporarily stored, for example, on the responsible production server, can then be determined and, as already mentioned, installed in the control unit.

[0019] Further advantageous embodiments of the two variants of the method according to the invention can also be seen from the two exemplary embodiments, which are described in more detail below with reference to the figures.

[0020] This shows:

[0021] Fig. 1 shows a schematic sketch of the first variant of the process flow; and

[0022] Fig. 2 is a schematic sketch of the second variant of the process flow.

[0023] Figure 1 shows a vehicle manufacturer (OEM) and a supplier (SUP). For the necessary communication between the OEM and SUP, a key pair (KeyPairSUP) is negotiated securely, symbolized here by the double arrow labeled 1. This KeyPairSUP key pair is then used to authenticate SUP and authorizes it to send data to the OEM.

[0024] Furthermore, within the production process of supplier SUP, indicated here by a dashed border and a symbolic factory pictogram, each ECU generates a unique, random key pair, KeyPairECU, and stores it within the ECU in a secure environment, such as a hardware security module. This is indicated by arrow 2 in Figure 1. The ECU then generates a certificate signing request (CSR) and signs it with the public key of the KeyPairECU key pair generated within the ECU. In the next step, symbolized by arrow 4, the ECU reads this CSR and temporarily stores it on a production server of supplier SUP, labeled 3.The ECU is then delivered to the vehicle manufacturer (OEM), as indicated by the truck symbol. As indicated by the arrow marked 5, the Certificate Signing Request (CSR) is transmitted to the OEM's Public Key Infrastructure (PKI). The CSR is authenticated using the negotiated key pair KeyPairSUP. This ensures that only the supplier (SUP) can transmit the relevant data to the OEM, as without such a KeyPairSUP key pair, a properly authenticated and therefore effective transmission of the CSR to the OEM and its PKI would not be possible.

[0025] Upon receiving the Certificate Signing Request (CSR), the vehicle manufacturer's (OEM) Public Key Infrastructure (PKI) verifies the signature created with the generated key pair (KeyPairECU) and, if the verification is successful, issues a certificate (ZertECU) for the control unit (ECU). This certificate (ZertECU) is then distributed to all OEM production facilities and their respective production servers (7) as indicated by the arrow marked 6, and stored there until needed.

[0026] When the respective control unit ECU is installed in a vehicle within the production of the vehicle manufacturer OEM, the Certificate Signing Request CSR and, based on this, the correct certificate ZertECU are determined within the production server 7 according to the arrow marked 8 and installed in the control unit ECU according to the arrow 9.

[0027] To reduce the strong dependence on the transmission of the Certificate Signing Request (CSR) authenticated with the negotiated key pair KeyPairSUP (labeled 5 in Figure 1), the procedure can also be implemented as shown in Figure 2. Here, too, the procedure begins with the negotiation of a key pair KeyPairSUP used for communication, as indicated by the double arrow 1, analogous to the representation in Figure 1. Subsequently, a unique random key pair KeyPairECU is generated within the ECU and securely stored there. This is also indicated by the arrow labeled 2, analogous to the representation in Figure 1. Finally, a Certificate Signing Request (CSR) is generated and signed with the public key of the generated KeyPairECU key pair of the ECU.The reading of the signed Certificate Signing Request (CSR) to the supplier SUP's production server 3, indicated by arrow 4, is also carried out analogously to the process in Figure 1.

[0028] Unlike the process shown in Figure 1, as indicated by arrow 10, a signature CSRSigSUP is now generated over the Certificate Signing Request (CSR) using the negotiated key pair KeyPairSUP. The supplier SUP writes this signature CSRSigSUP to the non-volatile memory of the ECU, as indicated by arrow 11. The ECU is then delivered to the vehicle manufacturer (OEM) or its production facility. In principle, the Certificate Signing Request (CSR) no longer needs to be sent separately; instead, it is delivered stored in the ECU along with the CSRSigSUP signature generated over it. However, it may still be useful to send the Certificate Signing Request (CSR) in parallel to increase its availability.This prevents the risk of a production stoppage in the event of a connection failure between the OEM's production facility and its Public Key Infrastructure (PKI). It is sufficient if the connection between the OEM's production facility and its PKI existed at the time of shipment or between the time of shipment and the start of production. During production itself, it is no longer required. The OEM's production facility is now able to read the Certificate Signing Request (CSR) and the signature CSRSigSUP from the ECU at any time. In Figure 2, this is done analogously to Figure 1 via arrow 8, with the difference that the signature CSRSigSUP is also read along with the Certificate Signing Request (CSR).Internally, within the vehicle manufacturer's (OEM) systems, this data is now forwarded to the OEM's Public Key Infrastructure (PKI) according to arrow 12. The PKI then validates the CSRSigSUP signature with the KeyPairSUP key pair negotiated between the OEM and the supplier SUP. If the CSRSigSUP signature is validated as correct, the OEM's PKI issues a ZertECU certificate for the ECU based on the Certificate Signing Request (CSR) and sends it, as shown in Figure 1, via arrow 6 to the OEM's production server 7. Again, as shown in Figure 1, the ZertECU certificate corresponding to the respective ECU is then installed in the ECU, as indicated by arrow 9.

[0029] In both versions, the ECU control unit, from the moment the ZertECU certificate is installed on the ECU control unit and the ECU, preferably in its hardware security module, has access to the KeyPairECU key pair it has generated, has securely and reliably stored the crypto materials required for communication within the ECU control unit.

Claims

Patent claims 1. A method for securely equipping electronic control units (ECUs) manufactured by a supplier (SUP) for vehicles of a vehicle manufacturer (OEM) with an individual key pair (KeyPairECU) and a certificate (ZertECU), wherein in a first step a key pair (KeyPairSUP) is securely negotiated between the vehicle manufacturer (OEM) and the supplier (SUP), wherein in a second step in production at the supplier (SUP) each of the electronic control units (ECUs) generates a unique random key pair (KeyPairECU) and stores it within the electronic control unit (ECU), wherein in a third step the electronic control unit (ECU) generates a certificate signing request (CSR) and signs it with the public key from the generated key pair (KeyPairECU), wherein in a fourth step the supplier (SUP) delivers the electronic control unit (ECU) and the certificate signing request (CSR) to the vehicle manufacturer (OEM).whereupon, in a fifth step, the vehicle manufacturer (OEM) verifies the certificate signing request (CSR) in its public key infrastructure (PKI), and, in the case of a positive verification, issues a certificate (ZertECU) for the control unit (ECU), and whereupon, in a sixth step, the certificate (ZertECU) belonging to the control unit (ECU) is installed in the control unit (ECU) during the vehicle manufacturer's (OEM) production process.

2. Method according to claim 1, characterized in that the generated key pair (KeyPairECU) or at least its private key is stored in a secure environment in the control unit (ECU).

3. Method according to claim 1 or 2, characterized in that the certificate (ZertECU) belonging to the control unit (ECU) is installed when the control unit (ECU) is installed in the respective vehicle.

4. Method according to claim 1, 2 or 3, characterized in that the delivery of the control unit (ECU) and the certificate signing request (CSR) takes place in parallel to each other, for which the certificate signing request (CSR) is read out and temporarily stored by the control unit (ECU) while still in production at the supplier (SUP).

5. Method according to claim 4, characterized in that the cached certificate signing request (CSR) is sent to the vehicle manufacturer's (OEM) public key infrastructure (PKI), which is authenticated via the negotiated key pair (KeyPairSUP), and in the event of a positive verification of the authentication, the process proceeds to the fifth step.

6. Method according to claim 1, 2 or 3, characterized in that the certificate signing request (CSR) is read and temporarily stored by the control unit (ECU) during production at the supplier (SUP), after which the supplier (SUP) creates a signature (CSRSigSUP) on the certificate signing request (CSR) using the negotiated key pair (KeyPairSUP) and writes this signature (CSRSigSUP) into the non-volatile memory of the control unit (ECU).

7. Method according to claim 6, characterized in that the supplier (SUP) delivers the control unit (ECU) together with the certificate signing request (CSR) and signature (CSRSigSUP) stored thereon to the vehicle manufacturer (OEM).

8. Method according to claim 7, characterized in that the vehicle manufacturer (OEM) reads the certificate signing request (CSR) and the signature (CSRSigSUP) from the control unit (ECU) and transmits it to its public key infrastructure (PKI), which validates the signature (CSRSigSUP) with the negotiated key pair (KeyPairSUP), and in the case of a positive validation, proceeds to the fifth step.

9. Method according to one of claims 1 to 8, characterized in that a certificate (ZertECU) issued in the fifth step for the respective control unit (ECU) is transmitted to production server (7) of one or all of the production plants of the vehicle manufacturer (OEM) and is temporarily stored there for the sixth step.

10. Method according to one of claims 1 to 9, characterized in that in the sixth step the certificate signing request (CSR) is read from the control unit (ECU) in order to determine the correct certificate (ZertECU) belonging to the respective control unit (ECU).

Images