Procedure for the secure provision of systems with an individual certificate

Abstract

The invention relates to a method for securely equipping systems with an individual certificate for secure communication with a communication partner, whereby a certification authority (CA) is established based on an asymmetric key pair (CARootPub, CARootPriv). The invention is characterized in that an additional certificate signing authority (ACSA) equipped with an asymmetric key pair (ACSAPub, ACSAPriv) is established, wherein the public key (ACSAPub) of the additional certificate signing authority (ACSA) is distributed to all systems that wish to receive certificates (Cert) issued by the certification authority (CA), in order to subsequently 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, after which the correctness of the certificate (Cert) and the signature (CertSign) is verified by the system using the public key (ACSAPub) of the additional certificate signing authority (ACSA) previously stored there.without verifying the signature of the certification authority (CA) contained in the certificate (Cert), and in case of a failed verification, exception handling is initiated.

Description

The invention relates to a method for securely providing systems with an individual certificate, for securely communicating with at least one communication partner, according to the type defined in more detail in the preamble of claim 1.Modern vehicles are distinguished by increasing networking. The vehicles are connected not only to systems such as the WorldWWeb, but also to systems and servers operated by the vehicle manufacturer or OEM, for example, applications inherent to the manufacturer and a server inherent to the manufacturer, which is frequently also referred to as a vehicle backend. These are developed, marketed and operated exclusively for their own fleet of vehicles by the manufacturer. All this together is also referred to as a vehicle ecosystem.In practice, the manifold communication relationships between the individual system components within such a vehicle ecosystem now result in a multiplicity of new interfaces and applications, all of which have to be secured by suitable cryptographic methods, such as mechanisms, protocols, etc. The protection serves, for example, to maintain the privacy of the vehicle user or to not enable any external intervention in the data traffic, which could be used by attackers to manipulate important functions, in particular when transmitting data relating to the vehicle control.It is obvious that the vehicles per se cannot communicate with the vehicle-external server or backend. In practice, individual control units installed in the vehicles are always used, which establish or maintain a connection to the backend. From the viewpoint of the backend, however, it is the case that primarily whole vehicles and no individual control units installed therein are known, so it is more important for the backend to know securely in which vehicle the control unit with which it is currently communicating is installed than to know which control unit is exactly but the associated vehicle is not known.The communication between vehicles and other participants of the vehicle ecosystem, in particular the backend, is currently secured with the aid of known standard methods (mostly TLS, sometimes IPSec). Both standard methods (TLS, IPSec) are based on asymmetric cryptography, in particular on asymmetric private keys and on certificates issued for the associated 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 devices must be individual, i.e. each vehicle must have at least one individual private key of its own, and• The associated certificate must be issued by a central certification authority (CA) trusted within the vehicle ecosystem to an individual vehicle identity, for example to the vehicle identification number (VIN: vehicle identification number), which is also referred to as chassis number.This private key should ideally be generated together with the associated public key in a secure hardware area (for example a hardware security module / HSM: hardware security module) of a control device located in the vehicle to which the certificate is intended to belong and should never leave this secure area of this control device. In this way, it can be ensured that the private key cannot be determined by an attacker in practice.An obvious solution would be to transfer this task to the manufacturer of the control device, who is to host the individual private key, to generate a vehicle-specific key pair in this control device during its production. The public key could then be read out of the control device and a certificate could be generated for this purpose, wherein the private key cannot be read out and remains in the control device for the entire service life of the latter. 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 of manufacturing the control device, since it is not known at this time in which vehicle, i.e. in the vehicle with which identity, the control device will be installed later in the OEM. Second, the controller is typically manufactured by a company other than the OEM. However, the vehicle-specific certificates for safeguarding the communication between the vehicles and the OEM-own backend or other participants of the OEM-own vehicle ecosystem should be issued by the OEM itself and not by the control device manufacturer, inter alia in order to exclude a potential misappropriation of certificates by the control device manufacturer. Theoretically, it is possible to securely connect a certification authority (CA) of its own OEM to the production lines of the control device manufacturer, but this is a cost-intensive solution.The applicant's laid-open specification DE 10 2009 009 310 A1 provides a method by means of which the secure communication between a user device with a control device of a vehicle and a backend located at a distance therefrom is possible via a publicly accessible network using digital certificates. The method comprises the steps of generating a non-specific certificate by the backend and sending the non-specific certificate to the control device, furthermore receiving and storing the non-specific certificate in the control device and then establishing an initial connection of the control device to the backend using the non-specific certificate as identifier. The initial connection is accepted by the backend only if the identifier is the non-specific certificate. Finally, identification information of the vehicle is requested by the backend and sent back to the backend by the control device. The backend then generates a specific certificate with the aid of the identification information and sends it to the control device. There it is received and stored. A cryptographically secured working connection can then be set up.The method presented in DE 10 2009 009 310 A1 has some disadvantages due to its principle. On the one hand, the certification authority generates not only the individual vehicle certificate but also the vehicle-specific key pair for which the certificate is issued. This also includes, in particular, the vehicle-specific private key. The vehicle-specific private key is therefore available not only to the control device or vehicle from which it is to be used, but is also known at least to the certification authority generating it. On the other hand, this key together with the certificate must be transmitted from the issuing certification authority to the vehicle via a relatively nonsecure connection. This is because the vehicle does not yet have a secure individual certificate at this point in time. Furthermore, the certification authority can never be sure that it actually transmits the newly created vehicle-specific certificate, and in particular the protectable individual private key, to the vehicle with the correct identity. Rather, an unauthorized third party who merely simulates this identity could also be the requester or recipient of the certificate, since the requester or recipient is not yet securely authenticated at this time because of the vehicle-specific certificate not yet present.The laid-open specification DE 10 2020 004 832 A1 describes a greatly improved modification of the method described in DE 10 2009 009 310 A1, which at least weakens the principal weaknesses described above. These improvements are now reasonably possible and practicable for two reasons. On the one hand, it is nowadays common practice for a plurality of control units which are equipped with a hardware security module (HSM) to be installed in vehicles. On the other hand, it is now possible for the device manufacturers to equip these control devices efficiently and in a secure manner, within the scope of the production process, not only with shared but also with individual secrets or keys. In particular, control units can be equipped with what is known as an endorsement key material, in particular also an individual asymmetric key pair or else a private key and a certificate containing the associated public key.As already mentioned above, at the time of production of the control device which is intended to house the vehicle-specific certificate, no certificate for a vehicle identity can be issued, since this is not yet known. DE 10 2020 004 832 A1 proposes issuing a certificate for an individual control device identity, for example for a unique and tamper-proof, for example read-only, identity of the control device which has installed the HSM, for example, in which the private key belonging to the vehicle-specific certificate is intended to be securely stored later.It is also proposed to add to the certificate specific to the control device the control device type to which this control device belongs (for example. Head unit (HU), telematics communication unit (TCU), rear seat unit (RSU), etc.), provided that this type cannot be derived from the control device identity, for example by storing the control device type in an extension field of the certificate ("certificate extension"). In this way, it is made possible for a plurality of control units installed in the same vehicle to be able to issue their own vehicle-specific certificate and for these different vehicle-specific certificates to be able to be distinguished from the opposite side if required.The device-specific private key and the device-specific certificate are then used by the control device at runtime to transmit a certificate signing request (CSR) generated in this control device at runtime and containing the vehicle-specific public key generated by the control device as part of a vehicle-specific key pair to the vehicle certification authority in a tamper-proof manner and then to obtain a vehicle-specific certificate from the latter, wherein the vehicle-specific private key never leaves this device.The method described requires that the public key of the vehicle certification authority is stored in the control device in a tamper-proof manner, and that the control device checks the received vehicle-specific certificate by checking at least the correctness of the signature of the vehicle-specific certificate with the public key of the vehicle certification authority. In this case, the vehicle-specific certificate is considered to be integrity-protected per se, since the digital signature contained in the certificate and generated by the vehicle certification authority can be checked at any time with the aid of the public key of the vehicle certification authority and any manipulation on the certificate can therefore be ascertained. For this reason, further integrity protection of the certificate is not necessary.In this way, the public key of the vehicle certification authority now forms a (relatively inflexible) security anchor or trust anchor in the control device, which has the consequence that the public key of the vehicle certification authority has to be stored in the control device in a tamper-proof manner, which in turn has the consequence that the public key of the vehicle certification authority in one control device cannot easily be reliably exchanged for another public key, which would be necessary in the case of a key exchange in the vehicle certification authority, however. The relatively inflexible tamper-proof storage of the public key of the vehicle certification authority in the control device and its use for checking the received vehicle-specific certificates therefore result in the vehicle certification authority, and here in particular its key pair, not being able to be readily changed or changed after tamper-proof storage of the public key in a control device.However, since the service life of the vehicles can amount to several decades, it can become advantageous or even necessary in this time, for example from a security point of view, to use a different asymmetric key pair and thus a different vehicle certification authority for signing vehicle-specific certificates. For example, it may be recommended by certain authorities, for example the Federal Office for Security in Information Technology (BSI), to no longer use a certain cryptographic method or a certain key length from a certain point in time. A changeover to a new key pair at the vehicle certification authority may also be necessary because, for example, the originally used signing method and / or the originally used key length no longer correspond to the prior art and are generally regarded as not secure enough.Because of the hurdles described above when replacing the public key of the vehicle certification authority in already produced vehicles and using the public key of the vehicle certification authority by the control devices for checking the received vehicle-specific certificates, a conversion of the vehicles or control devices already located in the field to another key pair and thus ultimately to another vehicle certification authority is not readily possible, since checking a signature produced with a new private key with the old public key stored in the control device would necessarily fail and the received certificate signed with the new private key would be discarded.The vehicles located in the field would thus be permanently bound to the original vehicle certification authority, and a changeover to another vehicle certification authority would not be possible without corresponding effort. This in turn leads to the vehicles located in the field being increasingly equipped with vehicle-specific certificates over time, which have been signed using legacy signing methods not corresponding to the prior art and / or using short private keys. Moreover, more and more different vehicle certification bodies would have to be operated over time, which would lead to a considerable increase in cost.The disadvantages mentioned are generally not only limited to vehicles or their control units, but also apply quite generally to all other ecosystems with systems comparable with regard to secure communication, on the one hand, and their at least one communication partner, on the other hand.Furthermore, DE 10 2020 205 933 A1 discloses a method for coupling an authentication means to a vehicle. For this purpose, an authentication means communicates with a control device of a vehicle for obtaining an authorisation, wherein at least one coupling is provided as soon as the authentication means is identified as authorised to the control device by means of an item of authentication information, for example a password. The authentication information can be generated for a first coupling by a server or a backend. The initial coupling is initiated by an operating unit arranged in the vehicle. The authentication information is preferably sent encrypted to the authentication means, wherein the authentication information is preferably sent encrypted by the authentication means to the control device.The object of the present invention is therefore to specify an improved method for securely providing a system with an individual certificate according to the preamble of claim 1, which makes its long-term use more flexible and secure.According to the invention, this object is achieved by a method having the features in claim 1 and here in particular in the characterizing part of claim 1. Further advantageous embodiments and developments of the method are specified in the dependent claims dependent thereon.In the method according to the invention, it is proposed, when issuing individual certificates for a set of systems, to supplement this certification authority (CA) by a so-called additional certificate signing authority (ACSA) equipped with an asymmetric key pair (ACSAPub, ACSAPriv) equipped with an asymmetric key pair (ACSA-Additionally Certificate Signing Authority) equipped with a different (CARootPub, CARootPriv) for a set of systems, the certificates (Cert) issued by the certification authority (CA) wish to be requested and received by the latter in order to equip them with the public key (ACSAPub) of the additional certificate signing authority (ACSA). This concerns the provision of certificates, and not their use for safeguarding communication. During the equipment, they are requested at the certification authority (CA) and subsequently, during the transmission of a certificate (Cert) issued by the certification authority (CA), to sign this certificate together with the signature from the additional certificate signing authority (ACSA) with its private key (ACSAPriv) and to transmit the signature (CertSi) generated in this way to the system requesting the certificate together with the generated certificate (Cert), subsequently checking the correctness of the received certificate (Cert) and of the received signature (CertSi) from the system requesting the certificate (Cert) with the aid of the public key (ACSAPub) of the additional certificate signing station (ACSA) stored there beforehand, the checking of the signature contained in the certificate (Cert) with the public key (CARootPub) of the certification station (CA) being dispensed with, and an exception treatment being initiated in the event of the checking failing.Even if the advantage may not be immediately evident at first glance, the method described here offers decisive advantages over the prior art, in particular over DE 10 2020 004 832 A1. Namely, the inventor has recognized that the checking of the received certificates (Cert) by the receiving system is not necessary to the extent it seems. This is because, from a security point of view, the receiving system does not have to trust the certification authority (CA) or its public key (CARootPub) or it has to check the received certificate (Cert) from a security point of view. Rather, the communication partner with which the control device subsequently communicates in a secured manner with the aid of the received certificate (Cert) must trust both the certification authority (CA) issuing the (Cert) and thus its public key (CARootPub) and must check the integrity of the certificate (Cert) previously received by the system and subsequently forwarded by the latter to its communication partner for the purpose of securing the communication with the aid of the public key (CARootPub) of the certification authority (CA).Thus, from a security point of view, at least with regard to confidentiality and integrity, it is possible to dispense with the checking of the signature of the received certificate (Cert) with the aid of the public key (CARootPub) of the certification authority (CA) by the system and thus with the (tamper-proof) storage of the public key (CARootPub) in the system described in DE 10 2020 004 832 A1.In the method according to the invention, instead of this, the certificate content is "signed", on the one hand the certificate body is signed with the private key of the certification authority and on the other hand the complete certificate is signed with the private key of the additional certificate signing authority. As a result, different signing methods and / or different public keys can be used for checking the certificate by the requesting / receiving system and for checking the certificate by the communication partner, which signing methods and / or different public keys can then be changed or exchanged independently of one another in each case at different times, depending on the requirements of the respective signing method and / or depending on the respective security goals. As a result, the certification authority can always use the most secure signing methods and key lengths corresponding to the prior art in coordination with the communication partners of the systems for certificate issue with little outlay, while the system can continue to use the old methods or keys for checking the received certificate.As explained above, it is not necessary from a security point of view that the receiving system trusts the certification authority (CA) or its public key (CARootPub), nor does it have to check the received certificate (Cert) from a security point of view. Only the communication partner of the system has to trust the certification authority (CA) and thus its public key (CARootPub) and check the integrity of the certificate (Cert) previously received by the system and subsequently forwarded by the latter to the communication partner with the aid of the public key (CARootPub).The lack of checking in the system now in principle increases the risk that a system accepts or stores an incorrect certificate, for example if it is sent an incorrect certificate, wherein both a specific manipulation by an attacker and a technical error or human failure can be the reason for the sending of an incorrect certificate. If an incorrect certificate is therefore stored in the system, the availability of the system in the communication may be impaired, since partners with which secure communication is to be carried out are potentially unavailable because of the incorrect certificate, because they do not accept an incorrect certificate and thus do not acknowledge the identity of the system.The communication partner of the system requires the highest possible security that the certificate present to him is actually the certificate of the system with which it is currently communicating. If this is not the case, the security of the communication partner is endangered because he or she may be familiar with an incorrect location. On the other hand, the risk associated with an incorrect certificate is substantially lower for the system itself. The risk of the system is merely that if it receives an incorrect certificate and uses it, its availability could be restricted because its communication partner does not recognize the certificate and thus no secured communication with the communication partner can be established. The confidentiality and integrity of the data of the system, which usually represents a considerably higher security goal, remain unaffected by this, however. It is therefore sufficient for the system if it trusts the additional certificate signing center (ACSA), which confirms to him by the signature that the received certificate is, according to its view, a correct certificate suitable for this system.If an attacker makes it possible to bypass this additional protection, for example by successfully manipulating the certificate and the additional signature, the damage that has occurred to both sides (system, communication partner) is limited, since the communication partner would easily recognize the certificate change on the basis of checking the signature contained in the certificate and generated by the certification authority (CA). It can thus be accepted that the method used for additional signing and the private key used in this case and thus the public key used for checking the additional signature may no longer fully correspond to the prior art over time, so that they can remain unchanged over a longer period of time, optionally even over the entire service life of a product equipped with the system, such as a vehicle, for example, as a result of which manipulation-proof storage of the public key used for checking the additional signature in the system is facilitated, for example.It should be noted that it is important that the signature contained in the certificate and generated by the certification authority (CA) is signed in the additional signing. If instead only the certificate's body were additionally signed, but not the signature generated by the certification authority (CA), the system cannot determine, by checking the additional signature, whether the signature of the received certificate generated by the certification authority (CA) is the original signature of the certification authority (CA), the additional signature would thus miss its purpose, since an attacker could easily impair the availability of the system in the sense described above by a manipulation of the signature contained in the certificate. For this reason, the cross certificates known from the literature, in which further certificates are issued by further certification bodies for a public key contained in a certificate, are not suitable for the method according to the invention, since in the cross certification the signatures generated by the first certification body are not signed again by the further certification bodies. The same applies analogously to certificates with multiple signatures, in which a certificate can contain signatures of a plurality of certification bodies, which in each case sign the same certificate body but not the signatures of the other certification bodies.It has thus been shown that it is expedient to sign the issued certificate an additional time and to dispense with checking of the signature contained in the certificate generated by the certification authority in the requesting system and instead to check only the correctness of the additional signature.It may be useful to check the received certificate from the requesting / receiving system to determine whether specific data contained in the certificate signing request (CSR) on which the issued certificate is based match the corresponding data in the received certificate (Cert), for example whether the public key contained in the certificate is equal to the public key contained in the certificate signing request (CSR) and / or whether, in the case of X.509 certificates, the common name (CN) contained in the certificate signing request (CSR) matches the common name (CN) contained in the certificate. According to a very advantageous embodiment of the method according to the invention, it is therefore provided to check, for at least one data field contained in the certificate signing request (CSR), by the system requesting / receiving the certificate (Cert), whether the value of this data field in the certificate signing request (CSR) transmitted to the certification authority (CA) corresponds in a suitable manner to the value of this data field in the received certificate (Cert).Any trusted entity from the perspective of the systems requesting / receiving the certificates, which is passed by the certificates in the transmission of the certificates from the certification authority (CA) to the requesting systems, can act as an additional certificate signing entity (ACSA), in particular it can be the certification entity (CA) or a registration entity (RA) if a registration entity (RA) is used and is involved in the distribution of the certificates. Such a registration point (RA) could be, for example, a backend of the vehicle manufacturer in the vehicle context or could be formed by such a backend.According to an advantageous development, it is therefore proposed to use the certification authority (CA) or the registration authority (RA) as an additional certificate signing authority (ACSA).In order for the additional signing to fulfil its purpose, the system receiving the certificate must trust the additional certificate signing center (ACSA), that is to say in particular that the additional certificate signing center (ACSA) must have knowledge about it or must be able to produce this knowledge by suitable checks whether the certificate to be transmitted is correct in the sense of the request of the receiving system. It may thus be useful to configure the additional certificate signing station (ACSA) such that it is capable of this purpose.A particularly advantageous development of the method according to the invention therefore provides for the additional certificate signing station (ACSA) to be implemented in such a way that it is capable of ascertaining whether the certificate (Cert) to be forwarded to the requesting / receiving system meets the requirements of this system, by, for example, the additional certificate signing station (ACSA) being (once) equipped with the public key (CARootPub) of the certification station (CA) and the correctness of the signature of a certificate (Cert) to be signed is checked by the additional certificate signing station (ACSA) before the calculation of the additional signature (CertSi) and / or, for each certificate (Cert) to be signed of the additional certificate signing station (ACSA), the certificate signing request (CSR) on which the certificate issue is based is made known in a manner, which permits a secure assignment of the certificate signing request (CSR) to the certificate (Cert) to be signed, in that, for example, the certificate signing request (CSR) is transmitted from the registration point (RA) or from the certification point (CA) to the additional certificate signing point (ACSA) in a suitably secured manner and subsequently from the additional certificate signing point (ACSA) to check whether the certificate (Cert) to be signed corresponds to the certificate signing request (CSR) in a suitable manner.Since the certification authority (CA) naturally knows both the CSR and its own public key (CARootPub), it can be particularly advantageous, as already proposed above, to implement the additional certificate signing authority (ACSA) as part of the certification authority (CA). Similar advantages result when implementing the additional certificate signing center (ACSA) as part of the registration center (RA), if present, since the registration center (RA) also naturally always knows the CSR and the public key (CARootPub) of the certification center (CA) can easily be transmitted to the registration center (RA) one time with integrity protection.The method according to the invention can now preferably be used in a vehicle ecosystem, so that the certification authority (CA) is designed as a vehicle certification authority (FCA) and the systems form the control units in the vehicle.Further advantageous embodiments of the method according to the invention are also evident from the remaining dependent dependent claims and become clear on the basis of the exemplary embodiments which are described in more detail below with reference to the figures.The following are shown: FIG. 1 is a diagram illustrating the core idea of the method of the present invention; FIG. 2 shows the schematic representation of an additional certificate signing station integrated into a certification station; FIG. 3 shows the schematic representation of an additional certificate signing station integrated into a registration station; FIG. 4 shows a diagram of a diagram analogous to the diagram in FIG. 1, in which a registration point is additionally provided; FIG. 5 is a diagram similar to the diagram in FIG. 4 in a vehicle ecosystem; and FIG. 6 is a diagram of a schematic for the detailed explanation of the method according to the invention in a vehicle ecosystem.The illustration in FIG. 1 shows a diagram for explaining the core idea of the method according to the invention. This comprises the system, the additional certificate signing station ACSA and the certification station CA. The system stores the public key ACSAPub of the additional certificate signing center ACSA, the additional certificate signing center ACSA has its key pair ASCAPub and ASCAPriv on the basis of its principle. The certification authority CA has its key pair CARootPub and CARootPr. In a first step, a certificate signing request, a so-called certificate signing request CSR, is now transmitted from the system to the certification authority CA. This generates a certificate Cert (CSR) corresponding to the certificate signing request CSR and transmits this to the additional certificate signing station ACSA. The latter signs the complete certificate with its private key ASCAPriv and transmits the signature CertGn and the certificate Cert together to the system. There, it is now sufficient to check the signature CertSi of the certificate created by the additional certificate signing center ACSA with the public key ACSAPub of the additional certificate signing center ACSA stored there, in order to guarantee sufficient security.The additional certificate signing station ACSA can now also be formed as part of the certification station CA, as a result of which an (external) step can be omitted, as is illustrated in FIG. 2. Alternatively, a registration point RA can also be placed on top, which in the vehicle context can be, for example, a backend of the vehicle manufacturer or can be formed by such a backend. As can be seen in FIG. 3, this registration point RA receives its certificate signing request CSR as the (primary) communication partner of the system and passes it on to the certification point CA. Otherwise, the sequence of the method is comparable to that of FIG. 1.FIG. 4 now shows an additional certificate signing station ACSA which is shown independently of the registration station RA and the certification station CA and which, however, could also be formed integrally analogously to FIGS. 2 or 3 and this will typically also be. However, for purposes of explanation, the separate illustration is more illustrative here. In order for the additional signing to fulfil its purpose, the system receiving the certificate Cert must trust the additional certificate signing center ACSA, that is to say in particular that the additional certificate signing center ACSA must have knowledge about it or must be able to produce this knowledge by suitable checks whether the certificate Cert to be signed and transmitted is correct in the sense of the request of the receiving system. For this purpose, it is now equipped with the public key CARootPub of the certification authority CA; in addition, the certificate signing request CSR on which the certificate Cert is based is transmitted to it by the registration authority RA. It can thus check the signature of the certificate Cert created by the certification authority CA, and it can also check whether the certificate Cert issued by the certification authority CA corresponds to the certificate signing request CSR.In the schematic of FIG. 5, the schematic is now transferred to preferred use in a vehicle ecosystem. The variables used are preceded by an F or an Fzg for this purpose. Otherwise, the sequence is to be understood analogously to that of FIG. 4. The system is formed by a control device with an identification GerID in a vehicle with the identification FzgID. All the other results analogously or by the sequence described in detail below with reference to FIG. 6. The terms are selected analogously to DE 10 2020 004 832 A1 already mentioned above.The diagram of FIG. 6, which ultimately represents a development of the diagram of DE 10 2020 004 832 A1, shows an indicated vehicle 1 twice, namely once denoted by 1' during production and once denoted by 1" during operation. A control device 2 is also shown several times, once denoted 2' during production, another time denoted 2" in the vehicle 1' during production thereof and another time in the vehicle 1" during operation. The control device 2 is then denoted there by 2'''. Also shown is an off-board server 3, e.g. a backend server of the respective OEM, a control device certification authority GCA and a vehicle certification authority FCA.The following steps are proposed in detail:A: Setting up a vehicle certification authority (FCA) for vehicle-specific certificates (once per specific fleet of vehicles) 1. an asymmetric vehicle root key pair (FzgRootPub FzgRootPr) is generated for the vehicle certification authority (FCA). 2. the private key FzgRootPr is stored in the vehicle certification authority (FCA) in a secure environment and used by the vehicle certification authority (FCA) for issuing / signing vehicle-specific certificates. 3. the public key (FzgRootPub) is distributed to all systems which are intended to be able to check certificates issued by the vehicle certification authority (FCA), for example to the backend and / or to a vehicle registration authority (FRA) with which the vehicles are intended to communicate securely.A': Setting up a vehicle registration point (FRA) with an additional certificate signing point (ACSA) for additionally signing vehicle-specific certificates (once per specific vehicle fleet) 1. an asymmetric key pair (ACSAPub, ACSAPriv) is generated for the additional certificate signing point (ACSA). 2. the private key (ACSAPriv) is stored in the additional certificate signing center (ACSA) in a secure environment and used by the additional certificate signing center (ACSA) for additionally signing vehicle-specific certificates issued by the vehicle certification center (FCA). 3. The public key (ACSAPub) is distributed to all controllers which are intended to be able to request and receive certificates issued by the vehicle certification authority (FCA). 4. the public key (ACSAPub) of the additional certificate signing station (ACSA) is stored in the control device in a tamper-proof manner.B: Setting up a device certification authority (GCA) (one time, for example, per controller manufacturer and a specific set of controllers to be produced by this manufacturer) 1. an asymmetric device root key pair (GerRootPub, GerRootPr) is generated for the device certification authority (GCA). 2. the private key (GerRootPr) is stored in the device certification authority (GCA) in a secure environment and used by the device certification authority (GCA) for issuing / signing certificates specific to the control device. 3. The public key (GerRootPub) is distributed to all systems which are intended to be able to check certificates issued by the device certification authority (GCA), for example to the vehicle registration authority (FRA).C: Equip the control device with initial cryptographic material, in particular with a control device-specific certificate (one time per control device with the individual identity (GerID), of the type (GerType), for example during its production) 1. a control device-specific key pair (GerIndPub, GerNdPriv) for the identity (GerID) is generated, preferably in a hardware security module (HSM) installed in this control device. 2. if the key pair is generated in the control device, the private key (GerlndPr) remains there. If the key pair is generated outside the control device, the private key (GerlndPr) is introduced into the control device on a route that is as secure as possible and does not leave it again. 3. the identity (GerID), the device type (GerType) and the public key (GerIndPub) are transmitted to the device certification authority (GCA), there a certificate (GerNdErt) is generated for the identity (GerID), the public key (GerIndPub) and the device type (GerType) with the aid of the private key (GerRootPr), wherein, for example, the identity (GerID) as part of the subject and device type (GerType) enter the certificate (GerlndErt) as an additional field ("Extension"), for example, and the entire data are signed with the private key (GerRootPr). 4. the certificate (GerlndErt) is transmitted from the device certification authority (GCA) back to the control device with the identity (GerID) and stored there.D: Acquisition of the vehicle identity and of the vehicle fingerprint (once per control device of the type (GerType) with the identity (GerID), during its installation in a vehicle with the identity (FzgID), for example, in the OEM) 1. During the installation of the control device with the identity (GerID) and the type (GerType) in a vehicle with the identity (FzgID), the data packet (FzgID, GerType, GerID) is acquired in a tamper-proof manner and is then transmitted to the vehicle registration point (FRA) in a tamper-proof manner. 2. the vehicle registration point (FRA) stores the data packet (FzgID, GerType, GerID) in a tamper-proof manner. 3. during the construction of the vehicle with the identity (FzgID), a tamper-proof individual digital fingerprint (FzgFA) of the vehicle is recorded in a secure environment and the data packet (FzgID, FzgFA) is transmitted to the vehicle registration location (FRA) in a tamper-proof manner. a. A variety of individual vehicle data, for example individual identities of various devices installed in the vehicle, preferably also data which are not back-documented, can be incorporated into the fingerprint, so that the latter cannot be reconstructed manually without further ado, e. b. The fingerprint must be designed such that it can be "reconstructed" at least partially by a control device installed in a vehicle during the operation thereof, by collecting the data flowing into the fingerprint, for example, from other control devices installed in the vehicle, for example, via the various vehicle buses. 4. the vehicle registration station (FRA) stores the data packet (FzgID, FzgFA) in a tamper-proof manner.E: Requesting and issuing a certificate during operation. If the vehicle requires one or a new certificate from the point of view of the control device with the identity (GerID), the following steps are carried out. 1. the control device with the identity (GerID) and the device type (GerType) a. ascertains its device-specific vehicle fingerprint (FzgFAGerSpez) by collecting the information necessary for this, b. ascertains the identity (FzgID) of the vehicle in which it is installed, c. generates a key pair (FzglndPub, FzgIndPr) for the individual vehicle certificate for the identity (FzgID), wherein the private key (FzgIndPriv) remains in the secure environment, d. creates a certificate signing request (CSR) for the data (FzgID, FzglndPub and GerType) e. generates the signature (Sign) by signing the data packet (CSR(FzglD FzglndPub, GerType), FzgFAGerSpez) with the individual control device key (GerlndPriv), f. sends the data packet ((CSR(FzglD FzglndPub, GerType), FzgFAGerSpez), Sign, GerlndCert(GerID GerlndPub, GerType)) to the vehicle registration point (FRA) 2. the vehicle registration point (FRA) (after receiving the data packet) a. checks, with the aid of the root key (GerRoPub) stored there, the correctness of the device-specific certificate (GerNdErt) b. extracts from the certificate signing request (CSR) the vehicle identity (FzgID), extracts from the device-specific certificate (GerNdErt) the device identity (GerID) and the device type (GerType) and checks whether an entry for (FzgID, GerType, in the backend, GerID), c. checks whether an entry (FzgID, FzgFA) is stored for the vehicle identity (FzgID), d. checks whether the device-specific vehicle fingerprint (FzgFAGerSpez) contained in the received message matches the general vehicle fingerprint (FzgFA), e. if one of the above checks fails: it initiates a special treatment, f. otherwise: it sends the received CSR (FzgID, FzglndPub, GerType) for the vehicle identity (FzgID) and the public key (FzglndPub) via a protected channel to the vehicle certification authority (FCA) i. The vehicle certification authority (FCA) uses the CSR (FzgID, FzglndPub, GerType) for the vehicle identity (FzgID) and the public key (FzglndPub) issues a certificate (FzglndErt) signed with (FzgRootPriv), and ii. the vehicle certification authority (FCA) sends the certificate (FzglndErt) back to the vehicle registration authority (FRA), wherein, in this exemplary embodiment, the vehicle registration center (FRA) also takes over the transmission of the certificates from the vehicle certification center (FCA) to the requesting control units. g. the additional certificate signing center (ACSA) installed in the vehicle registration center (FRA): i. checks the signature of the certificate (FzglndErt) with the public key (FzgRootPub) and the content of the certificate (FzglndErt) on the basis of the certificate signing request (CSR) ii. if one of the above checks fails: it initiates a special treatment, . otherwise: it signs the certificate (FzglndC) with the private key (ACSAPub) of the additional certificate signing center (ACSA) and generates the additional signature (FzglndCertSign) in the process, i.e. the vehicle registration center (FRA) returns the certificate (FzglndErt) and its additional signature (FzglndCertSign) to the control device with the identity (GerID) which is installed in the vehicle with the identity (FzgID). 3. the control device with the identity (GerID) a. checks the received certificate (FzglndErt), i.e. checks the correctness of the received additional signature (FzglndCertSign) with the public key (ACSAPub) of the additional certificate signing station (ACSA) ii. checks whether the received certificate (FzglndErt) corresponds to the transmitted CSR, i.e. whether (FzgID, FzglndPub, GerType) in both data structures match, b. fails one of the above checks to initiate an exception treatment, Otherwise, the certificate (FzglndErt) is stored locally 4th From now on, the control device with the identity (GerID) is in the own of a certificate issued to the vehicle identity and the associated private key and can carry out the tasks transmitted from the vehicle to this control device.

Claims

Method for securely providing systems with an individual certificate, wherein a certification authority (CA) is established on the basis of an asymmetric key pair (CARootPub, CARootPriv), characterized in that an additional certificate signing authority (ACSA) equipped with an asymmetric key pair (ACSAPub, ACSAPriv) different from the asymmetric Schlüsselpaar(CARootPub, CARootPriv) of the certification authority (CA) is also established, wherein the public key (ACSAPub) of the additional certificate signing authority (ACSA) is connected to all the systems, the certificates (Cert) issued by the certification authority (CA) are distributed thereby, request and receive, in order subsequently, in the course of the transmission of a certificate (Cert) issued by the certification authority (CA), to sign this certificate, together with the signature, from the additional certificate signing authority (ACSA) with its private key (ACSAPriv) and to transmit the signature (CertSi) thus generated to the system requesting the certificate together with the generated certificate (Cert), wherein the correctness of the received certificate (Cert) and of the received signature (CertSi) is checked by the system requesting the certificate (Cert) with the aid of the public key (ACSAPub) of the additional certificate signing station (ACSA) stored there beforehand, without checking the signature contained in the certificate (Cert) with the public key (CARootPub) of the certification station (CA), and wherein an exception treatment is initiated in the event of a failed checking of the received signature (CertSi).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) corresponds in a suitable manner to the value of this data field in the received certificate (Cert).Method according to Claim 1 or 2, characterized in that the certification authority (CA) or a registration authority (RA) forms the additional certificate signing authority (ACSA).Method according to claim 1, 2 or 3, characterized in that the additional certificate signing entity (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 satisfies the requirements of this system.Method according to Claim 4, characterized in that, for this purpose, the additional certificate signing station (ACSA), in particular once, is equipped with the public key (CARootPub) of the certification station (CA), and the correctness of the signature of a certificate (Cert) additionally to be signed is checked by the additional certificate signing station (ACSA) before the calculation of the additional signature (CertSi).Method according to Claim 4 or 5, characterized in that, for each certificate (Cert) to be signed of the additional certificate signing point (ACSA), the certificate signing request (CSR) on which the certificate issue is based is made known in a manner which allows a secure assignment of the certificate signing request (CSR) to the certificate (Cert) to be signed.Method according to Claim 6, characterized in that, for this purpose, the certificate signing request (CSR) is transmitted from the certification authority (CA) to the additional certificate signing authority (ACSA) in a suitably secured manner and it is then checked by the additional certificate signing authority (ACSA) whether the certificate (Cert) to be signed corresponds to the certificate signing request (CSR) in a suitable manner.Method according to Claim 6, characterized in that, for this purpose, the certificate signing request (CSR) is transmitted from the registration point (RA) to the additional certificate signing point (ACSA) in a suitably secured manner and the additional certificate signing point (ACSA) then checks whether the certificate (Cert) to be signed corresponds to the certificate signing request (CSR) in a suitable manner.Method according to one of Claims 1 to 8, characterized in that the private key (ACSAPriv) of the additional certificate signing centre (ACSA) is stored in the additional certificate signing centre (ACSA).Method according to claim 9, characterised in that the storage is effected in a read-protected manner.Method according to one of Claims 1 to 10, characterized in that the public key (ACSAPub) of the additional certificate signing entity (ACSA) is stored in the systems.Method according to claim 11, characterised in that the storage in the systems is effected in a manipulation-protected manner.Method according to one of Claims 1 to 12, characterized in that the distribution of the public key (ACSAPub) of the additional certificate signing entity (ACSA) to all the systems is effected in an integrity-protected manner.Method according to one of Claims 1 to 6, characterized in that control units in a vehicle are used as the systems.

Images