Method for authenticating data

Abstract

The present invention relates to a method for authenticating data (DAT13) transmitted between two of at least three instances (IZ1, IZ2, IZ3) in a system having these instances (IZ1, IZ2, IZ3), each of the instances (IZ1, IZ2, IZ3) having a unique identifier (IZ1_ID, IZ2_ID, IZ3_ID). The present invention is such that at least some of the instances (IZ1, IZ2, IZ3) each implement an authentication mechanism (AUTH12, AUTH23), and using the authentication mechanism (AUTH12, AUTH23), a first instance (IZ1) can authenticate itself to a second instance (IZ2) with respect to an adjacent instance (IZ2) that trusts the first instance (IZ1). Data (DAT13) transmitted from the first instance (IZ1) as the source instance (IZ1) to a non-adjacent target instance (IZ3) is authenticated by the source instance (IZ1) and delivered to an intermediate instance (IZ2) that trusts the source instance (IZ1). The intermediate instance (IZ2) checks the authentication, and if the check is positive, provides the data (DAT13) having the identifier (IZ1_ID) of the source instance (IZ1), re-authenticates the data (DAT13), and delivers it to an adjacent instance that trusts the intermediate instance (IZ2). This adjacent instance checks the authentication, and if the check is positive, re-authenticates the data (DAT13) having the identifier of the source instance (IZ1_ID) and delivers it to an adjacent instance that trusts this adjacent instance. This process is repeated until the transmitted data reaches the target instance (IZ3).

Description

Technical Field

[0001] The present invention relates to a method for authenticating data transmitted between two instances out of at least three instances in a system, wherein each of the instances has a unique identifier.

Background Art

[0002] Modern vehicles are today generally part of a so-called vehicle ecosystem. A central part of this system is a server external to the vehicle, so-called vehicle backend or briefly backend, which is usually operated as a manufacturer-specific server and often implemented on a commercial cloud. The vehicle is connected to this backend via the Internet. At this time, the communication between the backend and the vehicle is protected using well-known standard methods (mostly TLS, sometimes also IPSec). Subsystems or instances of this vehicle ecosystem are, for example, individual control devices (ECUs) attached to the vehicle, which in most cases communicate via an in-vehicle bus such as CAN, FlexRay, or Ethernet. Further instances of the vehicle ecosystem are smart terminals or applications running on those terminals (mostly manufacturer-specific OEM applications), which are operated, for example, on a smartphone and communicate with individual control devices and / or the backend inside the vehicle. The communication between applications and control devices inside the vehicle is in most cases carried out via NFC, WLAN, or Bluetooth (registered trademark), and the communication between the application and the backend is usually carried out via mobile radio such as UMTS, LTE, or 5G. Further subsystems or instances of the vehicle ecosystem may be manufacturer-specific external devices such as so-called OBD dongles, which usually communicate directly with individual control devices via a suitable interface inside the vehicle.

[0003] In this case, protecting the diverse communication relationships in such a vehicle ecosystem is usually as diverse as the communication relationships themselves. Many of these communication relationships are protected by standardized protocols such as TLS or IPSec. Bluetooth or WLAN connections have additional proprietary protection mechanisms, which are often complemented at the user level by manufacturer-specific protection mechanisms. In-vehicle communication between control devices is, in most cases, protected by SecOC.

[0004] In fact, at this time, the backend usually has a plurality of modules that communicate with the vehicle in the vehicle ecosystem. Generally, each vehicle is equipped with a telematics control unit (TCU) with a SIM card, which can establish an Internet connection to the backend or its modules. Certain control devices inside the vehicle communicate with external devices such as smartphones, laptops, dongles via NFC, Bluetooth, WLAN, or via the OBD2 socket that is installed as standard for on-board diagnosis in all modern vehicles. Additionally, these multiple external devices such as smartphones are usually also connected to the backend via a connection protected by TLS.

[0005] Basically, protecting the communication between the connected components of a vehicle ecosystem by encryption is known from the prior art and is described, for example, in Patent Document 1. Here, for example, end-to-end protection of communication using an appropriate encryption method can be considered. However, the drawback of this encryption method is usually that the encryption is not authenticated. This means that there is no certainty for the backend or one of its modules as the destination as to whether the received data was actually encrypted by this control device (ECU), or in the case of a download, whether the symmetric session key or transport key used for that request and its associated protection, etc., was actually sent from this control device.

[0006] To eliminate this vulnerability, it would also be necessary for the control device that communicates with the backend module by end-to-end encryption to be able to asymmetrically sign its messages. However, for this purpose, each control device would need to be equipped with a device-specific private key, the control device would need to be able to securely store its device-specific private key, for example, in a hardware security module (HSM), and the control device would need to be able to perform an asymmetric signing operation. At this time, it should be noted that the asymmetric signing operation has a very high CPU usage rate when using, for example, RSA, especially much higher than when checking digital signatures. That is, it is almost impossible for resource-constrained devices to execute this operation within a reasonable time.

[0007] In fact, many of the control devices attached to vehicles are resource-constrained devices. In particular, since they are not equipped with HSMs, it is technically impossible to securely store secrets such as device-specific private keys. Furthermore, many control devices are unable to provide the computational power required to calculate digital signatures quickly and efficiently using private keys.

Prior Art Documents

Patent Documents

[0008]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0009] Therefore, an object of the present invention is to identify a method for authenticating data in a system that minimizes these drawbacks.

Means for Solving the Problems

[0010] Based on the present invention, this problem is solved by the method having the features of claim 1, and in particular here the features described in the characterizing part of claim 1. Further advantageous embodiments become apparent from the dependent claims which depend on claim 1.

[0011] In the case of the method according to the present invention, according to a very advantageous embodiment of the method according to the present invention, a system which may be a vehicle ecosystem comprises various subsystems or instances. In the case of these instances of the system or the vehicle ecosystem, various communication mechanisms protected by various protection mechanisms are used for communication. That is, the entire system is very heterogeneous in terms of communication and its protection.

[0012] Furthermore, in this type of system, there are often hierarchical structures in many places, not limited to vehicle ecosystems in particular. For example, all the control devices which are individual instances of the system and are installed in the vehicle can be regarded as "the vehicle" from the back-end or the back-end module which is also an instance of the system. When a dongle or a smartphone is currently connected to the vehicle, for example, via Bluetooth, at this point, the dongle or the smartphone, or the application connected to the vehicle running on the smartphone can be understood as "the vehicle" when viewed from the back-end.

[0013] Next, there may be various trust relationships within such a system, and these trust relationships are often similarly hierarchically structured and technically realized or supported in various ways. For example, a second control device recognized as being attached to the same vehicle from a first control device may be classified as trustworthy for a control device attached to the vehicle. This is because it is assumed that the integrity of the entire system attached to the vehicle cannot be bypassed by trivial matters. That is, the present invention is based on the fact that it is not easy to introduce an unknown control device or an unauthorized control device into the vehicle. Further, for example, a control device trusts a smartphone connected to the control device via Bluetooth or an application executed on the smartphone. This is because the Bluetooth pairing with the smartphone is executed by a person who owns the vehicle key at the time of pairing and thus clearly has the authority to execute the pairing. Therefore, by using the Bluetooth security mechanism, the control device can be confident that the smartphone currently connected to the control device is the same as the smartphone permitted via Bluetooth pairing by an authorized person. Thereby, the control device can continue to trust this smartphone. On the other hand, for the same reason, the smartphone can also trust the control device connected to this smartphone. Similarly, for example, a trust relationship may exist between a control device attached to a vehicle, such as a telematics control unit, and a backend or a specific module within the backend. Further, if this control device has secrets such as, for example, a private approval key and an approval certificate belonging thereto, thereby, with respect to other systems and here particularly with respect to the backend or a specific backend module, this control device can surely authenticate itself. In this way, the backend can trust the message received from this control device and the information authenticated by this control device contained therein.In particular, due to the above appearance from the backend to the vehicle as a whole, this control device may be regarded from the backend as a trustworthy proxy for the entire vehicle, and thus in particular as a trustworthy proxy for all control devices attached to the vehicle.

[0014] For the reasons stated at the beginning, if the data transmitted from an individual control device cannot be directly authenticated by that control device against the target instance, the data transmitted from this instance can be authenticated via a further control device of the vehicle, such as a telematics control unit, or via another instance connected to the vehicle under a trust relationship. This further instance is a so-called intermediate instance that trusts the source instance transmitting the data. That is, the intermediate instance receives the data transmitted from the source instance, authenticates it by providing the identifier of the source instance, and can pass it on to a target instance, such as a backend module of the vehicle backend. If an individual control device in the vehicle cannot authenticate its own data, for example because the control device does not have the function of securely storing secrets and / or does not have the necessary computing power, the intermediate instance can be used to have its own data authenticated by the target system. That is, the authentication is delegated from the source instance to the intermediate instance. At the same time, in this process, the check of the authenticity of the data transmitted from the source instance is delegated from the target instance to the intermediate instance, which results in the target instance having to trust the intermediate instance.

[0015] In this case, in the method of the present invention, in principle, any number of intermediate instances can be provided between the source instance and the target instance. Therefore, the transmitted data is transmitted together with the identifier of the source instance, which is the source of the data transmitted through each intermediate instance, and at least the receiving-side intermediate instance among the intermediate instances trusts the transmitting-side intermediate instance. Of course, both instances can also trust each other. In this case, the first intermediate instance authenticates the data together with the identifier of the source instance, and the next intermediate instance checks the authentication of the received data together with the identifier of the source instance. If the check is positive, it newly authenticates the data together with the identifier of the source instance and delivers it to the next adjacent instance. This will continue until the data delivered from adjacent instance to adjacent instance reaches the target instance. That is, by this delegation of authentication, the data of instances not set for authentication can also be appropriately authenticated, thereby enhancing security. On the other hand, note that the authenticity check is delegated from each receiving-side instance to the transmitting-side adjacent instance.

[0016] Here, "adjacent" in the meaning of this specification means that when two instances implement a common authentication mechanism and the first instance can authenticate itself to the second instance using this, and the second instance trusts the first instance, the first instance is regarded as being adjacent to at least another instance, for example, the second instance. That is, "adjacent" has nothing to do with spatial proximity and is not a particularly symmetric relationship.

[0017] According to a particularly advantageous embodiment of the method according to the invention, three instances are provided. Of these instances, one is a source instance, one is a target instance, and one is an intermediate instance. In this case, a system, for example a vehicle ecosystem, can include more subsystems or instances than these three. However, in this method for authenticating data, only these three instances are used. This makes it possible to make the structure relatively simple and efficient because the data is checked and newly authenticated respectively over a long chain of intermediate instances without the need for new authentication.

[0018] That is, for a part of an existing system consisting of three instances each having an identifier, which may in particular be part of a vehicle ecosystem or such a system, a variant is proposed where there is a trust relationship both between a first instance as a source instance and an intermediate instance, and between the intermediate instance and a third instance as a target instance. In this case, the source instance and the intermediate instance implement a first authentication mechanism, using which the source instance can authenticate itself to the intermediate instance. The intermediate instance and the target instance implement a second authentication mechanism, using which the intermediate instance can authenticate itself to the target instance. Accordingly, data transmitted from the source instance to the target instance is first authenticated by the source instance using the first authentication mechanism and transmitted to the intermediate instance. The intermediate instance checks the authenticity of the data transmitted from the source instance using the first authentication mechanism. If the result of this check is positive, then the data is next combined with the identifier of the source instance, authenticated by the second authentication mechanism, and transmitted to the target instance. The target instance can check the authenticity of the combination consisting of the data and the identifier of the source instance by the second authentication mechanism. If the result of this check is positive, the target instance can use and / or further process the data as appropriate, and in this case, the data can be trusted to originate from the authentic source instance.

[0019] At this time, generally, it is not necessary to use the same authentication mechanism. Rather, the first and second authentication mechanisms may be different mechanisms, so the target instance cannot check the authenticity of the data authenticated by the source instance using the first authentication mechanism. This is because, for example, the target instance does not implement a compatible mechanism, and / or the target instance does not have the encryption material necessary to inspect the authenticity of the data authenticated by the source instance using the first authentication mechanism, and / or the preconditions of the first authentication mechanism, such as the local proximity between participating instances or the communication of participating instances via a specific bus, are not given to the source instance on the one hand and the target instance on the other hand. The local proximity can be detected, for example, according to Patent Document 2.

[0020] In this case, the source instance may be a smartphone that authenticates itself to an intermediate instance, such as a control device installed in a vehicle, using a Bluetooth mechanism. On the other hand, this control device as the intermediate instance implements an approval authentication mechanism. That is, here, if the intermediate instance owns an approval certificate associated with a secret approval key, it can authenticate itself to a target instance, such as a backend module, by means of them. At this time, the backend module as the target instance cannot inspect the Bluetooth authentication mechanism of the source instance. Therefore, for this reason, the target instance can assume that the transmitted data truly originates from the source instance only when the source instance trusts the intermediate instance, and this intermediate instance trusts that the data originates from the source instance. Additionally, this is the case where the target instance assumes that the second authentication mechanism used between the target instance and the intermediate instance is secure.

[0021] Furthermore, in a very advantageous further embodiment of the method according to the invention, at least one of the instances can be provided with at least one, usually a plurality of sub-instances having unique identifiers. In this case, this instance trusts at least this one sub-instance, where at least one sub-instance implements an authentication mechanism, using which the sub-instance can authenticate itself to the instance to which it belongs. That is, the method can be used not only appropriately in the chain of an instance and an intermediate instance, but also when branching from one instance to a plurality of further sub-instances, all of which are trusted by the instance. Therefore, these sub-instances can also serve as data sources for the source instance or the upper instance as the source instance.

[0022] A further very advantageous embodiment of the method according to the invention provides that at least one of the following authentication mechanisms is used. For example, authentication based on digital signatures can be adopted. As a supplement or alternative, authentication based on a symmetric method such as the MAC method can also be used. Also, in most cases, digital signals and / or Bluetooth, WLAN, NFC or SecOC based on a symmetric method, as well as the implementation mechanism of TLS, can also be the basis for authentication. However, in addition, authentication methods or mechanisms based on biometric methods using technologies that determine local proximity probabilistically and / or based on the use of a secure and trustworthy communication channel, rather than encryption methods and / or secrets, are also conceivable. Combinations are also conceivable here.

[0023] Here, as listed above, the authentication mechanism does not necessarily have to be based on an encryption method and / or a secret. Rather, other methods, such as a biometric method in particular, may be used. For example, one instance may be a combination of a mobile data carrier, such as a USB stick or a USB hard disk, and a person with a unique individual identifier, where the mobile data carrier stores the data to be transmitted. When the person connects the mobile data carrier to a compatible connection part of a head unit, which is a second instance installed in the vehicle, and a camera is connected to the head unit, if the person who connected the data carrier is uniquely identified by, for example, iris recognition by the camera, the head unit can thus determine which person connected the mobile data carrier. Next, the head unit, as an intermediate instance, can authenticate the data, for example, via TLS, by assigning the data to the person who connected the mobile data carrier, that is, by specifying the identifier of that person, and transmit it to a further instance, such as a back-end module, as the target instance.

[0024] Furthermore, the first instance may also be a person who directly inputs data via an input unit of a head unit installed in the vehicle, which is the next instance, and a camera is connected to this head unit. By this camera, the person who input the data is uniquely identified by iris recognition. In this way, the head unit, as the second instance, can determine which person input the data and transmit these data to a target instance, such as a back-end module, authenticated by an authentication mechanism, for example, via TLS, and specify the assignment of the data to the identifier of the person who input the data.

[0025] For the transmission of data from a source instance to an intermediate instance authenticated using a first authentication mechanism and the transmission of the identifier of the source instance and data from the intermediate instance to a target instance authenticated using a second authentication mechanism, depending on the types and natures of the two authentication mechanisms, additional data required for the receiving instance to check the authentication of each received data must be further transmitted from the source instance to the intermediate instance or from the intermediate instance to the target instance. For example, these additional data may be so-called authentication stamps such as digital signatures or message authentication codes (MACs).

[0026] Furthermore, as already mentioned, according to a highly advantageous embodiment of the method according to the invention, it is also provided to use, as an authentication mechanism for the target instance, authentication using the secret approval key and approval certificate of the instance transmitting the data. This transmission is particularly secure with respect to authentication and can be used, for example, by a TCU as an intermediate instance forming the central communication channel of the vehicle together with a backend or backend module.

[0027] In the method according to the invention in one embodiment, the data transmitted from the source instance is not protected against reading by an intermediate instance that verifies the authenticity of this data for the target instance. Therefore, according to a highly advantageous development of the method according to the invention, it is proposed that the encryption of the data transmitted between the source instance and the target instance be realized as so-called end-to-end encryption.

[0028] According to a highly advantageous development form of this, in this case, the target instance is equipped with an asymmetric decryption method and a corresponding asymmetric key pair, and the private key may be provided to be safely stored in the target instance. The source instance is equipped with a corresponding asymmetric encryption method and the public key of the target instance. The data transmitted from the source instance to the target instance can be directly encrypted with the public key using the encryption method before the data is transmitted to the target instance. Therefore, since at least one intermediate instance cannot read the data, end-to-end encryption can be realized in which the authentication can be delegated to an intermediate instance that trusts the source instance.

[0029] According to its corresponding further development form, the source instance is additionally provided with a symmetric encryption method, the target instance is provided with a corresponding symmetric decryption method, and a target decryption method may be provided before being transmitted to the intermediate instance. The data transmitted from the source instance to the target instance is encrypted by a symmetric key, a so-called transport key, which is newly generated safely, for example randomly, and conforms to the symmetric encryption and decryption methods before the data is transmitted to the target instance. This newly generated transport key is encrypted with the asymmetric public key of the aforementioned target instance for the source instance. Then, the source instance transmits the transport key encrypted in this way to the intermediate instance as part of the data to be authenticated.

[0030] That is, a modification of the method according to the present invention described so far provides that the public key of the target instance is provided to the source instance, where this public key is stored as a pure key and not as a certificate. Therefore, the introduction of this key needs to be done in a secure manner. That is, it must be guaranteed that it is well-known to the source instance that the public key belongs to the target instance, and also that both the information and the public key itself are protected against tampering in the source instance. However, in practice, this requirement can be relatively easily met if cryptographic material is first provided to the source instance. However, dynamically introducing a key later at runtime is correspondingly difficult. In particular, introducing the public key of a further communication partner incorporated into this system as a further target instance during the execution of the system is complex and difficult. However, this problem does not occur when the public key of the target instance used for encryption is introduced into the source instance in the form of a certificate. This is because in this case, it is sufficient if the public (root) key of the certification authority is securely introduced and integrity-protected storage is performed so that the integrity of all certificates introduced retroactively can be securely inspected at any time.

[0031] Therefore, according to a highly advantageous development of the method according to the invention, it is provided that a certification authority based on an asymmetric key pair is installed in the system. In this case, the root certificate of this certification authority contains the public key of the certification authority, and using this public key, the validity of the leaf certificate containing the public key used for actual encryption can be examined, and thus in particular the origin of the individual encryption keys or the attributes of the individual encryption keys to their respective target instances. Since the leaf certificates issued by the certification authority contain encryption keys, hereinafter these leaf certificates will also be referred to as encryption certificates. According to an advantageous development of the method according to the invention, in this case the certification authority is equipped with a protected interface, which enables the issuance of leaf certificates for the individual public keys belonging to the target instance. At this time, the public key contained in the leaf certificate is suitable for asymmetric encryption using the asymmetric encryption method, and the corresponding private key is suitable for decryption using the asymmetric encryption method. In this case, all leaf certificates issued by the certification authority of the target instance are appropriately stored in the certification authority or a third-party system connected to the certification authority. At this time, an acquisition interface is provided, through which the source instance can acquire or download the leaf certificate issued for the target instance from the certification authority or the third-party system. Furthermore, here, for all target instances of the system, using the protected interface, first a certificate containing the public key of each target instance is issued by the certification authority, and / or the target instance is given the option of having such a certificate issued by the certification authority using the protected interface. In this case, the public key of the certification authority is provided to all source instances of the system in a secure manner, and this public key is stored as a trust anchor for the leaf certificates issued by the certification authority, which become encryption certificates in the above-mentioned sense. Furthermore, all source instances of the system are also given the option of dynamically acquiring from the certification authority or the third-party system the necessary or additionally necessary leaf certificates of the target instances stored therein.

[0032] The use of such a certification authority and the use of the encrypted certificate issued by the certification authority enable data to be encrypted and transmitted to a newly added target instance or a target instance that was not yet known before the source instance was entrusted, which is a great advantage in actual use, especially in a dynamically changing system such as a vehicle ecosystem.

[0033] In this case, the acquisition interface itself does not necessarily have to be formed as a protected interface, which further simplifies the configuration or procedure.

[0034] Further advantageous embodiments of the method according to the invention and its variants are also apparent from the examples described in detail below with reference to the figures.

Brief Description of the Drawings

[0035]

Figure 1

Figure 2

Figure 3

Figure 4

Modes for Carrying Out the Invention

[0036] FIG. 1 schematically shows an exemplary vehicle ecosystem 1 having two vehicles Fzg1, Fzg2 and a backend consisting of two modules BEModulX, BEModulY. Each vehicle Fzg1, Fzg2 includes a telematics control unit (TCU) which includes a SIM card SIM and can establish an Internet connection to the backend protected directly by TLS. Specific control devices (ECUs) of the vehicles Fzg1, Fzg2 communicate with external devices ExtGer1 to ExtGer6 such as smartphones, laptops, dongles, etc. via near-field wireless communication NFC, Bluetooth BT, WLAN and / or in-vehicle diagnostic socket OBD. On the other hand, a plurality of external devices ExtGerA, ExtGerB, ExtGerC such as smartphones, laptops, etc. are connected to the backend via a connection protected by TLS. In this case, all TCUs, ECUs, and the backend or its modules BEModulX, BEModulY become subsystems or instances IZi of the vehicle ecosystem 1, similar to the external devices ExtGer1 to ExtGer6 and the external devices ExtGerA, ExtGerB, ExtGerC. At this time, 1 ≦ i ≦ n, where n is an arbitrary natural number.

[0037] In the following, a method for authenticating data in such a vehicle ecosystem 1 having a plurality of instances IZi will be described using the example of three participating subsystems or instances IZ1, IZ2, IZ2. However, it is of course possible to use additional instances IZi.

[0038] In this example, in the vehicle ecosystem 1, three different instances IZ1, IZ2, and IZ3 with unique identifiers IZ1_ID, IZ2_ID, and IZ3_ID become active. There is at least a one-way trust relationship between the first instance IZ1 and the second instance IZ2, and between the second instance IZ2 and the third instance IZ3. In both cases, that is, the second instance IZ2 must trust the first instance IZ1, and the third instance IZ3 must trust the second instance IZ2. Therefore, the first and second instances IZ1, IZ2, and the second and third instances IZ2, IZ3 are adjacent instances in the sense of this specification. An authentication mechanism AUTH12 is implemented between instances IZ1 and IZ2, and IZ1 can use this to authenticate itself to IZ2. Similarly, an authentication mechanism AUTH23 (optionally another one) is implemented between instances IZ2 and IZ3, and IZ2 can use this to authenticate itself to IZ3.

[0039] The schematic diagram of FIG. 2 shows these three instances and the object based on this method. This object is composed of an authenticated transmission of data DAT13 from a first instance IZ1 as a source instance IZ1 to a third instance IZ3 as a target instance IZ2, as shown by the dashed arrow. However, the source instance is a control device (ECU) that has no option to securely store secrets and also has no computing power for proper authentication for the target instance IZ3. Therefore, the data DAT13 transmitted from the source instance IZ1 to the target instance IZ3 is first authenticated by the source instance IZ1 by an authentication mechanism AUTH12 that does not require secrets and is transmitted to the intermediate instance IZ2. Then, the authentication of the transmitted data is checked by the intermediate instance IZ2 using the authentication mechanism AUTH12. If the result of this check is positive, the combination of the data DAT13 and the identifier IZ1_ID of the target instance is authenticated using the authentication mechanism AUTH23 and transmitted from the intermediate instance IZ2 to the target instance IZ3. Next, here, the authenticity of the combination consisting of the data DAT13 and the identifier IZ1_ID is checked by the target instance IZ3 using the authentication mechanism AUTH23. If the result of this check is positive, the target instance IZ3 can believe that the data DAT13 was truly received from the source instance IZ1 and can accordingly process or use the data.

[0040] At this time, generally, the authentication mechanisms AUTH12 and AUTH23 are different mechanisms, and the target instance IZ3 cannot verify the authenticity of the data authenticated by the source instance IZ1 using the authentication mechanism AUTH12. This is because, for example, the target instance IZ3 does not implement the mechanism AUTH12, and / or the target instance IZ3 does not have the encryption materials necessary to verify the authenticity of the data authenticated by the source instance IZ1 using the authentication mechanism AUTH12, and / or one of the preconditions of the authentication mechanism AUTH12, such as the local proximity between participating instances or the communication of participating instances via a specific bus, is not provided for the source instance IZ1 and the target instance IZ3. For example, when the source instance IZ1 is not a control device but a smartphone, this smartphone authenticates itself to an intermediate instance IZ2, which is, for example, a control device installed in a vehicle, using a Bluetooth mechanism. Also, this control device as the intermediate instance IZ2 has an approval authentication mechanism implemented. Therefore, the intermediate instance IZ2 owns a secret approval key and its corresponding certificate, and by these, the intermediate instance IZ2 can authenticate itself to, for example, a target instance IZ3 that is a backend module. In this case, the backend module as the target instance IZ3 cannot inspect the Bluetooth authentication AUTH12 of the source instance. For this reason, the target instance IZ3 can assume that the data DAT13 truly originates from the source instance IZ1 only when the source instance IZ1 trusts the intermediate instance IZ2, and this intermediate instance IZ2 is convinced that the data DAT13 originates from the source instance IZ1, and the target instance IZ3 assumes that the authentication mechanism AUTH23 is secure.

[0041] Both the authentication authorities AUTH12 and AUTH23 are based on authentication stamps such as digital signatures or MACs, that is, they generate an authentication stamp and inspect it (at this time, AUTH12_GEN or AUTH23_GEN indicates the function belonging to AUTH12 or AUTH23 for generating the authentication stamp, and AUTH12_VER or AUTH23_VER indicates the function belonging to AUTH12 or AUTH23 for checking (verifying) the authentication stamp), and also, both AUTH12 and AUTH23 already implicitly contain the necessary encryption materials, that is, under the special assumption that the necessary encryption materials are not explicitly specified as parameters, the proposed method consists of the following steps. · In the source instance IZ1, - The authentication stamp AuthSt12 of the data DAT13 is calculated by AUTH12_GEN, that is, AuthSt12 := AUTH12_GEN(DAT13), - The message (DAT13, AuthSt12) is transmitted to the intermediate instance IZ2. · In the authenticated intermediate instance IZ2 after receiving (DAT13, AuthSt12), - The validity of the received authentication stamp AuthSt12 of the received data DAT13 is checked by AUTH12_VER, that is, the boolean value AUTH12_VER(DAT13, AuthSt12) is calculated, - If the check is positive, the authentication stamp AuthSt23 of the combination of the data DAT13 and the identifier IZ1_ID of IZ1, that is, (DAT13, IZ1_ID), is calculated using AUTH23_GEN, that is, (AuthSt23 := AUTH23_GEN((DAT13, IZ1_ID))), otherwise, special processing is started, - The message (DAT13, IZ1_ID, AuthSt23) is transmitted to the source instance IZ3. · In the target instance IZ3 after receiving (DAT13, IZ1_ID, AuthSt23), - The authenticity of the received authentication stamp AuthSt23 of the received data (DAT13, IZ1_ID) is checked by AUTH23_VER, i.e., the boolean value AUTH23_VER((DAT13, IZ1_ID), AuthSt23) is calculated. - If the check is positive, the data DAT13 is assumed to be from IZ1, and accordingly the data DAT13 is used; otherwise, special processing is started.

[0042] In the presented method, the data DAT13 sent from the source instance IZ1 is not protected as it is read by the intermediate instance IZ2 that determines the authenticity of this data DAT13 for the target instance IZ3. From common prior art, it is known to protect data exchanged between two instances of, for example, the vehicle ecosystem 1, by end-to-end encryption based on asymmetric encryption, etc. For example, the target instance IZ1 can encrypt the data DAT13 before transmitting it to the intermediate instance IZ2, thereby protecting the data from read access by the intermediate instance IZ2. In the combination of delegating the authentication of the data DAT13 from the source instance IZ1 to the intermediate instance IZ2 and the target instance IZ3 as described above, the procedure schematically shown in Figure 3 is performed.

[0043] As a special version of this method, it is possible to provide the target instance IZ3 with an asymmetric decryption method AsymmDECR and an asymmetric key pair (IZ3Pub, IZ3Priv) that matches it. The private key IZ3Priv is securely stored within the target instance IZ3, and the source instance IZ1 is provided with an asymmetric encryption method AsymmENCR corresponding to the decryption method AsymmDECR and the public key IZ3Pub of the source instance IZ3. The data DAT13Plain transmitted from the source instance IZ1 to the target instance IZ3 is directly encrypted using the encryption method AsymmENCR by the public key IZ3Pub before being transmitted to the target instance IZ3. As an alternative to this, additionally, a symmetric encryption method SymmENCR can be provided to the source instance IZ1, and a symmetric decryption method SymmDECR corresponding to the encryption method SymmENCR can be provided to the target instance IZ3. Next, the data DAT13Plain transmitted from the source instance IZ1 to the target instance IZ3 can be encrypted with a newly generated secure, for example random, symmetric key that matches the encryption and decryption methods SymmENCR / SymmDECR, a so-called transport key, before being sent to the intermediate instance IZ2. Subsequently, this newly generated transport key is encrypted with the asymmetric public key IZ3Pub, and it is sufficient to transmit the transport key encrypted in this way together with the authenticated data DAT13 as part of the intermediate instance IZ2.

[0044] Both AUTH12 and AUTH23 are based on an authentication stamp such as a digital signature or MAC, i.e., they generate an authentication stamp and check it (where AUTH12_GEN or AUTH23_GEN represents the function belonging to AUTH12 or AUTH23 for generating the authentication stamp, and AUTH12_VER or AUTH23_VER represents the function belonging to AUTH12 or AUTH23 for checking (verifying) the authentication stamp). Under the special assumption that both AUTH12 and AUTH23 already implicitly contain the necessary encryption material, i.e., the necessary encryption material is not explicitly specified as a parameter, a second variant of the proposed method, i.e., the variant using a symmetric transport key, consists of the following steps. · At the source instance IZ1, - A new symmetric transport key transpKey is generated using a secure method, - The data DAT13Plain to be transmitted is encrypted using transpKey by SymmENCR, i.e., DAT13ENCR := SymmENCR(transpKey, DAT13Plain), - The transport key transpKey is asymmetrically encrypted using IZ3Pub by AsymmENCR, i.e., transpKeyENCR := AsymmENCR(IZ3Pub, transpKey), - The data DAT13 to be transmitted determined for IZ3 is formed as a combination of DAT13ENCR and transpKeyENCR, i.e., DAT13 := (DAT13ENCR, transpKeyENCR), - The authentication stamp AuthSt12 of the transmitted DAT13 is calculated by AUTH12_GEN, i.e., AuthSt12 := AUTH12_GEN(DAT13), - The message (DAT13, AuthSt12) is transmitted to IZ2. · At the authenticated intermediate instance IZ2 after receiving (DAT13, AuthSt12)), - The authenticity of the received authentication stamp AuthSt12 of the received data DAT13 is checked by AUTH12_GEN, i.e., the boolean value AUTH12_VER(DAT13, AuthSt12) is calculated. - If the check is positive, the authentication stamp AuthSt23 of the combination of the data DAT13 and the identifier IZ1_ID of IZ1, i.e., (DAT13, IZ1_ID), is calculated using AUTH23_GEN, i.e., (AuthSt23 := AUTH23_GEN((DAT13, IZ1_ID))), otherwise, special processing is started. - The message (DAT13, IZ1_ID, AuthSt23) is transmitted to IZ3. · At the target instance IZ3 after receiving (DAT13, IZ1_ID, AuthSt23), - The authenticity of the received authentication stamp AuthSt23 of the received data (DAT13, IZ1_ID) is checked by AUTH23_VER, i.e., the boolean value AUTH23_VER((DAT13, IZ1_ID), AuthSt23) is calculated. - If the check is positive, two components DAT13ENCR and transpKeyENCR are extracted from DAT13, otherwise, special processing is started. - The transpKeyENCR is decrypted using the private key IZ3Priv, thereby determining the transport key transpKey, i.e., transpKey := AsymmDECR(IZ3Priv, transpKeyENCR). - Using the transport key transpKey, DAT13ENCR is decrypted, thereby determining the usage data DAT13Plain, i.e., DAT13Plain := SymmDECR(transpKey, DAT13ENCR). - It is assumed that the data DAT13Plain is derived from IZ1, and accordingly, the data DAT13Plain is used.

[0045] In a variant of the present method with the described encryption, the source instance IZ1 is provided with the public key IZ3Pub of the target instance IZ3. If this public key IZ3Pub is stored as a pure key rather than a certificate, the introduction of this key needs to be done in a secure manner. In particular, the source instance IZ1 must be sure to know that the key IZ3Pub belongs to the target instance IZ3. Also, both that information and the key IZ3Pub itself must be protected from tampering at the source instance IZ1. These requirements can be relatively easily met if encryption material is first provided to the source instance IZ1, but during execution, the dynamic introduction of such keys, especially the introduction of public keys belonging to additional communication partners, makes it extremely difficult.

[0046] Therefore, it may be useful to install an encryption certification authority ENCR-CA for leaf certificates containing asymmetric public encryption keys within the vehicle ecosystem 1. The root certificate EncrRootCert of this certification authority ENCR-CA contains the public key EncrRootPub of the certification authority ENCR-CA. Using this public key EncrRootPub, the validity of the leaf certificate EncrIndCert containing the actual encryption key EncrIndPub and, thereby, in particular, the origin of the encryption key EncrIndPub or its belonging to each target instance can be inspected. Since the leaf certificates issued by the certification authority ENCR-CA contain encryption keys, hereinafter, these leaf certificates are also referred to as encryption certificates.

[0047] Figure 4 shows the provisioning of an instance IZi of the exemplary vehicle ecosystem 1, which is provided with a certification authority ENCR-CA and a certification service Cert-Service implemented by a third-party system and used to distribute leaf certificates issued by the certification authority ENCR-CA. Here, it is assumed that the same certification authority ENCR-CA is used for all target instances IZ3 (BEModulX, BEModulY, ExtGerA). Further, Figure 4 also shows the state after each individual instance IZi has been provided with approved cryptographic material, i.e., individual secret approval keys, individual approval certificates, root approval certificates, etc. Here, it is assumed that the individual approval certificates of all instances IZ2 (ExtGer2, ExtGerβ, TCU) to be authenticated are issued from the same approval certification authority END-CA, i.e., signed using the same secret root key EndRootPriv.

[0048] To equip all instances IZ1, IZ2, IZ3 with the necessary certificates, the system configuration is designed such that an encryption certification authority ENCR-CA based on an asymmetric key pair (EncrRootPub, EncrRootPriv) is installed within the vehicle ecosystem 1. The encryption certification authority ENCR-CA is provided with a protected interface GENCERT, which enables the issuance of leaf certificates EncrIndCertIZ3 for the individual public keys EncrIndPubIZ3 belonging to the target instance IZ3. At this time, the public key EncrIndPubIZ3 included in the leaf certificate is suitable for asymmetric encryption using the asymmetric encryption method AsymmENCR, and the corresponding secret key EncrIndPrivIZ3 is suitable for decryption using the asymmetric decryption method AsymmDECR.

[0049] All leaf certificates issued by the encryption certification authority ENCR-CA for the target instance IZ3 are stored or saved within the encryption certification authority ENCR-CA or within a third-party system connected to the encryption certification authority ENCR-CA. An (not necessarily protected) acquisition interface GETCERT is installed, through which the source instance IZ1 can directly download or obtain the leaf certificate issued for the target instance IZ3 from the encryption certification authority ENCR-CA or from the third-party system storing the leaf certificate. As already pointed out, in this case, the acquisition interface GETCERT does not need to be protected. This is because the leaf certificate is protected against tampering by the signature with EncrRootPriv, and the information contained in the certificate is usually not confidential, i.e., it is public.

[0050] Furthermore, all source instances IZ3 of the vehicle ecosystem 1 are provided with individual asymmetric key pairs (EncrIndPubIZ3, EncrIndPrivIZ3) suitable for encryption or decryption, and the private key EncrIndPrivIZ3 is intended to be stored within the target instance IZ3 to protect against unauthorized reading. For this purpose, for all target instances IZ3 of the vehicle ecosystem 1, a protected interface GENCERT is used to first issue individual certificates containing the individual public key EncrIndPubIZ3 (signed with EncrRootPriv) from the certification authority, and / or the target instance IZ3 is given the option to issue such a certificate from the encryption certification authority ENCR-CA at runtime using GENCERT.

[0051] For all source instances IZ1 of the vehicle ecosystem 1, the public key EncrRootPub of the encryption certification authority ENCR-CA is provided in a secure manner (initially or at runtime), which is stored in each source instance IZ1 in an unforgeable manner as the trust anchor of the leaf certificate (encryption certificate) issued by the encryption certification authority ENCR-CA. Furthermore, all source instances IZ1 of the vehicle ecosystem 1 are intended to be provided with the option of dynamically, i.e., at runtime, obtaining or receiving the leaf certificate of the target instance IZ3 that needs to be stored there or additionally needs to be stored, from the encryption certification authority ENCR-CA or a third-party system.

[0052] During operation, for each target instance IZ3 that wants to receive and decrypt the data encrypted by the source instance IZ1, if its encryption certificate EncrIndCertIZ3 is not yet in the encryption certification authority ENCR-CA or in the third-party system storing the encryption certificate, the generation of the encryption certificate EncrIndCertIZ3 by the encryption certification authority ENCR-CA and the storage in the encryption certification authority ENCR-CA or the third-party system are started via the protected interface GENCERT.

[0053] Each source instance IZ1 that wants to encrypt the data DAT13Plain and send it to the target instance IZ3 performs the following steps. · If the encryption certificate of the target instance IZ3 is not yet in the source instance IZ1 or if this encryption certificate is updated, the source instance IZ1 downloads the latest encryption certificate EncrIndCertIZ3 from the encryption certification authority ENCR-CA or a third-party system using the acquisition interface GETCERT. · The source instance IZ1 checks the validity of the downloaded encrypted certificate EncrIndCertIZ3 using the public key EncrRootPub of the encrypted certification authority ENCR-CA, which is protected against tampering and stored within the source instance IZ1. At this time, the key EncrRootPub may be part of the root certificate EncrRootCert (as shown in Figure 4). · If the check of the encrypted certificate EncrIndCertIZ3 is positive, the public key EncrIndPubIZ3 of the target instance IZ3 contained within the encrypted certificate EncrIndCertIZ3 is extracted, and encryption is continued according to the method described above by using the key EncrIndPubIZ3 extracted from the encrypted certificate EncrIndCertIZ3 as the asymmetric key IZ3Pub. If the check is negative, special processing is started.

[0054] It should be noted that there may be multiple third-party systems within the vehicle ecosystem 1 that store the encrypted certificate EncrIndCertIZ3 so that the source instance IZ1 can obtain the encrypted certificate EncrIndCertIZ3 as comfortably as possible. In particular, a third party that includes all or part of the available encrypted certificates EncrIndCertIZ3 may be installed, for example, within the vehicle control device, which enables the control devices attached to the same vehicle to obtain the encrypted certificate EncrIndCertIZ3 particularly easily.

[0055] The previous description of this method assumes that the encryption certification authority ENCR-CA only supports root and leaf certificates and does not support intermediate certificates. However, this method can be extended to a certificate chain that traces back to the encryption certification authority ENCR-CA in a clear way. In this case, when generating the encrypted certificate EncrIndCertIZ3 using the protected interface GENCERT, it may be necessary to generate additional intermediate certificates as needed. Also, when obtaining the encrypted certificate EncrIndCertIZ3 using the acquisition interface GETCERT, instead of one encrypted certificate EncrIndCertIZ3, a certificate chain including the encrypted certificate EncrIndCertIZ3 may be returned as needed, and then this certificate chain is fully inspected by the target instance IZ1 using the public root key EncrRootPub of the encryption certification authority ENCR-CA stored therein.

[0056] The acquisition interface GETCERT that can be used to obtain the encrypted certificate EncrIndCertIZ3 can be implemented in various ways. In particular, as described in RFC7517, a service that returns JSON Web Key (JWK) may be implemented, and a certificate chain of any length can also be returned.

[0057] The considerations made for the encryption certification authority ENCR-CA can also be applied to the approval certification authority END-CA that simplifies the use of the approval certificates mentioned above.

[0058] For this purpose, the approval certification authority END-CA is set up. Next, an individual asymmetric secret approval key EndIndPrivIZ2 and its corresponding individual approval certificate EndIndCertIZ2 issued by the approval certification authority END-CA are provided to the approval-certifiable instance or intermediate instance IZ2 (e.g., ExtGer2, ECUβ, TCU) (shown in Figure 4), or a certificate chain issued by the approval certification authority END-CA is provided, and the leaf certificate of the certificate chain corresponds to EndIndPrivIZ2 (not shown in the figure).

[0059] The encryption certification authority ENCR-CA is set by generating an asymmetric key pair (EncrRootPub, EncrRootPriv) and, if necessary (as shown in Figure 4), generating a self-signed root certificate EncrRootCert containing the public key EncrRootPub. The public root key EndRootPub of the approval certification authority END-CA is distributed to all target instances IZ3 (e.g., BEModulX, BEModulY, ExtGerA) that are able to check the signature generated using the secret approval key (e.g., initially, as the raw public key or a self-signed root certificate EndRootCert (shown in the figure) containing this key, etc.), where it is stored as a non-forgeable trust anchor.

[0060] The public root key EncrRootPub of the approval certification authority ENCR-CA is distributed to all source instances IZ1 (ExtGer1, ExtGer2, ExtGer3, ECUα, ECUβ, TCUA) that want to send data encrypted using the public key contained in the encryption certificate to one of the target instances IZ3 (e.g., initially, as the raw public key or a self-signed root certificate EncrRootCert (shown in the figure) containing this key, etc.).

[0061] The individual secret approval key EndIndPrivIZ2 and the corresponding approval certificate EndIndCertIZ2 are generated in a well-known manner and introduced into the intermediate instance IZ2. The encryption certificate can be generated, for example, as follows. That is, each of the target instances IZ3 (as shown in the figure) generates an individual key pair (EncrIndPubIZ3, EncrIndPrivIZ3), and subsequently, a certificate signing request (CSR) EncrIndCSRIZ3 containing the public key EncrIndPubIZ3 can be sent to the encryption certification authority ENCR-CA using the interface GENCERT in an authenticated manner (not shown in the figure), whereby this encryption certification authority ENCR-CA generates an individual encryption certificate EncrIndCertIZ3 from the certificate signing request. Alternatively, as an alternative (not shown in the figure), a further trustworthy system (which may or may not be the encryption certification authority ENCR-CA) generates an individual key pair (EncrIndPubIZ3, EncrIndPrivIZ3), introduces the private key EncrIndPrivIZ3 into the target instance IZ3 in a secure manner, sends a certificate signing request EncrIndCSRIZ3 containing the public key EncrIndPubIZ3 to the encryption certification authority ENCR-CA in an authenticated manner, whereby this certification authority ENCR-CA generates an individual encryption certificate EncrIndCertIZ3 from the CSR. The encryption certificates generated by the encryption certification authority ENCR-CA are transmitted to and stored in the encryption certificate distribution service Cert-Service. In this way, the source instance IZ1 can obtain or download the required encryption certificates from the encryption certificate distribution service Cert-Service using the acquisition interface GETCERT as needed.

[0062] The previous considerations regarding the certificate chain equally apply to the considerations related to the approval certification authority and can be easily adapted to the certificate chain as well.

Claims

Claim 1 In a system having at least three instances (IZ1, IZ2, IZ3), a method for authenticating data (DAT13) transmitted between two of these instances (IZ1, IZ2, IZ3), wherein each of the instances (IZ1, IZ2, IZ3) has a unique identifier (IZ1_ID, IZ2_ID, IZ3_ID), at least some of the instances (IZ1, IZ2, IZ3) each implement an authentication mechanism (AUTH12, AUTH23), and using the authentication mechanism (AUTH12, AUTH23), a first instance (IZ1) can authenticate itself to an adjacent instance (IZ2) that trusts the first instance (IZ1), and data (DAT13) transmitted from the first instance (IZ1) as a source instance (IZ1) to a non-adjacent target instance (IZ3) is authenticated by the source instance (IZ1) and delivered to an intermediate instance (IZ2) that trusts the source instance (IZ1), and the intermediate instance (IZ2) checks the authentication, and if the check is positive, provides the data (DAT13) having the identifier (IZ1_ID) of the source instance (IZ1), re-authenticates the data (DAT13) and delivers it to an adjacent instance that trusts the intermediate instance (IZ2), and the adjacent instance checks the authentication, and if the check is positive, re-authenticates the data (DAT13) having the identifier of the source instance (IZ1_ID) and delivers it to an adjacent instance that trusts the adjacent instance, and this process is repeated until the transmitted data reaches the target instance (IZ3). Claim 2 The method according to claim 1, characterized in that three instances (IZ1, IZ2, IZ3) are provided, one forming the source instance (IZ1), one forming the target instance (IZ3), and one forming the intermediate instance (IZ2). Claim 3 At least one of the instances (IZ1, IZ2, IZ3) comprises at least one sub-instance having a unique identifier, the instances (IZ1, IZ2, IZ3) trust at least one of their sub-instances, and at least one of the sub-instances implements an authentication mechanism, and using the authentication mechanism, the sub-instance can authenticate itself to the instance (IZ1, IZ2, IZ3) to which the sub-instance belongs. The method according to claim 1 or 2, characterized in that.

4. The following authentication mechanisms (AUTH12, AUTH23), namely, Authentication based on digital signature, Authentication based on symmetric method, Authentication based on Bluetooth, Authentication based on WLAN, Authentication based on NFC, Authentication based on SecOC, Authentication based on TLS, Authentication based on biometric method, Authentication based on locally established proximity using technology, and / or Authentication based on the use of a secure and trustworthy communication channel The method according to any one of claims 1 to 3, characterized in that at least one of them is used.

5. As an authentication mechanism (AUTH12, AUTH23) of an intermediate instance for another intermediate instance or for the target instance (IZ3), authentication using the secret approval key and approval certificate of the instance (IZ1, IZ2) that transmits the data (DAT13) is used. The method according to any one of claims 1 to 4, characterized in that.

6. The data (DAT13) to be transmitted is encrypted by the source instance (IZ1) and decrypted only for the target instance (IZ3). The method according to any one of claims 1 to 5, characterized in that encryption is used.

7. The target instance IZ3 is provided with an asymmetric key pair compatible with the asymmetric decryption method, the secret key of the key pair is securely stored in the target instance, and the source instance is provided with the corresponding asymmetric encryption method and the public key of the key pair. The method according to claim 6, characterized in that the source instance can encrypt the data to be transmitted.

8. In addition, a symmetric encryption method is provided for the source instance, and a corresponding symmetric decryption method is provided for the target instance. Before being transmitted, the data to be transmitted is encrypted by a newly generated secure or random transport key by the source instance, and the transport key is encrypted by the public key of the asymmetric key pair and transmitted together with the encrypted data to be transmitted. The method according to claim 7, characterized in that.

9. A certification authority based on an asymmetric root key pair is installed in the system. The certification authority (ENCR-CA) is provided with a protected interface (GENCERT), which enables the issuance of leaf certificates for individual public keys belonging to the target instance (IZ3). The public keys included in the leaf certificates are suitable for asymmetric encryption using an asymmetric encryption method (AsymmENCR), and the corresponding private keys are suitable for decryption using the asymmetric decryption method (AsymmDECR). All leaf certificates issued from the certification authority (ENCR-CA) for the target instance are stored in the certification authority (ENCR-CA) or a third-party system connected to the certification authority (ENCR-CA), and an acquisition interface (GETCERT) is provided. Through this, the source instance can download the leaf certificate issued for the target instance from the certification authority (ENCR-CA) or the third-party system. For all target instances of the system, using the protected interface (GENCERT), individual certificates containing the public keys of the respective target instances are first issued from the certification authority (ENCR-CA), and / or the target instance is provided with the option of having such a certificate issued from the certification authority (ENCR-CA) using the protected interface (GENCERT). All source instances (IZ1) of the system are provided with the public key (EncrRootPub) of the certification authority (ENCR-CA) in a secure manner, and this public key (EncrRootPub) is stored as a trust anchor for the leaf certificate (encrypted certificate) issued from the certification authority (ENCR-CA) so that it is not tampered with there. All source instances (IZ1) of the system are provided with the option of dynamically acquiring the necessary or additionally necessary leaf certificates of the target instance from the certification authority (ENCR-CA) or the third-party system storing the leaf certificate. The method according to claim 7 or 8, characterized in that.

10. The method according to claim 9, characterized in that the acquisition interface is formed as an unprotected interface. **Claim 11** The system is formed as a vehicle ecosystem, and the system includes the following instances, namely: - A backend server outside the vehicle or at least one module thereof, - Individual control devices (ECUs) attached to the vehicle, - A smartphone that executes vehicle-related applications that communicate with the individual control devices attached to the vehicle and / or the backend server outside the vehicle, - A manufacturer-specific and / or vehicle-specific external device for a device or an interface for such a device that is set to communicate directly with the control device attached to the vehicle, The method according to any one of claims 1 to 10, characterized in that it includes at least some of the above.

Images