Search

EP-4740359-A1 - METHOD FOR SECURELY EQUIPPING SYSTEMS WITH AN INDIVIDUAL CERTIFICATE

EP4740359A1EP 4740359 A1EP4740359 A1EP 4740359A1EP-4740359-A1

Abstract

The invention relates to a method for securely equipping systems with an individual certificate for secure communication with a communication partner, a certification authority (CA) being established on the basis of an asymmetric key pair (CARootPub, CARootPriv). The invention is characterised in that an additional certificate signing authority (ACSA) equipped with an asymmetric key pair (ACSAPub, ACSAPriv) is established, the public key (ACSAPub) of the additional certificate signing authority (ACSA) being distributed to all systems that wish to receive certificates (Cert) issued by the certification authority (CA) in order then to sign a certificate (Cert) issued by the certification authority (CA) by the additional certificate signing authority (ACSA) with its private key (ACSAPriv) and to transmit the signature (CertSign) generated in this way together with the generated certificate (Cert) to the system, whereupon the correctness of the certificate (Cert) and the signature (CertSign) is checked by the system by means of the public key (ACSAPub) of the additional certificate signing authority (ACSA) previously stored therein, without verifying the signature of the certification authority (CA) contained in the certificate (Cert), and an exception handling being initiated in the event of a failed check.

Inventors

  • FRIESEN, VIKTOR
  • WEBER, PHILIPP
  • MEIDLINGER, DANIEL
  • Kimmerle, Christian

Assignees

  • Mercedes-Benz Group AG

Dates

Publication Date
20260513
Application Date
20250319

Claims (14)

  1. 1. A method for securely equipping systems with an individual certificate, wherein a certification authority (CA) is established based on an asymmetric key pair (CARootPub, CARootPriv), characterized in that an additional certificate signing authority (ACSA) is established, equipped with an asymmetric key pair (ACSAPub, ACSAPriv) different from the asymmetric key pair (CARootPub, CARootPriv) of the certification authority (CA), wherein the public key (ACSAPub) of the additional certificate signing authority (ACSA) is distributed to all systems that wish to request and receive certificates (Cert) issued by the certification authority (CA), in order to subsequently, during the transmission of a certificate (Cert) issued by the certification authority (CA) to the system requesting the certificate, this certificate, including the signature, is signed by the additional certificate signing authority (ACSA) with its private key (ACSAPriv), and the signature thus generated is (CertSign) to be transmitted to the system requesting the certificate together with the generated certificate (Cert), after which the correctness of the received certificate (Cert) and the received signature (CertSign) is checked by the system requesting the certificate (Cert) using the public key (ACSAPub) of the additional certificate signing authority (ACSA) previously stored there, without verifying the signature contained in the certificate (Cert) with the public key (CARootPub) of the certification authority (CA), and in the event of a failed verification of the received signature (CertSign), exception handling is initiated.
  2. 2. The method according to claim 1, characterized in that, for at least one data field contained in the Certificate Signing Request (CSR), the system requesting/receiving the certificate (Cert) checks whether the value of this data field in the Certificate Signing Request (CSR) transmitted to the Certification Authority (CA) matches the value of this data field in the received certificate. (Cert) agrees in a suitable manner.
  3. 3. Method according to claim 1 or 2, characterized in that the certification authority (CA) or a registration authority (RA) trains the additional certificate signing authority (ACSA).
  4. 4. Method according to claim 1, 2 or 3, characterized in that the additional certificate signing authority (ACSA) is implemented in such a way that it is able to determine whether the certificate (Cert) to be forwarded to the requesting/receiving system meets the requirements of that system.
  5. 5. Method according to claim 4, characterized in that for this purpose the additional certificate signing authority (ACSA) is equipped, in particular once, with the public key (CARootPub) of the certification authority (CA) and the correctness of the signature of an additionally to be signed certificate (Cert) is checked by the additional certificate signing authority (ACSA) before the calculation of the additional signature (CertSign).
  6. 6. Method according to claim 4 or 5, characterized in that for each certificate (Cert) to be signed, the Certificate Signing Request (CSR) underlying the certificate issuance is made known to the Additional Certificate Signing Authority (ACSA) in a manner that allows a secure assignment of the Certificate Signing Request (CSR) to the certificate (Cert) to be signed.
  7. 7. Method according to claim 6, characterized in that the Certificate Signing Request (CSR) is transmitted by the Certification Authority (CA) to the Additional Certificate Signing Authority (ACSA) in a suitably secure manner and is subsequently checked by the Additional Certificate Signing Authority (ACSA) to see if the certificate (Cert) to be signed corresponds to the Certificate Signing Request (CSR) in a suitable manner.
  8. 8. Method according to claim 6, characterized in that the Certificate Signing Request (CSR) is transmitted by the Registration Authority (RA) to the Additional Certificate Signing Authority (ACSA) in a suitably secured manner and is subsequently checked by the Additional Certificate Signing Authority (ACSA) to see if the certificate (Cert) to be signed corresponds to the Certificate Signing Request (CSR) in a suitable manner.
  9. 9. Method according to one of claims 1 to 8, characterized in that the private key (ACSAPriv) of the additional certificate signing authority (ACSA) is stored in the additional certificate signing authority (ACSA).
  10. 10. Method according to claim 9, characterized in that the storage is read-protected.
  11. 11. Method according to one of claims 1 to 10, characterized in that the public key (ACSAPub) of the additional certificate signing authority (ACSA) is stored in the systems.
  12. 12. Method according to claim 11, characterized in that the storage in the systems is tamper-proof.
  13. 13. Method according to one of claims 1 to 12, characterized in that the distribution of the public key (ACSAPub) of the additional certificate signing authority (ACSA) to all systems is integrity-protected.
  14. 14. A method according to any one of claims 1 to 6, characterized in that the systems used are control units in a vehicle. ...

Description

Mercedes-Benz Group AG Procedures for securely equipping systems with an individual certificate The invention relates to a method for securely equipping systems with an individual certificate, for secure communication with at least one communication partner, according to the type defined in more detail in the preamble of claim 1. Modern vehicles are characterized by increasing connectivity. These vehicles are not only connected to systems like the World Wide Web, but also to systems and servers operated by the vehicle manufacturer or OEM, such as proprietary applications and a manufacturer-owned server, often referred to as the vehicle backend. These are developed, marketed, and operated by the manufacturer exclusively for its own vehicle fleet. All of this together is also known as the vehicle ecosystem. In practice, the diverse communication relationships between the individual system components within such a vehicle ecosystem result in a multitude of new interfaces and applications, all of which must be secured by suitable cryptographic methods, such as mechanisms, protocols, etc. This security serves, for example, to protect the privacy of the vehicle user and to prevent external interference with data traffic, which, particularly during the transmission of data related to vehicle control, could be exploited by attackers to manipulate critical functions. It is obvious that the vehicles themselves cannot communicate with the external server or backend. In practice, it is always individual control units installed in the vehicles that establish and maintain a connection to the backend. From the backend's perspective, however, it primarily knows entire vehicles and not individual control units within them. Therefore, it is more important for the backend to know for sure in which vehicle the control unit it is communicating with is located. It's more difficult to know exactly which control unit is being used than to know the vehicle it belongs to. Communication between vehicles and other participants in the vehicle ecosystem, especially the backend, is currently secured using established standard protocols (mostly TLS, sometimes IPSec). Both standard protocols (TLS, IPSec) are based on asymmetric cryptography, specifically asymmetric private keys and certificates issued for the corresponding public keys by a central, trusted Certificate Authority (CA). The following requirements are important for secure communication between the vehicles and the backend: • The certificates used by the vehicles or their control units must be individual, i.e., each vehicle must have at least one unique private key, and • The corresponding certificate must be issued by a central certification authority (CA) trusted within the vehicle ecosystem to an individual vehicle identity, e.g. the vehicle identification number (VIN), also known as the chassis number. Ideally, this private key, along with its corresponding public key, should be generated in a secure hardware area (e.g., a Hardware Security Module/HSM) within the control unit of the vehicle to which the certificate belongs, and should never leave this secure area of the control unit. This ensures that the private key is virtually impossible for an attacker to determine. A seemingly obvious solution would be to delegate this task to the manufacturer of the control unit that is to house the individual private key: to generate a vehicle-specific key pair within the control unit during its production. The public key could then be read from the control unit, and a certificate created for it, while the private key would remain unreadable and inaccessible for the entire lifespan of the control unit. However, this approach is problematic for two reasons. First, the identity of the vehicle for which the certificate is to be issued is not yet known at the time the control unit is manufactured, as it is not known at that point in which vehicle—i.e., in which vehicle with which identity—the control unit will later be installed by the OEM. Second, the control unit is usually manufactured by a company other than the OEM. However, the vehicle-specific certificates for securing communication between the vehicles and the OEM's own backend, or other participants in the OEM's vehicle ecosystem, should be issued by the OEM itself, and not by the control unit manufacturer, among other reasons, to prevent potential misuse of certificates by the control unit manufacturer. While it is theoretically possible to securely connect an OEM's own certification authority (CA) to the control unit manufacturer's production lines, this is a costly solution. The applicant's patent application DE 102009 009 310 A1 provides a method for secure communication between a user device with a vehicle's electronic control unit (ECU) and a remote backend via a publicly accessible network using digital certificates. The method comprises the steps of the backend generating a non-specific certificate and sending it to th