Method for verifying data

Abstract

The invention relates to a method for verifying data (DAT13) which is transmitted between two of the instances (IZ1, IZ2, IZ3) in a system having at least three instances (IZ1, IZ2, IZ3), each of the instances (IZ1, IZ2, IZ3) having a unique identity (IZ1 ID, IZ2 ID, IZ3 ID). The invention is characterized in that at least some of the instances (IZ1, IZ2, IZ3) each implement a verification mechanism (AUTH12, AUTH23), by means of which a first instance (IZ1) can verify itself with respect to an adjacent instance (IZ2) trust the first instance (IZ1), data (DAT13) to be transmitted from the first instance (IZ1) as a source instance (IZ1) to a non-adjacent target instance (IZ3) is verified by the source instance (IZ1) and transmitted to an intermediate instance (IZ2) trust the source instance (IZ1), which intermediate instance checks the verification, and if the check is qualified, the data (DAT13) is transmitted to the target instance (IZ3). The data (DAT13) is configured with an identity (IZ1ID) of the source instance (IZ1), the data (DAT13) is re-verified and forwarded to an adjacent instance trust the intermediate instance (IZ2), the adjacent instance checks the verification, and if the check is qualified, the data (DAT13) configured with the identity (IZ1ID) of the source instance is re-verified, and if the check is not qualified, the data (DAT13) is forwarded to the intermediate instance (IZ2). And sending the data to an adjacent instance trust it, repeating this process until the data to be transmitted reaches the target instance (IZ3).

Description

Technical Field

[0001] The invention relates to a method for verifying data which are transmitted between two of the instances in a system having at least three instances, wherein each instance has a unique identification. Background Art

[0002] Today, modern vehicles are typically part of the so-called vehicle ecosystem. The core of this system is the so-called vehicle backend or simply the backend, which is usually operated as a manufacturer's own server and is often implemented in a commercial cloud. The vehicle is connected to the backend via the Internet. Here, the communication between the backend and the vehicle is protected by known standard methods (usually TLS, sometimes also by IPSec). Subsystems or instances of the vehicle ecosystem are, for example, various control units (ECUs) installed in the vehicle, which usually communicate with each other through the vehicle's internal bus (such as CAN, FlexRay or Ethernet). Smart terminal devices or applications running on them, usually OEM applications owned by the manufacturer, also form other instances of the vehicle ecosystem, which run on smartphones, for example, and communicate with various control units and / or backends in the vehicle. Their communication with the control unit inside the vehicle is usually carried out via NFC, WLAN or Bluetooth, while their communication with the backend is typically carried out via mobile communication, such as UMTS, LTE or 5G. Other subsystems or instances of the vehicle ecosystem can also be manufacturer-specific external devices, such as OBD dongles, which usually communicate directly with various control units in the vehicle through suitable interfaces.

[0003] The protection of the various communication relationships within such a vehicle ecosystem is typically 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 other individual protection mechanisms, which are often supplemented by additional manufacturer-specific protection mechanisms at the application level. In-vehicle communication between control units is often protected by SecOC.

[0004] In practice, the backend here typically has a number of modules that communicate with the vehicle in the vehicle ecosystem. Each vehicle usually contains a telematic control unit (TCU), which in turn contains a SIM card and can establish a direct Internet connection with the backend or its modules. Specific control units in the vehicle communicate with external devices (e.g. smartphones, laptops, dongles) via NFC, Bluetooth, WLAN, or the OBD2 socket that is present in all modern vehicles and is used for OnBoard diagnostics. In addition, a number of these external devices (e.g. smartphones) are typically also connected to the backend via a connection protected by TLS.

[0005] In principle, it is known in the prior art and described, for example, in US 2020 / 0202017 A1, to protect the communication between members of the vehicle ecosystem by encryption. For example, it is conceivable to protect the communication end-to-end by suitable encryption methods. However, a disadvantage of such encryption methods is that the encryption is typically not verified, which means that the backend or one of its modules as a recipient cannot determine whether the received data is actually encrypted by the control unit (ECU) or whether the request for download and, for example, the symmetric session key or transmission key used for protection actually come from the control unit.

[0006] In order to overcome this weakness, it must be ensured that the control units that communicate with the backend module in an end-to-end encrypted manner can also sign messages in an asymmetrical manner. However, for this purpose, each control unit must now be equipped with a device-specific private key, the control unit must be able to store its device-specific private key reliably, for example in a hardware security module (HSM), and the control unit must be able to perform an asymmetric signing operation, wherein it must be noted that asymmetric signing operations, for example when using RSA, are very computationally intensive and are several orders of magnitude higher, especially compared to the verification of digital signatures. This means that resource-poor devices can hardly perform this operation within a reasonable time.

[0007] In practice, however, many control units installed in vehicles today are resource-poor devices that are technically unable to reliably store secrets such as device-specific private keys, especially because they do not have an HSM. In addition, many control units do not have the necessary computing power to calculate digital signatures with their private keys quickly and efficiently enough. Summary of the invention

[0008] The object of the present invention is therefore to specify a method for verifying system-internal data which eliminates these disadvantages to the greatest extent possible.

[0009] According to the invention, this object is achieved by a method having the features of claim 1, here in particular the characterizing part of claim 1. Further advantageous embodiments result from the associated dependent claims.

[0010] According to a very advantageous embodiment of the method according to the invention, the system can be a vehicle ecosystem with different subsystems or instances. For these instances of the system or vehicle ecosystem, different communication mechanisms can now be used for communication, which in turn are protected by different protection mechanisms. This means that the entire system is highly heterogeneous in terms of communication and communication protection.

[0011] Furthermore, in such systems (and this applies in particular not only to vehicle ecosystems) there are often hierarchical structures at many points. For example, all control units installed in the vehicle and forming individual instances of the system can be considered a "vehicle" by the backend or a module thereof that also forms an instance of the system. If a dongle or a smartphone is currently connected to the vehicle, for example via Bluetooth, then at this point in time, the dongle or smartphone or the application running on it and connected to the vehicle can also be considered a "vehicle" from the perspective of the backend.

[0012] Next, there may be various trust relationships within such systems, which usually also have a hierarchical structure and are technically implemented or supported in different ways. For example, a control unit installed in a vehicle can identify a first control unit as a second control unit installed in the same vehicle and classify it as trustworthy because it determines that the integrity of the overall system installed in the vehicle cannot be easily and conveniently bypassed. In other words, the experience based here is that it is impossible to place an additional unknown control unit or an unauthorized control unit in the vehicle without worry. Further, for example, the control unit trusts that the smartphone connected to it via Bluetooth or the application running on it is trustworthy because the Bluetooth pairing for the smartphone has been performed by a person who has the car key at the time of pairing and thus obviously has the necessary permissions to perform the pairing. That is, by using the Bluetooth security mechanism, the control unit can ensure that the smartphone connected to it is the same smartphone that the authorized person has authorized via Bluetooth pairing. In this way, the control unit can continue to trust the smartphone. On the other hand, the smartphone can also trust the control unit connected to it accordingly for the same reason. Similarly, a trust relationship can exist between a control unit installed in a vehicle (such as a telematics control unit) and the back end or a specific module in the back end. If the control unit also possesses secrets, such as a private authorization key and the associated authorization certificate, the control unit can thereby reliably authenticate itself to other systems, in particular also to the backend or a specific backend module. In other words, in this way the backend can trust the messages received from the control unit and the information contained therein that is authenticated by the control unit. Since the vehicle is seen as a whole from the outside perspective of the backend facing the vehicle, as described above, the control unit is regarded by the backend as a trustworthy representative of the entire vehicle and thus in particular of all control units installed therein.

[0013] If individual control units cannot verify the data transmitted by them directly and accordingly with respect to the target instance for the reasons mentioned at the beginning of the text, the data to be transmitted by these instances can be verified by another control unit of the vehicle (such as a telematics control unit) or another instance connected to the vehicle in a trust relationship. Next, this other instance forms an intermediate instance of the source instance that trusts the transmitted data to a certain extent. That is, the intermediate instance can receive the data to be transmitted from the source instance, add the identity of the source instance, verify and transmit it to the target instance, such as the back-end module of the vehicle's back end. Although a single control unit in the vehicle cannot verify its data now, for example, because it lacks the ability to store secrets securely and / or because it cannot provide the required computing power, it can use the intermediate instance to verify its data with respect to the target system. That is, the source instance entrusts the verification to the intermediate instance. At the same time, in this process, the target instance entrusts the intermediate instance to review the authenticity of the data sent by the source instance, with the result that the target instance must trust the intermediate instance.

[0014] For the method according to the present invention, in principle, any number of intermediate instances can be designed between the source instance and the target instance. Next, the transmitted data is transmitted through a corresponding plurality of intermediate instances together with the identity of the source instance as the source of the data to be transmitted, wherein at least the intermediate instance responsible for receiving trusts the intermediate instance responsible for sending, wherein the two can of course also trust each other. Here, the first intermediate instance verifies the data and the identity of the source instance, and the next intermediate instance checks the verification of the received data and the identity of the source instance. If the check is qualified, the data and the identity of the source instance are re-verified and transmitted to the next adjacent intermediate instance, and so on, until the data transmitted by the adjacent instance to the adjacent instance reaches the target instance next. That is to say, through such verification delegation, the data can also be verified accordingly by an instance that is not set up for this purpose, thereby improving security. It should be noted that, on the other hand, the authenticity check is respectively delegated by the instance responsible for receiving to the adjacent instance responsible for sending.

[0015] In the description here, adjacent means that a first instance is considered to be adjacent to at least one other instance, such as a second instance, provided that the two instances implement the same authentication mechanism by which the first instance can authenticate itself relative to the second instance, and additionally, the second instance trusts the first instance. In other words, adjacent has nothing to do with spatial proximity, and in particular, there is no symmetric relationship.

[0016] Now, according to a particularly advantageous embodiment of the method according to the invention, three instances are designed. One of the instances is then the source instance, one is the target instance and the other forms an intermediate instance. The system (e.g. the vehicle ecosystem) can here contain more subsystems or instances than the three here. However, only these three instances are included in the data verification method. This makes the structure relatively simple and efficient, because the data does not need to be checked and revalidated separately via a long chain of intermediate instances.

[0017] That is, a variation is designed for a part of an existing system consisting of three instances with respective identities, which can be a vehicle ecosystem in particular, or can also be only a part of such an ecosystem, wherein a trust relationship exists between a first instance and an intermediate instance as a source instance, or between an intermediate instance and a third instance as a target instance. The source instance and the intermediate instance implement a first verification mechanism here, whereby the source instance can verify itself relative to the intermediate instance. The intermediate instance and the target instance implement a second verification mechanism, whereby the intermediate instance can verify itself relative to the target instance. Next, the data to be sent from the source instance to the target instance is first verified by the source instance through the first verification mechanism and transmitted to the intermediate instance. The intermediate instance checks the authenticity of the data transmitted by the source instance with the help of the first verification mechanism. If the result of the check is qualified, the intermediate instance then combines the data and the identity of the source instance together, and verifies these data with the second verification mechanism so as to transmit them to the target instance. Now the target instance can check the authenticity of the combination consisting of the data and the identity of the source instance with the help of the second verification mechanism. If the result of the check is qualified, the target instance can use and / or continue to process the data accordingly, and can trust that the data does come from the source instance.

[0018] It is generally not necessary to use the same authentication mechanism here. More precisely, the first and second authentication mechanisms can be different mechanisms, so that the target instance cannot check the authenticity of the data authenticated by the source instance using the first authentication mechanism, for example because the target instance does not implement a matching mechanism and / or because the target instance lacks the necessary cryptographic material to check the authenticity of the data authenticated by the source instance using the first authentication mechanism and / or because a prerequisite of the first authentication mechanism is not met for the source instance on the one hand and for the target instance on the other hand, such as the spatial proximity of the relevant participating instances or the relevant participating instances communicating via a specific bus. For example, the spatial proximity can be acquired according to DE 10 2021001170A1.

[0019] Here, the source instance can be a smartphone, which authenticates itself with respect to an intermediate instance (e.g. a control unit installed in a vehicle) by means of a Bluetooth mechanism, and this control unit as an intermediate instance implements a signature verification mechanism. That is, the intermediate instance has a private signing key and an associated signing certificate, by which the intermediate instance can authenticate itself with respect to a target instance (e.g. a backend module). The backend module as a target instance cannot check the Bluetooth verification of the source instance here. For this reason, the target instance can only determine that the transmitted data indeed comes from the source instance if the target instance believes that the intermediate instance has ensured that the data comes from the source instance, and in addition, the target instance determines that the second verification mechanism used between it and the intermediate instance is secure.

[0020] Furthermore, in another particularly advantageous design of the method according to the present invention, it can be designed that at least one instance contains at least one, typically multiple, sub-instances with unique identification. The instance here at least trusts this sub-instance, wherein at least one sub-instance implements a verification mechanism, and the sub-instance can verify itself relative to the instance to which it belongs by means of the verification mechanism. In other words, the method can not only be used accordingly for a chain consisting of instances and intermediate instances, but also for the case where multiple other sub-instances are separated from one instance and the instance trusts all these sub-instances. These sub-instances can then be formed as source instances, or can also be formed as data sources of the upper-level instance as the source instance.

[0021] According to another very advantageous design of the method of the present invention, at least one of the following authentication mechanisms is used. For example, authentication based on digital signatures can be used. In addition or as an alternative, authentication based on symmetric methods, such as MAC methods, can be used. The implemented Bluetooth, WLAN, NFC or SecOC and TLS mechanisms can also form the basis for authentication, which are usually based on digital signatures and / or symmetric methods. In addition, authentication methods or mechanisms that are not based on encryption methods and / or secrets, but on biometric methods, determine spatial proximity by technical means and / or use secure and trusted communication channels can also be considered. Here, a combination of the above methods can also be considered.

[0022] Here, as shown in the table above, the authentication mechanisms do not necessarily have to be based on cryptographic methods and / or secrets, but they can also be other methods, in particular biometric methods. For example, one of the instances can be a combination of a mobile data carrier (e.g. a USB stick or USB hard disk, etc.) and a person with a unique personal identity, wherein the data to be transmitted are stored on the mobile data carrier. Now, if the person connects the mobile data carrier to a suitable interface of a host installed in the vehicle and forming the second instance, and a camera is connected to the host, for example, by iris recognition, which uniquely authenticates the person connected to the data carrier, then the host can then determine in this way which person has connected the mobile data carrier. In the case of explaining the association between the data and the person connected to the mobile data carrier (i.e. his identity), the host, as an intermediate instance, can then transmit the authenticated data (e.g. via TLS) to another instance as the target instance, such as a backend module.

[0023] In addition, the first instance can also be directly a person who inputs data through an input unit of a host installed in a vehicle and forming the next instance, and a camera is connected to the host, which uniquely verifies the person who inputs the data through iris recognition. In this way, the host as the second instance determines which person inputs the data, and when the data and the identity of the person who inputs the data are explained, the data can be verified through a verification mechanism (for example, through TLS) and transmitted to the target instance, such as a backend module.

[0024] For the transmission of data from the source instance to the intermediate instance verified by the first verification mechanism, and the transmission of data and the source instance identity from the intermediate instance to the target instance verified by the second verification mechanism, depending on the form and characteristics of the two verification mechanisms, additional data may also have to be transmitted from the source instance to the intermediate instance, or from the intermediate instance to the target instance, which the receiving instance needs in order to check the verification of the corresponding received data. For example, these additional data can be so-called verification stamps, such as digital signatures or message authentication codes (MACs).

[0025] As described above, a very advantageous design of the method according to the present invention can further be designed as a verification mechanism relative to the target instance, using the private signing key of the instance responsible for sending the data and its signing certificate to implement the verification. This transmission is particularly safe in terms of verification and can be used, for example, by a TCU as an intermediate instance, which forms the core communication channel between the vehicle and the back end or back end module.

[0026] Now, in one embodiment of the method according to the invention, no protection measures are taken for the data sent by the source instance against simultaneous reading by the intermediate instance, which verifies the authenticity of the data with respect to the target instance. Therefore, according to a very advantageous improved embodiment of the method according to the invention, it is proposed to encrypt the data transmitted between the source instance and the target instance, so-called end-to-end encryption.

[0027] According to one particularly advantageous improved design, an asymmetric decryption method and a suitable asymmetric key pair can be used for the target instance, and the private key can be securely stored in the target instance. Next, the source instance is provided with a corresponding asymmetric encryption method and the public key of the target instance. In this way, the data that needs to be transmitted from the source instance to the target instance can be directly encrypted with the public key by means of an encryption method before being transmitted to the target instance. As a result, the at least one intermediate instance cannot read the data, so that end-to-end encryption can be achieved, wherein verification can still be delegated to the intermediate instance that trusts the source instance.

[0028] According to one of the corresponding improved design schemes, it can also be designed to provide an additional symmetric encryption method for the source instance and a matching symmetric decryption method for the target instance, and the data that needs to be transmitted from the source instance to the target instance is encrypted using a (corresponding) newly generated security key (for example, a random symmetric key that matches the symmetric encryption and decryption method), the so-called transmission key, before being sent to the intermediate instance. Next, the source instance encrypts the newly generated transmission key using the asymmetric public key of the target instance known above. Next, the source instance transmits the encrypted transmission key to the intermediate instance as part of the data to be verified.

[0029] That is, according to this variant of the method of the present invention, the public key of the target instance is provided to the source instance, wherein the public key is stored as a key only, not as a certificate. Therefore, the key must be added in a secure manner. That is, it must be ensured that the source instance knows that the public key belongs to the target instance, and both this information and the public key itself must be protected in the source instance to avoid tampering. However, in practice, these requirements can be met relatively well by initially configuring the encryption material for the source instance. But then dynamically adding keys during operation will become correspondingly difficult. For other communication objects that are integrated into the system during the operation of the system as other target instances, adding their public keys is particularly complex and difficult. However, if the public key of the target instance used for encryption is added to the source instance in the form of a certificate, this problem will no longer exist, because in this case, the public (root) key of the certification authority can be securely added and integrity protected to be stored, so that the integrity of all subsequently added certificates can be reliably audited at any time.

[0030] Therefore, according to a very advantageous improved design scheme of the method described in the present invention, it is designed to set up a certification authority based on an asymmetric key pair in the system. The root certificate of the certification authority contains the public key of the certification authority, which can be used to check the correctness of the leaf certificate containing the actual public key for encryption, and then especially check the source or subordination of each encryption key of the corresponding target instance. Since the leaf certificates issued by the certification authority contain encryption keys, these leaf certificates are also referred to as encryption certificates in the following. According to an advantageous improved design scheme of the method described in the present invention, the certification authority has a security interface here, which can issue leaf certificates for individual public keys belonging to the target instance, wherein the public key contained in the leaf certificate is suitable for asymmetric encryption with the aid of an asymmetric encryption method, and the corresponding private key is suitable for decryption with the aid of an asymmetric encryption method. All leaf certificates issued by the certification authority for the target instance will be stored accordingly in the certification authority or in a third-party system connected to the certification authority. An extraction interface is provided here, and the source instance can extract or download the leaf certificate issued for the target instance from the certification authority or a third-party system through the extraction interface. Furthermore, in the case of using a secure interface, for all target instances of the system, a certificate containing the public key of the corresponding target instance is initially issued by the certification authority, and / or the target instance is provided with the option of being issued such a certificate by the certification authority in the case of using a secure interface. All source instances of the system are hereby configured with the public key of the certification authority in a secure manner and stored as a trust anchor for the leaf certificates issued by the certification authority forming the encryption certificates described above. Furthermore, all source instances of the system are also configured with the option of being able to dynamically extract the required or additionally required target instance leaf certificates stored there from the certification authority or a third-party system.

[0031] By using such certification authorities and the encryption certificates issued by them, data can be transmitted in an encrypted manner to newly added or unknown target instances before the source system is put into use, which is particularly beneficial in practical applications, especially in dynamically changing systems (such as vehicle ecosystems).

[0032] In this case, the extraction interface itself does not necessarily have to be designed as a secure interface, which further simplifies the structure or process. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Further advantageous embodiments of the method according to the invention and its variants can also be derived from the exemplary embodiments which are described in more detail below with reference to the drawings.

[0034] in:

[0035] Figure 1 A schematic diagram of a vehicle ecosystem is shown;

[0036] Figure 2 The first variation of the verification delegation method according to the present invention is schematically shown;

[0037] Figure 3 Another variation of the verification delegation method according to the present invention is schematically shown; and

[0038] Figure 4 A schematic diagram shows how to configure encryption certificates for an instance of a vehicle ecosystem. DETAILED DESCRIPTION

[0039] Figure 1 An example vehicle ecosystem 1 with two vehicles Fzg1, Fzg2 and a backend consisting of two modules BEModulX and BEModulY is schematically shown. Each vehicle Fzg1, Fzg2 contains a telematic control unit TCU, which in turn contains a SIM card SIM and is able to establish a direct Internet connection to the backend, which is protected by TLS. The specific control units (ECUs) of the vehicles Fzg1, Fzg2 communicate with external devices ExtGer1–ExtGer6 (e.g. smartphones, laptops, dongles, etc.) via near field communication NFC, Bluetooth BT, WLAN and / or on-board diagnostic socket OBD, etc. On the other hand, multiple external devices ExtGerA, ExtGerB, ExtGerC (e.g. smartphones, laptops, etc.) are connected to the backend via a connection protected by TLS. All TCUs, ECUs and backends or their modules BEModulX and BEModulY together with external devices ExtGer1 - ExtGer6 and external devices ExtGerA, ExtGerB, ExtGerC form a subsystem or instance IZi of the vehicle ecosystem 1 , where 1≤i≤n and n is an arbitrary natural number.

[0040] Next, a method for verifying data in such a vehicle ecosystem 1 having multiple instances IZi will be described by taking three participating subsystems or instances IZ1, IZ2 and IZ2 as examples. Of course, the method can also involve other instances IZi.

[0041] That is to say, for this example, there will be three different instances IZ1, IZ2, and IZ3 in the vehicle ecosystem 1, each with a unique identity IZ1_ID, IZ2_ID, and IZ3_ID in an active state. Whether between the first instance IZ1 and the second instance IZ2, or between the second instance IZ2 and the third instance IZ3, there is a trust relationship in at least one direction. In any case, the second instance IZ2 should trust the first instance IZ1, and the third instance IZ3 should trust the second instance IZ2. Thus, the first and second instances IZ1, IZ2, and the second and third instances IZ2, IZ3 belong to adjacent instances in this description. Instances IZ1 and IZ2 implement the verification mechanism AUTH12, whereby IZ1 can verify itself relative to IZ2. Similarly, instances IZ2 and IZ3 implement (another / possibly different) verification mechanism AUTH23, whereby IZ2 can verify itself relative to IZ3.

[0042] Now, Figure 2 The three instances and the purpose of the invention, which is the basis of the present invention, are schematically shown. This purpose of the invention is to transmit the data DAT13 from the first instance IZ1 as the source instance IZ1 to the third instance IZ3 as the target instance IZ2 after verification, as shown by the dotted arrow. However, the source instance is now a control unit (ECU) that cannot store secrets safely and does not have matching computing power for appropriate verification of the target instance IZ3. Therefore, the data DAT13 to be sent from the source instance IZ1 to the target instance IZ3 will first be verified by the source instance IZ1 using the verification mechanism AUTH12 that does not require any secrets, and transmitted to the intermediate instance IZ2. There, the authenticity of the transmitted data is checked by the intermediate instance IZ2 with the help of the verification mechanism AUTH12. If the result of the check is qualified, the combination of the data DAT13 and the identity identifier IZ1_ID of the target instance is verified by the intermediate instance IZ2 using the verification mechanism AUTH23, and transmitted to the target instance IZ3. There, the authenticity of the combination of data DAT13 and identity IZ1_ID is checked by the target instance IZ3 using the authentication mechanism AUTH23. If the result of this check is favorable, the target instance IZ3 can then trust that the data DAT13 was indeed received from the source instance IZ1 and process or use the data accordingly.

[0043] Here, the authentication mechanisms AUTH12 and AUTH23 can generally be different mechanisms, and the target instance IZ3 is unable to check the authenticity of the data verified by the source instance IZ1 using the authentication mechanism AUTH12, for example because the target instance IZ3 does not implement the mechanism AUTH12, and / or because the target instance IZ3 lacks the necessary cryptographic material and is unable to check the authenticity of the data verified by the source instance IZ1 with the aid of the authentication mechanism AUTH12, and / or because for the source instance IZ1 and for the target instance IZ3, a prerequisite in the authentication mechanism AUTH12 is not met, such as the spatial proximity of the relevant participating instances or the communication of the relevant participating instances via a specific bus. If the source instance IZ1 is not a control unit but a smart phone, it authenticates itself with respect to the intermediate instance IZ2 (for example, a control unit installed in a vehicle) by means of a Bluetooth mechanism, and the control unit as the intermediate instance IZ2 also implements a signature verification mechanism, that is, the intermediate instance IZ2 has a private signing key and an associated certificate, and the intermediate instance can authenticate itself with respect to the target instance IZ3 (for example, a backend module) through the private signing key and the associated certificate, while the backend module as the target instance IZ3 cannot check the Bluetooth verification AUTH12 of the source instance. For this reason, the target instance IZ3 can only determine that the data DAT13 is indeed from the source instance IZ1 under the following circumstances: the target instance IZ3 believes that the intermediate instance IZ2 has ensured that the data DAT13 is from the source instance IZ1, and the target instance IZ3 determines that the verification mechanism AUTH23 is safe.

[0044] Under certain assumptions, i.e., both the authentication mechanism AUTH12 and the authentication mechanism AUTH23 are based on a verification stamp, such as a digital signature or a MAC, i.e., they generate and check the verification stamp, wherein AUTH12_GEN or AUTH23_GEN represents the AUTH12 or AUTH23 function used to generate the verification stamp, and AUTH12_VER or AUTH23_VER represents the AUTH12 or AUTH23 function used to check (verify) the verification stamp, and both AUTH12 and AUTH23 have implicitly implied the required cryptographic material, i.e., the required cryptographic material is not explicitly shown as a parameter, then the recommended method consists of the following steps:

[0045] ●In source instance IZ1:

[0046] ■ Use AUTH12_GEN to calculate the verification stamp AuthSt12 of the data DAT13, that is, AuthSt12:=AUTH12_GEN(DAT13);

[0047] ■Transmit the message (DAT13, AuthSt12) to the intermediate instance IZ2;

[0048] In the intermediate instance IZ2 responsible for authentication, after receiving (DAT13, AuthSt12):

[0049] ■ Check the correctness of the verification stamp AuthSt12 of the received data DAT13 using AUTH12_VER, i.e. calculate the Boolean value AUTH12_VER(DAT13, AuthSt12);

[0050] ■If the check is qualified, AUTH23_GEN is used to calculate the combination of the data DAT13 and the identity identifier IZ1_ID of IZ1, that is, the verification stamp AuthSt23 of (DAT13, IZ1_ID), that is, AuthSt23:=AUTH23_GEN((DAT13, IZ1_ID)), otherwise, a special process will be initiated;

[0051] ■Transmit the message (DAT13, IZ1_ID, AuthSt23) to the source instance IZ3;

[0052] ● In the target instance IZ3, after receiving (DAT13, IZ1_ID, AuthSt23):

[0053] ■ Check the correctness of the verification stamp AuthSt23 of the received data (DAT13, IZ1_ID) using AUTH23_VER, i.e. calculate the Boolean value AUTH23_VER((DAT13, IZ1_ID), AuthSt23);

[0054] ■If the check is qualified, it will be determined that data DAT13 comes from IZ1 and data DAT13 will be used accordingly, otherwise, a special processing will be initiated.

[0055] For the data DAT13 sent by the source instance IZ1, the proposed method does not take any protection measures against simultaneous reading by the intermediate instance IZ2, and the intermediate instance IZ2 confirms the authenticity of the data DAT13 relative to the target instance IZ3. In the general current technology, it is known that protection can be implemented for the exchanged data between the two instances of the vehicle ecosystem 1, for example, through end-to-end encryption based on asymmetric encryption. In this way, the target instance IZ1 can, for example, encrypt the data DAT13 before transmitting it to the intermediate instance IZ2, so as to revoke the data reading permission of the intermediate instance IZ2 in this way. Combined with the above-mentioned delegation from the source instance IZ1 to the intermediate instance IZ2 to verify the data DAT13 relative to the target instance IZ3, the following will be formed. Figure 3 The process is schematically shown.

[0056] As a unique feature of this method, the target instance IZ3 can be configured with an asymmetric decryption method AsymmDECR and a matching asymmetric key pair (IZ3Pub, IZ3Priv). The private key IZ3Priv will be securely stored in the target instance IZ3, and the source instance IZ1 will be configured with an asymmetric encryption method AsymmENCR matching the decryption method AsymmDECR and the public key IZ3Pub of the target instance IZ3, and before being transmitted to the target instance IZ3, the data DAT13Plain that needs to be transmitted from the source instance IZ1 to the target instance IZ3 will be directly encrypted with the public key IZ3Pub by means of the encryption method AsymmENCR. Alternatively, a symmetric encryption method SymmeNCR can be additionally configured for the source instance IZ1, and a symmetric decryption method SymmDECR matching the encryption method SymmeNCR can be configured for the target instance IZ3. Next, the data DAT13Plain to be transmitted from the source instance IZ1 to the target instance IZ3 can be encrypted with a newly generated security key (e.g. a random symmetric key compatible with the symmetric encryption and decryption method Symmencr / symmdecr), the so-called transmission key, before being sent to the intermediate instance IZ2. Next, it is only necessary to encrypt this newly generated transmission key with the asymmetric public key IZ3Pub and then transmit the transmission key encrypted in this way to the intermediate instance IZ2 as part of the data to be verified DAT13.

[0057] Under the assumptions made above, that is, both AUTH12 and AUTH23 are based on a verification stamp, such as a digital signature or MAC, that is, a verification stamp is generated and checked, AUTH12_GEN or AUTH23_GEN represents the AUTH12 or AUTH23 function used to generate the verification stamp, and AUTH12_VER or AUTH23_VER represents the AUTH12 or AUTH23 function used to check (verify) the verification stamp, and both AUTH12 and AUTH23 have implicitly implied the required encryption material, that is, the required encryption material is not explicitly shown as a parameter, then the second variant of the proposed method, that is, the variant using a symmetric transmission key, consists of the following steps:

[0058] ●In source instance IZ1:

[0059] ■ Generate a new symmetric transport key transpKey using a secure method;

[0060] ■Use transpKey with SymmENCR to encrypt the data DAT13Plain to be sent, that is, DAT13ENCR:=SymmENCR(transpKey, DAT13Plain);

[0061] ■Use IZ3Pub to asymmetrically encrypt the transmission key transpKey with the help of AsymmENCR, i.e. transpKeyENCR:=AsymmENCR(IZ3Pub, transpKey);

[0062] ■ The data DAT13 to be transmitted for IZ3 is formed into a combination of DAT13ENCR and transpKeyENCR, that is, DAT13:=(DAT13ENCR, transpKeyENCR);

[0063] ■ Use AUTH12_GEN to calculate the verification stamp AuthSt12 of the data to be transmitted DAT13, that is, AuthSt12:=AUTH12_GEN(DAT13);

[0064] ■Transmit the message (DAT13, AuthSt12) to IZ2.

[0065] ● In the intermediate instance IZ2 responsible for authentication, after receiving (DAT13, AuthSt12):

[0066] ■ Check the correctness of the verification stamp AuthSt12 of the received data DAT13 using AUTH12_GEN, i.e. calculate the Boolean value AUTH12_VER(DAT13, AuthSt12);

[0067] ■If the check is qualified, AUTH23_GEN is used to calculate the combination of the data DAT13 and the identity identifier IZ1_ID of IZ1, that is, the verification stamp AuthSt23 of (DAT13, IZ1_ID), that is, AuthSt23:=AUTH23_GEN((DAT13, IZ1_ID)), otherwise, a special process will be initiated;

[0068] ■Transmit the message (DAT13, IZ1_ID, AuthSt23) to IZ3.

[0069] ●In the target instance IZ3, after receiving (DAT13, IZ1_ID, AuthSt23):

[0070] ■ Check the correctness of the verification stamp AuthSt23 of the received data (DAT13, IZ1_ID) using AUTH23_VER, i.e. calculate the Boolean value AUTH23_VER((DAT13, IZ1_ID), AuthSt23);

[0071] ■If the check is qualified, two components DAT13ENCR and transpKeyENCR are extracted from DAT13, otherwise, a special process will be initiated;

[0072] ■ Decrypt transpKeyENCR with the help of the private key IZ3Priv, thereby determining the transmission key transpKey, that is, transpKey:=AsymmDECR(IZ3Priv, transpKeyENCR);

[0073] ■ Decrypt DAT13ENCR with the help of the transmission key transpKey to determine the valid data DAT13Plain, that is, DAT13Plain:=SymmDECR(transpKey, DAT13ENCR);

[0074] ■It will be assumed that the data DAT13Plain comes from IZ1 and the data DAT13Plain will be used accordingly.

[0075] In the described method variant in which encryption is configured, the public key IZ3Pub of the target instance IZ3 is configured for the source instance IZ1. If the public key IZ3Pub is stored as a simple key rather than as a certificate, it must be added in a secure manner, in particular it must be ensured that the source instance IZ1 knows that the key IZ3Pub belongs to the target instance IZ3, and both this information and the key IZ3Pub itself must be protected in the source instance IZ1 to avoid tampering. These requirements can be met relatively well in the case of an initial configuration of cryptographic material for the source instance IZ1, but this makes it difficult to dynamically add such keys during operation, especially when adding public keys from other communication partners.

[0076] It is therefore advantageous to provide a key certification authority ENCR-CA for leaf certificates containing asymmetric public encryption keys in 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, which can be used to check the correctness of the leaf certificates EncrIndCert containing the actual encryption keys EncrIndPub and then in particular to check the origin or subordination of the individual encryption keys EncrIndPub with respect to the corresponding target instance. Since the leaf certificates issued by the certification authority ENCR-CA contain encryption keys, these leaf certificates are also referred to as encryption certificates in the following.

[0077] Figure 4The configuration of an instance IZi of an exemplary vehicle ecosystem 1 is shown, which is configured with a certification authority ENCR-CA and a certification service Cert-Service, which is implemented by a third-party system and is 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). In addition, Figure 4 The status of each instance IZi after the configuration of the signed cryptographic material is shown, that is, the configuration of a separate private signing key, a separate signing certificate, a license root certificate, etc. Here, it is assumed that the separate signing certificates for all instances IZ2 (ExtGer2, ExtGerβ, TCU) responsible for verification are issued by the same license certification authority END-CA, that is, signed with the same private root key EndRootPriv.

[0078] Now, in order to configure the required certificates for all instances IZ1, IZ2, IZ3, the system structure is designed to set up an encryption certification authority ENCR-CA based on an asymmetric key pair (EncrRootPub, EncrRootPriv) within the vehicle ecosystem. The encryption certification authority ENCR-CA is configured with a security interface GENCERT, which can issue a leaf certificate EncrIndCertIZ3 for a separate public key EncrIndPubIZ3 belonging to the target instance IZ3, wherein the public key EncrIndPubIZ3 contained in the leaf certificate is suitable for asymmetric encryption using the asymmetric encryption method AsymmENCR, and the corresponding private key EncrIndPrivIZ3 is suitable for decryption using the asymmetric decryption method AsymmDECR.

[0079] All leaf certificates issued by the encryption certification authority ENCR-CA for the target instance IZ3 will be stored or kept in the encryption certification authority ENCR-CA or in a third-party system connected to the encryption certification authority ENCR-CA. A (not necessarily protected) extraction interface GETCERT is set up, through which the source instance IZ1 can download or extract the issued leaf certificates directly from the encryption certification authority ENCR-CA or from the third-party system that keeps the leaf certificates for the target instance IZ3. As mentioned above, the extraction interface GETCERT is not necessarily protected here, because the leaf certificate is protected by using the signature of EncrRootPriv to prevent tampering, and the information contained in the certificate is usually not confidential, that is, it is public.

[0080] In addition, all target instances IZ3 of the vehicle ecosystem 1 are configured with a separate asymmetric key pair (EncrIndPubIZ3, EncrIndPrivIZ3) suitable for encryption or decryption, and the private key EncrIndPrivIZ3 is stored in the target instance IZ3 to prevent it from being illegally read. To this end, for all target instances IZ3 of the vehicle ecosystem 1, when using the security interface GENCERT, a separate certificate (signed by EncrRootPriv) containing a separate public key EncrIndPubIZ3 is initially issued by the encryption certification authority ENCR-CA, and / or an option is configured for the target instance IZ3 so that such a certificate can be issued by the encryption certification authority ENCR-CA when using GENCERT at runtime.

[0081] Now, all source instances IZ1 of the vehicle ecosystem 1 are configured (initially or at runtime) with the public key EncrRootPub of the encryption certification authority ENCR-CA in a secure manner and stored in the corresponding source instance IZ1 in a tamper-proof manner as a trust anchor for the leaf certificates (encryption certificates) issued by the encryption certification authority ENCR-CA. Further, it is designed to configure options for all source instances IZ1 of the vehicle ecosystem 1 to be able to dynamically, i.e. at runtime, extract or obtain the required or additionally required target instance IZ3 leaf certificates stored there from the encryption certification authority ENCR-CA or from a third-party system.

[0082] Next, the runtime process is: each target instance IZ3 that wishes to receive and decrypt encrypted data from the source instance IZ1 and whose encryption certificate EncrIndCertIZ3 does not yet exist in the encryption certification authority ENCR-CA or in a third-party system that keeps the encryption certificate, arranges through the security interface GENCERT for the encryption certification authority ENCR-CA to generate an encryption certificate EncrIndCertIZ3 and save it in the encryption certification authority ENCR-CA or in the third-party system.

[0083] Each source instance IZ1 that wishes to send encrypted data DAT13Plain to a target instance IZ3 performs the following steps:

[0084] ●If the encryption certificate of the target instance IZ3 does not exist in the source instance IZ1, or the encryption certificate needs to be 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 extraction interface GETCERT.

[0085] The source instance IZ1 checks the correctness of the downloaded encryption certificate EncrIndCertIZ3 with the help of the public key EncrRootPub of the encryption certification authority ENCR-CA stored in the source instance IZ1 in a tamper-proof manner, wherein the key EncrRootPub (such as Figure 4 (shown)

[0086] It can also be a component of the root certificate EncrRootCert.

[0087] If the check of the encryption certificate EncrIndCertIZ3 is passed, the public key EncrIndPubIZ3 of the target instance IZ3 contained in the encryption certificate EncrIndCertIZ3 is extracted and encryption is continued according to the method described above, for which the key EncrIndPubIZ3 extracted from the encryption certificate EncrIndCertIZ3 is used as the asymmetric key IZ3Pub. If the check result is unsatisfactory, a special process is initiated.

[0088] It should be noted that the third-party system storing the encryption certificate EncrIndCertIZ3 can exist repeatedly / multiple times in the vehicle ecosystem 1, so that the source instance IZ1 can retrieve the encryption certificate EncrIndCertIZ3 as conveniently as possible. For example, a third-party institution containing all or part of the available encryption certificates EncrIndCertIZ3 can be set in the vehicle control unit, so that the control unit installed in the same vehicle can retrieve the encryption certificate EncrIndCertIZ3 particularly conveniently.

[0089] The above method is based on the premise that the encryption certification authority ENCR-CA only supports root certificates and leaf certificates, that is, it does not support any intermediate certificates. However, the method can also be extended in an obvious way to a certificate chain that can be traced back to the encryption certification authority ENCR-CA. In this case, when the encryption certificate EncrIndCertIZ3 is generated with the help of the security interface GENCERT, it may also be necessary to generate an intermediate certificate, and when the encryption certificate EncrIndCertIZ3 is extracted with the help of the extraction interface GETCERT, a certificate chain containing the encryption certificate EncrIndCertIZ3 is returned instead of a specific encryption certificate EncrIndCertIZ3, and then the target instance IZ1 checks the certificate chain in its entirety with the help of the public root key EncrRootPub of the encryption certification authority ENCR-CA stored there.

[0090] The extraction interface GETCERT that can be used to extract the encryption certificate EncrIndCertIZ3 can be implemented in various ways. As described in RFC7517, it can especially implement a service that returns a JSON Web Key (JWK), which can return a certificate chain of any length.

[0091] The scheme determined for the encryption certification authority ENCR-CA can also be applied to the permission certification authority END-CA, which can simplify the use of the above-mentioned signing certificates.

[0092] For this purpose, a certification authority END-CA is set up. Next, a separate asymmetric private signing key EndIndPrivIZ2 and an associated separate signing certificate EndIndCertIZ2 issued by the certification authority END-CA are configured for the instance or intermediate instance IZ2 with signature verification capability (e.g. ExtGer2, ECUβ, TCU) (in Figure 4 ), or configure a certificate chain issued by a licensed certification authority END-CA, whose leaf certificate corresponds to EndIndPrivIZ2 (not shown in the figure).

[0093] The encryption certification authority ENCR-CA is set up, for which an asymmetric key pair (EncrRootPub, EncrRootPriv) is generated and, if necessary (in Figure 4 The root certificate EncrRootCert containing the public key EncrRootPub is self-signed and generated (as shown in the figure). For example, the public root key EndRootPub of the licensed certification authority END-CA will be distributed (for example, initially as the original public key, or as a self-signed root certificate EndRootCert containing the key (as shown in the figure)) to all target instances IZ3 (for example, BEModulX, BEModulY, ExtGerA), which can check the generated signature with the help of the private signing key and should be saved as a trust anchor in a tamper-proof manner.

[0094] For example, the public root key EncrRootPub of the encryption certification authority ENCR-CA will be distributed (for example, initially as the original public key, or as a self-signed root certificate EncrRootCert containing the key (as shown in the figure)) to all source instances IZ1 (ExtGer1, ExtGer2, ExtGer3, ECUα, ECUβ, TCU), which wish to send encrypted data to one of the target instances IZ3 with the help of the public key contained in the encryption certificate.

[0095] A separate private signing key EndIndPrivIZ2 and an associated signing certificate EndIndCertIZ2 are generated in a known manner and added to the intermediate instance IZ2. For example, an encryption certificate can be generated, for which purpose (as shown in the figure) each target instance IZ3 generates a separate key pair (EncrIndPubIZ3, EncrIndPrivIZ3), and then in a verified manner (not shown in the figure), using the interface GENCERT, the Certificate Signing Request (CSR) EncrIndCSRIZ3 containing the public key EncrIndPubIZ3 is provided to the encryption certification authority ENCR-CA, which then generates a separate encryption certificate EncrIndCertIZ3 from the Certificate Signing Request CSR, or alternatively (not shown in the figure), another trusted system that can be but does not have to be the encryption certification authority ENCR-CA generates a separate key pair (EncrIndPubIZ3, EncrIndPrivIZ3), adds the private key EncrIndPrivIZ3 to the target instance IZ3 in a secure manner, and in a verified manner sends the Certificate Signing Request (CSR) EncrIndCSRIZ3 containing the public key EncrIndPubIZ3 to the encryption certification authority ENCR-CA. EncrIndCSRIZ3 is provided to the encryption certification authority ENCR-CA, which then generates a separate encryption certificate EncrIndCertIZ3 from the CSR. The encryption certificate generated by the encryption certification authority ENCR-CA is transmitted to the encryption certificate distribution service Cert-Service and stored there. In this way, the source instance IZ1 can extract or download the encryption certificates they need from the encryption certificate distribution service Cert-Service when necessary using the extraction interface GETCERT.

[0096] The above-mentioned design scheme for the certificate chain is also applicable to the relevant design scheme of the licensed certification body, and can also be easily adjusted according to the certificate chain.

Claims

1. A method for verifying data (DAT13) which are transmitted between two of the instances (IZ1, IZ2, IZ3) in a system having at least three instances (IZ1, IZ2, IZ3), wherein: Each of the instances (IZ1, IZ2, IZ3) has a unique identity (IZ1_ID, IZ2_ID, IZ3_ID), It is characterized in that At least some of the instances (IZ1, IZ2, IZ3) each implement an authentication mechanism (AUTH12, AUTH23), by means of which a first instance (IZ1) is able to authenticate itself relative to an adjacent instance (IZ2) that trusts the first instance (IZ1), wherein the data (DAT13) to be 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 transmitted to an intermediate instance (IZ2) that trusts the source instance (IZ1), the intermediate instance checking the Verify, and if the check is qualified, configure the identity (IZ1_ID) of the source instance (IZ1) for the data (DAT13), re-verify the data and forward it to an adjacent instance that trusts the intermediate instance (IZ2); the adjacent instance checks the verification, and if the check is qualified, re-verifies the data (DAT13) configured with the identity (IZ1_ID) of the source instance, and sends the data to the adjacent instance that trusts the adjacent instance; repeats this process until the data to be transmitted reaches the target instance (IZ3).

2. The method according to claim 1, It is characterized in that Three instances (IZ1, IZ2, IZ3) are designed, of which one forms the source instance (IZ1), one forms the target instance (IZ3), and another forms the intermediate instance (IZ2).

3. The method according to claim 1 or 2, It is characterized in that At least one of the instances (IZ1, IZ2, IZ3) contains at least one sub-instance with a unique identity, wherein the instance (IZ1, IZ2, IZ3) trusts at least one of its sub-instances, and the at least one sub-instance implements a verification mechanism, and the at least one sub-instance can verify itself relative to the instance (IZ1, IZ2, IZ3) to which it belongs with the help of the verification mechanism.

4. The method according to claim 1, 2 or 3, It is characterized in that Use at least one of the following authentication mechanisms (AUTH12, AUTH23): Digital signature-based authentication; Verification based on symmetric methods; Bluetooth-based authentication; WLAN-based authentication; NFC-based authentication; SecOC-based verification; TLS-based authentication; Authentication based on biometric methods; Verification based on spatial proximity determined by technical means; and / or Authentication based on the use of secure and trusted communication channels.

5. The method according to any one of claims 1 to 4, It is characterized in that The authentication mechanism (AUTH12, AUTH23) of an intermediate instance relative to another intermediate instance or to the target instance (IZ3) implements authentication with the help of the private signing key and signing certificate of the instance (IZ1, IZ2) sending the data (DAT13).

6. The method according to any one of claims 1 to 5, It is characterized in that The data (DAT13) to be transmitted are encrypted by the source instance (IZ1), wherein the encryption used only requires decryption for the destination instance (IZ3).

7. The method according to claim 6, It is characterized in that An asymmetric decryption method and a matching asymmetric key pair are configured for the target instance, wherein the private key of the key pair is securely stored in the target instance, and a matching asymmetric encryption method and a public key of the key pair are configured for the source instance, so that the source instance can encrypt data to be transmitted.

8. The method according to claim 7, It is characterized in that A symmetric encryption method is additionally configured for the source instance, and a matching symmetric decryption method is configured for the target instance, wherein, before the data to be transmitted is sent by the source instance, the data to be transmitted is encrypted using a newly created secure or random transmission key, wherein the transmission key is encrypted using a public key of an asymmetric key pair and transmitted together with the encrypted data to be transmitted.

9. The method according to claim 7 or 8, It is characterized in that A certification authority based on an asymmetric root key pair is set up inside the system, wherein the certification authority (ENCR-CA) is configured with a security interface (GENCERT), and the security interface can issue a leaf certificate for a separate public key belonging to the target instance (IZ3), wherein the public key contained in the leaf certificate is suitable for asymmetric encryption with the aid of an asymmetric encryption method (AsymmENCR), and the corresponding private key is suitable for decryption with the aid of an asymmetric decryption method (AsymmDECR), wherein all leaf certificates issued by the certification authority (ENCR-CA) for the target instance are stored in the certification authority (ENCR-CA) or in a third-party system connected to the certification authority (ENCR-CA), wherein an extraction interface (GETCERT) is provided, and the source instance can download the leaf certificates issued for the target instance from the certification authority (ENCR-CA) or the third-party system through the extraction interface Certificate, wherein, when using the security interface (GENCERT), the certification authority (ENCR-CA) initially issues a separate certificate containing the public key of the corresponding target instance for all target instances of the system, and / or configures options for the target instances so that such certificates can be issued by the certification authority (ENCR-CA) when using the security interface (GENCERT), wherein all source instances (IZ1) of the system are configured with the public key (EncrRootPub) of the certification authority (ENCR-CA) in a secure manner and store it there in a tamper-proof manner as a trust anchor for the leaf certificates (encryption certificates) issued by the certification authority (ENCR-CA), and wherein all source instances (IZ1) of the system are configured with options so that they can dynamically extract the required or additionally required target instance leaf certificates stored there from the certification authority (ENCR-CA) or a third-party system.

10. The method according to claim 9, It is characterized in that The extraction interface is designed as an unprotected interface.

11. The method according to any one of claims 1 to 10, It is characterized in that The system is designed as a vehicle ecosystem that includes at least some of the following examples: - a vehicle-external backend server or at least one module thereof; - A control unit (ECU) installed in a vehicle; - a smartphone on which a vehicle-related application runs, which communicates with a control unit installed in the vehicle and / or with a vehicle-external backend server; - Manufacturer-specific and / or vehicle-specific external devices or interfaces for such devices which are arranged to communicate directly with a control unit installed in the vehicle.

Images