RU2851079C1 - Method of interblock control of application access to transport vehicle components and system for implementing it - Google Patents

Abstract

FIELD: computing technology.

SUBSTANCE: claimed result is achieved by a method of inter-block control of application access to a vehicle component (VC), in which: a) the application is loaded into the execution environment, with the application including an application certificate and a manifest containing information about permitted interactions with VC components; b) information is collected using the execution environment to certify the loaded application; c) the loaded application is certified using a security gateway based on the collected information ; d) cryptographic material confirming successful certification is generated using the security gateway and transmitted to the specified execution environment; e) establish a session between the application and the VC component through the security gateway, during which they authenticate the application's access rights using cryptographic material; f) use the security gateway to analyse the application request received within the established session to the VC component, as a result of which they decide whether to execute the request received.

EFFECT: increased security when vehicle components interact with applications.

26 cl, 4 dwg

Description

Field of technology

The invention relates to the field of ensuring the security of vehicle communication networks, and in particular to a system and method for controlling access to electronic units of a vehicle.

State of the art

Modern vehicles, particularly autonomous and electric vehicles, are complex systems incorporating various sensors, controllers, actuators, data exchange technologies, and other components that together provide extensive vehicle functionality. Additional features implemented for safer and more comfortable driving are enabled by software, including apps developed by both the automaker and third-party developers. However, the use of apps can pose security risks. For example, attackers can find existing security flaws (e.g., vulnerabilities) in apps and exploit them to launch malware and attack the vehicle's electronic control units (ECUs) in order to gain control of the vehicle's controls. Another example of a threat is third-party apps. Unlike car manufacturers, third-party developers lack complete information about the conditions of interaction with vehicle components (e.g., ECUs). Consequently, they can provide apps with more functionality than is necessary for interaction with specific vehicle components, which in turn can lead to malfunction of both those components and the vehicle itself. The use of such apps within a vehicle's electronic and digital circuitry raises questions about vehicle safety and operability, given the potential for abuse of the apps' functionality.

Solutions for ensuring the security of vehicle electronic components are known in the prior art. For example, patent application US20230118187A1 describes an automotive gateway that provides a secure, open platform for guest applications. The automotive gateway facilitates interaction between guest applications and the vehicle's electronic subsystems. The automotive gateway includes interfaces for communicating with the electronic subsystems and at least one processor within which guest applications run as virtual machines. Guest applications and electronic subsystems are separated into secure and unsecure domains (zones). Interaction between them is controlled by a hypervisor, which uses security policies to determine whether interaction is permitted or prohibited.

At the same time, the solution presented in the aforementioned publication requires certain resources, particularly hardware capabilities, to implement such an automotive gateway, including running guest applications as virtual machines and a hypervisor. It also requires constant monitoring using dedicated security policies, which must be continually created and updated. Furthermore, the solution relies on the implementation being carried out within the automotive gateway itself.

Thus, there is a current need for solutions aimed at ensuring the safety of the operation of a vehicle as a whole and of its individual components and subsystems, while having greater flexibility in controlling the interaction between the vehicle components, including components that ensure the operation of various applications, and at the same time, within certain hardware constraints, at least the same level of safety.

The proposed solution, on the one hand, eliminates the shortcomings of existing state-of-the-art solutions, and on the other, expands the arsenal of technical means aimed at ensuring vehicle security when third-party applications interact with its components. For example, the proposed solution mitigates the exploitation of potential application vulnerabilities.

Disclosure of the essence of the invention

The present invention was developed taking into account the above-described shortcomings of the prior art, and the purpose of the present invention is to ensure the safe performance of a vehicle (V) and its components. Specifically, the invention relates to solutions aimed at controlling access of applications, including third-party applications, to VV components, while also monitoring interactions between VV components. These applications are implemented within one VV component, which enables the application to operate. Examples of such VV components include various electronic systems, driver assistance systems, infotainment systems, and telematics systems. These applications interact with various VV components, such as electronic control units (ECUs), advanced driver assistance systems, and various VV sensors.

Embodiments of the present invention include the execution of applications within a single TS component, including an application execution environment, and a separately implemented security gateway in the form of another TS component, which makes it possible to eliminate limitations in terms of the hardware capabilities of the application execution environment and not be limited to the capabilities of any one TS component, for example, a security gateway.

The technical result achieved by the presented solution consists in increasing the security of interaction between vehicle components and applications, including applications containing vulnerabilities, due to inter-unit control of application access to components, in particular to electronic units, of the vehicle.

Another technical result is expanding the vehicle's functionality while maintaining operational safety by running an application, such as a third-party application, in a runtime environment within a physically separated component from other vehicle components and implementing a security gateway to control interactions between them. This separate vehicle component includes both the vehicle's components, such as infotainment systems, and components such as a cloud computing device (server) or mobile device.

The specified technical results are achieved through the implementation of a system and method for inter-unit control of application access to components, in particular to electronic control units, of a vehicle, which are described in more detail below.

According to one aspect of the invention, a method is proposed for inter-unit control of application access to at least one component of a TS, wherein said method comprises the steps of loading an application into an execution environment, wherein the application includes at least an application certificate and a manifest containing information on permitted interactions with TS components (access rights); collecting information using the execution environment to attest the downloaded application, wherein the collected information includes a manifest and/or information on the application certificate, wherein the collected information is signed with a key of the execution environment; attesting the downloaded application using a security gateway based on the collected information; generating cryptographic material using the security gateway that confirms successful completion of the attestation, wherein the generated cryptographic material is transmitted using the security gateway to said execution environment; establishing a session between the application and at least one component of the TS through the security gateway, during which the access rights of the application are authenticated using the cryptographic material; using a security gateway, an analysis is performed of at least one received application request within the established session to the TS component, as a result of which a decision is made to execute the received request.

According to some embodiments of the invention, the cryptographic material provides authentication of the network connection of the specified application, and which is at least one of: a key for generating a MAC, a session key, an attestation token or a certificate.

According to some embodiments of the invention, the application interacts through a security gateway with at least one of the following components of the vehicle: an electronic control unit (ECU); a driver assistance system; a telematics system.

According to some embodiments of the invention, the application execution environment is at least one of: a local computing component of the TS, having the ability to download and execute the application; a mobile device interacting with the components of the TS; a remote server communicating with the components of the TS.

According to some embodiments of the invention, the local computing component of the vehicle is an infotainment system.

According to some embodiments of the invention, the information collected for certifying the downloaded application additionally includes: the application identifier, the application vendor, the application hash sum, information about other certificates, the application size, and the unique identifier of the execution environment.

According to some embodiments of the invention, the execution environment is a trusted execution environment, and the application is loaded into said trusted execution environment.

According to some embodiments of the invention, a security policy is formed with respect to the certified application based on the collected information, wherein the security policy includes information about the permitted interactions of the certified application with at least one component of the TS.

According to some embodiments of the invention, an analysis of the received application request to the TS component is performed using the generated security policy.

According to some embodiments of the invention, the attestation token is intended for an open network connection (session) between the attested application and at least one component of the TS.

According to some embodiments of the invention, said attestation token verifies the integrity of the application.

According to some embodiments of the invention, at least one received request is analyzed within the established session to a component of the TS to determine the possibility of transmitting a specific command to the component of the TS to fulfill the received request.

According to some embodiments of the invention, the decision taken to execute the received request includes information either on permission and transmission of a command to the TS component to execute the request received from the application, or on rejection of the said request.

According to another aspect of the invention, a system is proposed for inter-unit control of application access to at least one component of the TS, wherein said system includes: at least one execution environment, which is a computing component containing at least one processor and memory for implementing an operating system, within the framework of which at least one application is executed, interacting with at least one component of the TS, wherein the application includes at least a manifest containing information on permitted interactions with components of the TS (access rights), and an application certificate, and the execution environment is intended for performing loading and execution of the application; implementing integrity control of said application, including the immutability of the application since the moment of its loading or last execution; a security gateway intended at least for exchanging data with the execution environment, including with the application, and with other components of the TS; attestation of the application on the basis of information received from the execution environment, wherein during attestation the identity and integrity of the application are checked; generating confirmation of successful completion of attestation by the application, which includes the generation of cryptographic material; authentication of the network connection of the application; establishing a network connection (session) with an application to implement interaction of the application with at least one component of the TS; at least one component of the TS with which the said application interacts within the framework of the established session, wherein the interaction is carried out through a security gateway, which during the established session analyzes each received request of the application to the TS component and makes a decision on fulfilling the received request.

According to some embodiments of the invention, in the proposed system, the cryptographic material is at least one of: a MAC generation key, a session key, an attestation token, or a certificate.

According to some embodiments of the invention, the proposed system is furthermore configured to exchange data between the security gateway and the execution environment, including with the application, via a secure communication channel.

According to some embodiments of the invention, the proposed system is further configured with a capability in which the security gateway is designed to verify the integrity of the operating system of the runtime environment in order to establish trust in the runtime environment and subsequently in the application.

According to some embodiments of the invention, the proposed system is further configured with the possibility that the component of the vehicle with which the application interacts via the security gateway is at least one of the following: an electronic control unit; a driver assistance system; a telematics system.

According to some embodiments of the invention, the proposed system is further configured with the capability in which the application execution environment is at least one of: a local computing component of the TS, having the ability to download and execute the application; a mobile device interacting with the components of the TS; a remote server communicating with the components of the TS.

According to some embodiments of the invention, the proposed system is further configured with the possibility that the local computing component of the vehicle is an information and entertainment system.

According to some embodiments of the invention, the proposed system is further configured with the capability that the execution environment is a trusted execution environment into which the application is trusted loaded.

According to some embodiments of the invention, the proposed system is further configured with the capability in which the execution environment additionally collects information for certifying the downloaded or launched application, including: the application identifier, the application vendor, the application hash, information about other certificates, the size of the application, and a unique identifier of the execution environment.

According to some embodiments of the invention, the proposed system is further configured with a capability in which the security gateway generates a security policy with respect to the certified application based on the collected information, wherein the security policy includes information about the permitted interactions of the certified application with at least one component of the TS.

According to some embodiments of the invention, the proposed system is further configured with the capability in which said attestation token is intended for an open network connection (session) between the attested application and at least one component of the TS.

According to some embodiments of the invention, the proposed system is further configured to have the capability in which said attestation token verifies the integrity of the application.

According to some embodiments of the invention, the proposed system is further configured with a capability in which the decision taken to execute the received request includes information either on permission and transmission of a command to the component of the vehicle to execute the request received from the application, or on rejection of the said request.

Brief description of the drawings

Additional objects, features and advantages of the present invention will be apparent from reading the following description of the embodiment of the invention with reference to the accompanying drawings, in which:

Fig. 1 shows an example of a system implementing a method for inter-unit control of application access to vehicle components.

Fig. 2 shows an example of network exchange between the application and vehicle components, namely electronic control units.

Fig. 3 shows a diagram illustrating an example of the operation of the method for inter-unit control of application access to a vehicle component.

Fig. 4 shows a method for inter-unit control of application access to vehicle components.

Although the invention is capable of various modifications and alternative forms, the characteristic features illustrated by way of example in the drawings will be described in detail. It should be understood, however, that the purpose of the description is not to limit the invention to a specific embodiment. Rather, the purpose of the description is to encompass all changes and modifications within the scope of the invention, as defined by the appended claims.

Implementation of the invention

The objects and features of the present invention, and methods for achieving these objects and features, will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the embodiments disclosed below; it may be embodied in various forms. The substance given in the description is nothing more than specific details provided to assist those skilled in the art in a comprehensive understanding of the invention, and the present invention is defined only within the scope of the appended claims.

The present invention addresses the shortcomings of the prior art by providing a system and method for inter-unit application access control to vehicle (V) components. For the purposes of this description, the term "vehicle" refers to any vehicle, including at least components that support the vehicle's operation, including movement, and a network for their interaction. In particular, such a vehicle includes an electric vehicle and an autonomous vehicle.

We will also define a number of other terms to further describe the present invention.

The term "vehicle component" refers to vehicle devices, vehicle systems, or vehicle subsystems, other than those explicitly identified as distinctive. Examples of vehicle components include at least:

- electronic systems such as electronic control units (ECUs);

- driver assistance systems, such as advanced driver assistance systems (ADAS);

- in-vehicle infotainment systems (IVI);

- telematic systems;

- various sensors and detectors.

An application is a program developed to achieve specific tasks by utilizing the computing resources of the environment in which the program is executed (hereinafter referred to as the runtime environment). Within the context of this description, the application is also adapted to run within the components of the system, if this is necessary for execution.

A third-party application is any application that is not a mandatory part of the TS and allows for the functionality of TS components to be supplemented, while the said TS components include an execution environment for the execution of the third-party application.

It is worth noting that the applications that require control within the scope of this description are applications created by both third parties (e.g., third-party developers) and the creators of the vehicles themselves.

For the purposes of this description, the term "application" also includes the term "third-party application" and vice versa, except where a specific term is explicitly mentioned.

A runtime environment is a hardware and software system that enables the execution of applications (third-party applications) and provides various services and resources necessary for their operation. Application runtime environments are those components of the IT system that have the functionality to run them, specifically those that have an operating system. A runtime environment can be implemented either as an internal component of the IT system or as an external device, such as on a remote server or mobile device.

An application manifest is a file (such as an XML file) that contains data that identifies the application and describes the application's capabilities by providing at least the following information:

• about restrictions on the use of system resources (for example, RAM);

• about permitted interactions of the application with the functions of the runtime environment (for example, access to geolocation data) and the functions of the components (devices and systems) of the vehicle connected to the runtime environment (for example, permission to send a signal to unlock the doors, permission to send a signal to regulate the operation of the vehicle’s climate control system, or permission to send a signal to receive any data from telematics systems).

It is worth noting that information about the permitted interactions of the application with the functions of the runtime environment and/or the functions of the components of the TS can be presented in the form of access rights to the corresponding functions of the runtime environment and components of the TS.

In one implementation, the term "allowed" app interactions also refers to "permitted" app interactions. For example, in cases where there is no specific list of allowed interactions, but there is a list of prohibited interactions, all interactions except those specifically prohibited are considered permitted.

A secure gateway (SGW) is a component that monitors and controls the interaction of applications with vehicle components, particularly electronic control units, and also enables data routing between vehicle components, including with other application execution environments.

A preferred embodiment of the present invention includes the implementation of an application runtime environment and a security gateway as separate components of the TS, which makes it possible to eliminate limitations in terms of hardware capabilities during joint implementation, and also provides the possibility of independent development of both the runtime environment and the security gateway.

An Electronic Control Unit (ECU) is a device capable of receiving signals from sensors and various vehicle components (e.g., automotive systems) and controlling various actuators based on these signals. Examples of actuators include, but are not limited to, the headlight unit or the brake system.

Further, in the description of the figures, examples of embodiments of the present invention are presented.

Fig. 1 shows an example of a system implementing a method for inter-unit control of application access to vehicle components (hereinafter referred to as the control system).

In general, the control system includes such elements of the vehicle 100 as: a runtime environment 110 , including at least one application 120 , a security gateway 130 and other components of the vehicle, such as components 135 , communication with which is carried out at least via a CAN bus (from the English Controller Area Network).

Within the framework of this description, the components 135 of the vehicle 100 include at least the electronic units of the vehicle, such as the electronic control units (ECU) 180 , other control units 185 , the chassis domain 195 and the electronic system of the vehicle 190 that assists the driver in driving and parking (Advanced Driver Assistance Systems, ADAS). Within the framework of this description, the electronic units of the vehicle are further understood to mean any of the components 135 , except in cases where specific components 135 of the vehicle 100 are explicitly indicated.

As mentioned above, the execution environment 110 can be implemented within the local computing device of the vehicle (not shown in Fig. 1 ) or be it, an external computing device (cloud service, server) 140 , or a mobile device 150. An example of a local computing device of the vehicle or a component of the vehicle is the infotainment system of the vehicle, within which the applications 120 perform their purposes. When implementing the execution environment 110 using the cloud service 140 or the mobile device 150, communication with them is carried out via the information and communication network 170 , for example, the Internet. Communication can also be carried out both by wired and wireless communication using appropriate solutions and technology. In addition, the execution environment 110 includes an operating system, within which the loading, launching and subsequent execution of the application 120 is carried out.

In the context of the present invention, the execution environment 110 is intended to at least:

• downloading or running application 120 ;

• verification (checking) of the authenticity and integrity of the downloaded and/or launched application 120 , including the immutability of the application 120 since its download or last launch.

In one embodiment, both the loading and launch of application 120 are trusted. The loading or launch of application 120 is considered trusted when, as part of the startup of the operating system (OS) of runtime environment 110 , it is confirmed that the OS has not been previously changed or modified, and then, when loading or launching application 120 , its authenticity and integrity are determined. In other words, the loading or launch of application 120 will be considered trusted when a trusted OS load is performed, application 120 is subsequently loaded or launched, and verified by the trusted OS. The task of verifying the trustworthiness of the OS and/or the trustworthiness of application 120 may be performed either using solutions provided by the party that created the OS or the entire runtime environment 110 , or by one of the components of the TS 100 , for example, the security gateway 130 or another module designed or capable of performing the specified task.

In one embodiment of the invention, the security gateway 130 takes over the function of verifying the application 120 , instead of the runtime environment 110. In this embodiment, the security gateway 130 will perform all the same actions for verifying the application 120 that the runtime environment 110 performs, or a part of them.

In a preferred embodiment of the invention, the runtime environment 110 is configured to exchange data with the security gateway 130 via network data exchange, including via a secure communication channel, and to generate a list of information of the downloaded or launched application 120 for verification, which verifies the authenticity and integrity of the application when it is downloaded to the runtime environment 110 , attestation, which confirms the authenticity and integrity of the application when it is launched, and/or providing this list of information to the security gateway 130 , including in connection with the exchange of data initiated by the application 120. It is worth noting that the specified list of information includes at least one of the following materials: a manifest, an identifier, a signature and certificates of the application 120. Additionally, the list of information may include information about the user, his identifiers (login and password), other certificate(s).

Thus, verification (checking) of the application 120 before its installation at least includes checking the integrity and/or authenticity of the application 120 , as well as checking the compliance of the application 120 certificates. In other words, at least the downloaded file package, or APK file (English: Android package kit file), is checked for compliance with the following:

• application 120 is downloaded from a legitimate (trusted) site;

• all licenses and certificates of the 120 application are valid;

• the application manifest is legitimate (valid) and matches the loaded application 120 , and the contents of the manifest have not been modified;

• the manufacturer (vendor) of application 120 is indicated correctly;

• the file package or APK file is signed by a certified party or by the TS 100 manufacturer itself, where the signature confirms that the application 120 complies with the TS requirements.

The certification of Appendix 120 in turn includes at least:

• verification of compliance of Appendix 120 with the certificate issued by the responsible party;

• checking the manifest for compliance with all access rights specified in it (permissions for interaction with other applications and components 135 TS 100 );

• checking the hash value of the application binary file 120 and its signature.

The need to verify the manifest stems from the fact that application 120 may be complete, but the number of access rights in the manifest may be modified, either more or less than originally specified by the application 120 manufacturer and confirmed by the vehicle manufacturer. Moreover, the manufacturer of application 120 and vehicle 100 may be the same person.

In one implementation option, when the runtime environment110represented by a local computing device, such as a vehicle's infotainment system, the application attestation function120can be implemented by generating in the runtime environment110and sending to the security gateway130(for example, in the certification module132) signed with a cryptographic key to confirm the authenticity and integrity of the launched application and its manifest. In response from the security gateway130(for example, from the certification module132) execution environment110obtains cryptographic material (e.g., a MAC key, session key, token, or certificate) that further authenticates the network connection of the application established on behalf of the application120. Runtime environment110stores the received cryptographic material in connection with the corresponding application120. In the future, the application120establishes connections with the security gateway using the mentioned cryptographic material130In one implementation, a connection is established with an MQTT message broker.134(hereinafter referred to as the MQTT broker). MQTT broker134is a module that is part of the security gateway130and designed to send commands to components135TS100, for example to the ECU180, via a CAN-MQTT converter136.

In another embodiment, when the execution environment 110 is represented by the cloud service 140 , the attestation function of the application 120 is completely executed in the cloud service 140 , and the security gateway 130 trusts the results of the attestation performed by the cloud service 140 and the received cryptographic material included in messages and requests (e.g., MQTT) from the application 120 of the cloud service 140 .

In another embodiment, when the execution environment 110 is implemented on the mobile device 150 , the attestation function is performed by interaction between the attestation component of the operating system of the mobile device 150 and the cloud service of the operating system manufacturer (not shown in Fig. 1 ), and the attestation result is provided directly to the application 120. The application 120 , in turn, transmits the attestation result, confirming the authenticity and integrity of the application, and its manifest to the security gateway 130 when establishing a network connection.

In a general embodiment, the security gateway 130 is configured to monitor interactions between the application 120 running within the execution environment 110 and at least one component 135 , such as the ECU 180. To perform its purpose, the security gateway 130 has the ability to perform at least:

• data exchange, including via a secure communication channel, with the execution environment 110, with other components of the TS and other execution environments (if any), including external execution environments;

• checking the integrity of the operating system of the execution environment 110 in order to establish trust in the execution environment 110 ;

• certification of application 120 based on the received list of information from execution environment 110 , while during certification the authenticity and integrity of application 120 is checked;

• generation of confirmation of successful completion of application certification, which includes cryptographic material (for example, an certification token);

• authentication of the network connection of the application 120 .

It's worth noting that, for ease of understanding, a specific implementation of cryptographic materials, namely an attestation token, will be used in the following text. However, cryptographic materials are not limited to this implementation and include other entities, examples of which were presented earlier.

In one embodiment, the security gateway 130 signs the attestation token with a cryptographic key, which helps ensure the integrity of the attestation token during network interaction between the application 120 and the components of the TS, in particular with the security gateway 130 itself.

The security gateway 130, when authenticating the network connection with the application 120, receives a list of information (in particular, containing the manifest or information from it) from the execution environment 110 or the application 120 itself, analyzes it within the framework of attestation, stores the list of information (in particular, the manifest) and sends in response cryptographic material (for example, an attestation token), which ensures further authentication of the network connection established on behalf of the application 120 , the reception (for example, via the MQTT message broker 134 ) of a request to the ECU 180 from the application 120 and the implementation of control over the compliance of said request with the permissions from the application manifest, followed by making a decision on allowing or rejecting said request to the ECU 180. In the event of a decision on allowing, the security gateway 130 , using the CAN-MQTT converter 136, converts the request into a command to the ECU 180 .

The ECU 180 , for example the ECU for controlling the door lock, is configured to interact with the security gateway 130 to receive commands via the CAN-MQTT converter 136 , which converts the received requests from the MQTT broker 134 into commands to the ECU 180 .

Let us consider an example of the interaction of elements of the control system shown in Fig. 1 and implemented within the framework of vehicle 100 .

Let us assume that the application 120 has previously been downloaded and installed into the execution environment 110 , and also certified by the security gateway 130 , wherein the execution environment 110 is a trusted execution environment that ensures the reliable launch and verification of the application 120 . The execution environment 110 generates a list of information for certification in order to confirm the authenticity and integrity of the launched or started application 120 , and provides the specified list of information to the security gateway 130 in connection with the establishment of a network connection from the launched or started application 120 . The list of information provided to the security gateway 130 includes at least an application manifest, which contains information about the access rights granted to the application 120 to at least one component 135 . Security gateway 130, for its part, either attests application 120 based on the information received, or, if attestation was previously performed when loading application 120 , performs authentication to establish a network connection (session) for exchanging data with said application 120 . If the application was previously attested, then the received list of information includes an attestation token, which is used for authentication. Security gateway 130 has information (e.g., in the form of rules) about the access rights that application 120 has. Information about the application's access rights was previously generated by security gateway 130 during application attestation. Security gateway 130 then verifies the received attestation token and compares the received manifest with the information about the access rights of application 120 that it has, and if the verification is successful, establishes a session with application 120 . During a session, application 120 transmits a request to ECU 180 via security gateway 130 , and security gateway 130, in turn, converts the requests into commands and forwards them to ECU 180. In response, security gateway 130 receives data from ECU 180 for application 120 , which it converts into a form understandable to application 120 , and transmits it to it.

For example, the "Doors" application loaded into runtime environment 110 contains a manifest describing the application's access rights to interact (communicate) with vehicle (car) components, in particular, to send a request to lock the doors. Runtime environment 110, on behalf of the "Doors" application, establishes a connection (session) with security gateway 130. Security gateway 130 uses an attestation token to authenticate the connection with runtime environment 110 established on behalf of the "Doors" application. Through this connection, the "Doors" application transmits a request to security gateway 130 , where the request includes a request to lock the doors. Security gateway 130 verifies that the "Doors" application has the access rights to send a request to lock the doors. Upon successful verification of the specified access rights, security gateway 130, using CAN-MQTT converter 136 , converts the request into a CAN command, sends the command to the CAN bus, and then transmits the command to the appropriate door control unit for execution. An example of the operation of MQTT broker 134 and CAN-MQTT converter 136 is shown in the description of Fig. 2 .

It is worth noting that if a network connection is established with security gateway 130 on behalf of an application that does not have access rights to the function it requests, then security gateway 130, when checking the access rights of the specified application associated with the current network connection, generates an access error and the command is not transmitted to component 135 of TS 100 , for example, ECU 180 .

As a result, it becomes possible to launch any application securely in a vehicle. This technology allows for the expansion of vehicle functionality while maintaining a high level of information and functional security. Specifically, the technology enables:

• eliminate the influence of applications, including third-party applications, on electronic control units (ECUs) beyond the explicitly declared function;

• prevent applications from secretly collecting data stored on the vehicle, such as personal data of vehicle users;

• implement support for separate policies for the use of both the vehicle and its components, for example, parking and vehicle movement modes;

• provide support for part of the TS subscription management scheme.

Examples of data that may be collected include vehicle routes and vehicle operating data. The loss of such data may harm the user, both in terms of their physical safety and economic security (for example, by increasing the cost of their insurance policy). The proposed method for inter-unit application access control to vehicle components improves vehicle security by addressing these issues.

In another embodiment of the present invention, during inter-unit access control of applications to at least one component of the vehicle for or during their interaction, the security gateway 130 takes into account another criterion for access to components 135 of the vehicle 100. Such a criterion is the role of the vehicle user. Examples of user roles are: the vehicle owner (role "owner"), the vehicle driver (role "driver"), the service person, the mechanic (role "engineer"). Roles may have different access rights and be assigned to different users. For example, the role "driver" may be set by default for any driver of the vehicle. In addition, each role may be endowed with certain privileges. For example, when the role "owner" is activated, the user has the right to send the signal "open the trunk/hood", but when the role "driver" is activated, this right is not granted. In another example, a user with the "owner" role and the "winter package" subscription can send signals (commands) to components 135 to activate the vehicle's heated steering wheel and/or seat heating functions. In yet another example, a user (driver) with the "owner" role has the privilege (right) to activate the "autopilot" (ADAS) component 190 , while a driver with the "driver" role does not. It's worth noting that the driver's role is assigned when they authenticate with vehicle 100 , and at that moment, the rights available to the corresponding role are activated. The role can also be changed, but doing so requires reauthentication.

In another embodiment of the present invention, during the inter-unit control of application access to at least one component of the vehicle, the security gateway 130 takes into account another criterion for determining access to the components 135 of the vehicle 100 and the possibility of transmitting a signal and subsequently a command to one of the components 135. Such a criterion is the state of the vehicle 100 itself. Examples of the states of the vehicle 100 are the following: Closed (vehicle in full lock mode, engine off), Opened (vehicle in unlocked mode, engine off), Ready to drive (vehicle in unlocked mode, engine running), Drive (vehicle in driving mode), Parking (vehicle in waiting mode for movement or locking). The criterion of the vehicle state can also affect the operation of the security gateway 130 during the determination of access (transmission of a signal and/or command) of an application 120 to the components 135 .

OnFig. 2an example of network communication between at least one application, such as an application, is presented120, and one of the components135TS100, namely with an electronic control unit180In other words, an example of how an MQTT broker works is presented.134 and CAN-MQTT converter 136.

It is worth noting that initially the application 120 is launched in the execution environment 110 with the established user rights and, accordingly, further interaction of the application 120 with the components 135 of the TS 100 is carried out within the framework of the launched process after the launch of the application 120 .

As mentioned earlier, the MQTT broker 134 and the CAN-MQTT converter 136 are part of the security gateway 130 and are designed to convert requests from applications 120 to components 135 of the vehicle 100 , in particular, to the ECU 180 .

Fig. 2 shows three ECUs: ECU 180a , ECU 180b , and ECU 180c . ECU 180a is responsible for interacting with the vehicle's speed controller. ECU 180b is responsible for interacting with the vehicle's doors. ECU 180c is responsible for interacting with the vehicle's headlights. Each ECU communicates with MQTT broker 134 via CAN-MQTT converter 136. This communication involves receiving commands, executing them using the ECU, and transmitting the results of the executed commands in response.

MQTT broker 134 includes access object identifiers (MQTT topic identifiers) of vehicle components with which interaction is possible. For example, these include vehicle components such as the speed controller, doors, and headlights. The access object identifier for the speed controller is "speed," for doors it is "doors," and for headlights it is "light." Each identifier defines possible command signals that can be transmitted to components 135 of vehicle 100 via the corresponding ECUs 180 .

Application 120 sends a request to MQTT broker 134 for the required actions. The application sends the request by sending a message with a specified access object identifier. For example, application 120 needs to close a door. Application 120 generates a request containing the "close" information and adds the "doors" identifier to it. It then sends a "close" message with the "doors" identifier, which refers to the vehicle's "doors" component, to MQTT broker 134. CAN-MQTT converter 136 then converts the recorded "close" message into a command (signal) and forwards the command to the appropriate ECU, in this case, ECU 180b . After ECU 180b executes the command, a command execution signal is sent back, which is converted back into a message, and application 120 reads the command execution result information.

It is worth noting that application 120 transmits requests to MQTT broker 134, as mentioned earlier, within the framework of an open session with security gateway 130 . The session between application 120 and MQTT broker 134 is formed as follows. Application 120 sends a request (CONNECT packet) to connect to MQTT broker 134 . The request contains authentication data, which includes at least confirmation of successful attestation (cryptographic material). As additional authorization information, the request may contain user information, certificate(s), etc. MQTT broker 134 verifies the received set of information and, if the verification is successful, opens a session with application 120 . Confirmation of successful or unsuccessful verification is sent to the process by sending a CONNACK packet.

During validation, MQTT broker 134 will check whether the application's permissions match the application request. Previously, when attesting application 120, security gateway 130 determined the permissions of application 120 based on the application manifest. For example, application 120 requested permissions to read and write data with the ID "doors," read data with the ID "speed," and write data with the ID "light." Accordingly, MQTT broker 134 will check the request to ensure it matches the application's permissions and then allow or deny the appropriate actions.

In another specific implementation option, authentication and authorization of access rights will be split into two parts. In other words, authorization for reading data is separate from authorization for writing data. In this case, authentication and authorization for reading data with access object identifiers is performed within a session (as in the previously described option), and authentication is performed each time a write operation is performed. In this case, application 120 subscribes to read all data with the corresponding access object identifiers. The application then reads data with the corresponding access object identifier within the session. Moreover, each time application 120 sends data to MQTT broker 134 , application 120 signs the specified data with the cryptographic material previously obtained during successful attestation. In turn, MQTT broker 134 verifies the message signature (authenticates) upon receipt and, if verified successfully, further transmits it through CAN-MQTT converter 136 to ECU 180 . Thus, the MQTT broker 134 authenticates the application 120 that sent the message each time, confirming its authenticity.

Fig. 3 shows a diagram illustrating an example of the operation of a method for inter-unit control of application access to at least one component of a vehicle.

Let's assume that you need to launch an application that allows you to interact with the mechanism responsible for locking and unlocking the car doors (hereinafter referred to as the "doors" application).

The scenario for inter-block application access control to a vehicle component includes steps that can be conditionally divided into three blocks.

The first block of steps is preparatory and is responsible for installing the application 120 into the execution environment 110 of the TS 100 , as well as verifying the application 120 , wherein the first block of steps includes steps 301–304 .

Step 301. Runtime 110 begins downloading the "door" application. It's worth noting that the application can be downloaded to runtime 110 either through security gateway 130 or without it. For example, runtime 110 will contact third-party server 160 , which hosts the application download file 120 , or the user will download application 120 directly to runtime 110 .

Step 302. During installation, runtime environment 110 verifies information about application 120 and generates a list of information for its subsequent certification. The list of information includes at least one of the following materials: a manifest, an identifier, and certificates of application 120. In a particular implementation case, the list of information includes part of the information from the manifest and/or certificates of application 120 , namely: the name of the application, the application ID, its version, size, hash, installation date, device ID, etc. Runtime environment 110 downloads the manifest and certificates together with the "door" application. In addition, information for the list of information can be obtained from the internal services of TS 100 , in particular, runtime environment 110 .

Step 303 . Runtime 110 passes the list of information to the attestation module 132 running on the security gateway 130 .

Step 304. Security gateway 130 verifies (checks) the door application by checking the received information from the information list in order to establish the authenticity and integrity of the application and, in case of successful checks, adds information about the door application in the execution environment 110. The parameters of these checks are at least time and trust in the execution environment 110 .

The second block of steps is certification and is responsible for certification of application 120 in security gateway 130 of TS 100 , and the second block of steps includes steps 305–308 .

Step 305. Runtime 110 launches the "door" application process, during which it collects up-to-date information about the application (name, application ID, hash, manifest with privileges, launch time, etc.). The up-to-date information can be collected from several sources, which can be either internal to TS 100 or external to TS 100. One such source can be "platform device attestation services for mobile platforms."

Step 306 . The execution environment 110 verifies the authenticity of the collected information using cryptographic methods that ensure the protection of the information, and transmits the specified information to the security gateway 130 .

Step 307. Security gateway 130 verifies (validates) the door application by checking the information received from runtime environment 110 from the information list to confirm the authenticity and integrity of the application. If the verification is successful, it analyzes the door application's privileges specified in the manifest. During the analysis, a security policy is applied that takes into account the context of vehicle 100 and the user. Examples of such contexts include the current user's roles, vehicle states, subscription statuses, and the presence of access rights described in the manifest. As a result of successful attestation, a token is generated containing a subset of the access rights corresponding to the application according to the manifest.

Step 308. Security gateway 130 sends a response to runtime 110 regarding the success or failure of attestation. If successful, the response contains cryptographic material, such as an attestation token. The response may also be signed with the cryptographic key of security gateway 130 .

The third block of steps is operational and is responsible for the network interaction of the application 120 through the security gateway 130 with the components 135 of the TS 100 , while the third block of steps includes steps 309 - 316 .

Step 309. After launching and successfully attesting, the "door" application authenticates and/or authorizes itself with the MQTT Broker 134 service using the previously obtained attestation token. Authentication can be performed either per session by sending a CONNECT packet with the attestation token, or per request, which must include the attestation token, which links the message content to the process authentication data (MAC).

Step 310. MQTT broker 134 of security gateway 130 informs the door applications about the successful or unsuccessful opening of the session as a result of authentication. If the session is not opened successfully, the work is terminated. Otherwise, if the session is opened successfully, proceed to step 311 .

Step 311. The "doors" application, within the current session, requests MQTT broker 134 to provide it with certain data from certain ECUs 180. In other words, it subscribes to security gateway 130 , namely MQTT broker 134 , to receive information about the current speed of vehicle 100 and the current status of vehicle 100 doors. As part of the subscription, security gateway 130 , using MQTT broker 134 within the current session and taking into account the request for current information, performs the following steps.

Step 312. ECUs 180a and 180b regularly send messages about the current status to security gateway 130 .

In one embodiment of the invention, the frequency of messages provided is determined empirically, for example, by analyzing safety requirements and taking into account the CAN bus bandwidth. For example, messages may be sent as frequently as every 10 ms or less frequently.

Step 313. In security gateway 130, CAN-MQTT converter 136 receives all current status messages from ECUs 180a and 180b .

Step 314. The CAN-MQTT converter 136 generates MQTT messages based on the statuses received via the CAN bus and sends them to the appropriate queues of the MQTT broker 134 .

Step 315. MQTT broker 134 receives messages from CAN-MQTT converter 136 and transmits them to the "doors" application, since it has previously subscribed to the corresponding queues (speed and doors).

Step 316. The Doors application receives messages with current information about the speed and status of the doors, and then performs actions according to its internal logic in response to the new information.

An example of the internal logic of the "Doors" application is the following. The "Doors" application received a message that the doors are open and the speed of vehicle 100 is greater than 15 km/h. In response, the "Doors" application generates a command to close the doors to ECU 180b . The "Doors" application then sends the door close command to MQTT broker 134. MQTT broker 134 receives the message (the door close command) from the "Doors" application, performs a security check based on the current session rights or the attached attestation token, and, if successful, passes the message to CAN-MQTT converter 136. CAN-MQTT converter 136 applies the policy regarding the ability to send a command to ECU 180b on the CAN bus and, if possible, converts the received message into a CAN frame. The CAN-MQTT 136 converter sends a command to the CAN bus for the 180b ECU. The 180b ECU receives the command and executes it, specifically locking the doors. The 180b ECU switches its internal state to "doors locked" and sends corresponding notifications back to the CAN bus.

Fig. 4 shows a block diagram illustrating an example of the implementation of a method for inter-unit control of application access to at least one component of a vehicle (hereinafter referred to as method 400 ).

The presented method 400 is implemented using at least the elements of the control system described in Fig. 1. Depending on the implementation option, the method 400 can be performed either within the framework of sequentially executed steps or by dividing said steps into two stages, with some of the steps being performed in parallel or simultaneously. Moreover, the execution of the stages can be either spaced out in time or performed continuously.

It's worth noting that the description of method 400 below refers to a downloaded application 120 , but method 400 is also applicable to a launched application 120 , as well as a preinstalled application (an application provided with the runtime environment). Therefore, it's important to understand that although the description refers to actions taken when downloading application 120 , the steps of method 400 are also applicable when launching application 120 , only instead of downloading application 120 , it refers to launching application 120 . Furthermore, in cases where the application is preinstalled, downloading is not required.

In one embodiment of the method, the steps of the first (preliminary) stage may be performed once, while the steps of the second (main) stage may be repeated more than once. Method 400 may also be implemented without dividing it into stages.

The first (preliminary) stage includes steps 410 , 420 , 430 , 440 and 450 .

At step 410, application 120 is loaded into execution environment 110 , wherein application 120 includes at least a manifest containing at least data that allows identifying the application, as well as information about permitted interactions with components 135 , including electronic units 180. Information about permitted interactions of application 120 , contained in the manifest, is typically presented in the form of a list of permitted interactions of application 120 with components 135 of vehicle 100 , in particular, with electronic control units of vehicle.

In one embodiment, the manifest is a file that in turn contains metadata about the application 120 and determines its behavior throughout its life cycle, including the aforementioned information about permissible interactions with other applications 120 and components 135 of the TS 100 .

The loading of the application 120 into the execution environment 110 is carried out by at least one of the following variants. In the first variant, the component of the vehicle 100 , such as the infotainment system (IVI), carries out an independent loading from the remote server 160 via the Internet 170 . The remote server 160 is, for example, a specialized platform for distributing applications. In one of the embodiments, said specialized platform has the ability to interact with the execution environment 110 through so-called "app stores" that can be installed on user devices. Examples of such applications are applications such as "RuStore", "App Store", "Google Play Store" or "Uptodown". The user devices are, for example, a mobile device 150 . In the second variant, said loading of the application 120 into the execution environment 110 is carried out using a security gateway 130 , which additionally carries out verification, during which the authenticity and integrity of the downloaded application 120 is checked.

In one embodiment, downloading the application 120 includes checking and installing the application in the execution environment 110 . Said checking (verification) of the application 120 before its installation is aimed at checking the integrity and/or authenticity of the application 120 , as well as checking the compliance of the certificates of the application 120 . In other words, at least the downloaded file package, or APK file (English: Android package kit file), is checked for compliance with the following:

• application 120 is downloaded from a legitimate (trusted) site;

• all licenses and certificates of the 120 application are valid;

• the application manifest is legitimate (valid) and matches the loaded application 120 , and the contents of the manifest have not been modified;

• the manufacturer (vendor) of application 120 is indicated correctly;

• the file package or APK file is signed by a certified party or by the TS 100 manufacturer itself, where the signature confirms that the application 120 complies with the TS requirements.

In another embodiment, the security gateway 130 performs a verification step of the application 120 before installation into the execution environment 110 and, upon passing the specified verification, transfers the application 120 for installation into the execution environment 110 or independently installs the application 120 into the execution environment 110 .

As previously mentioned, the execution environment 110 is understood to include at least the following components of the TS 100 :

(1) In-Vehicle Infotainment (IVI);

(2) components of the instrument cluster, namely the instrument panel, which presents various information about the state of the vehicle, for example, a car, and allows for the control of the functions of other components of the vehicle;

(3) multimedia system;

(4) a mobile device connected to vehicle components via a specific application.

It can be said that the execution environment 110 can be any component of the vehicle that allows loading and executing the application 120 (a third-party application) within the operating system of the corresponding component of the vehicle 100 to implement the purpose of the application 120. For example, the application 120 can be responsible for controlling the mechanism for locking and unlocking the doors of the vehicle 100 , as well as for providing information about the state of the doors of the vehicle 100. In the case when the execution environment 110 is implemented within the mobile device 150 , the said mobile device 150 interacts with the components 135 of the vehicle 100 through the security gateway 130 , and the communication between them can be implemented both via a wired (physical) connection using a cable connection, and using wireless solutions (e.g., Wi-Fi, BLE). It is worth adding that the execution environment 110 can be not only a component of the vehicle, but also a component outside the vehicle (a mobile device, a remote server).

In another embodiment, the execution environment 110 is, among other things, a trusted component of the TS 100. A trusted execution environment is understood to be an execution environment that has been installed or loaded by means of monitoring the specified actions (installation or loading) by the security gateway 130 , wherein the security gateway 130 determines and verifies the integrity of the operating system of the execution environment 110 .

At step 420, information is collected (formed into a list) using the execution environment 110 for conducting the certification of the loaded (or launched) application 120. The formed list includes at least the following information:

• application ID 120 ,

• manufacturer (vendor) of the application 120 ,

• application hash sum 120 (current checksum),

• information about the certificate,

• manifesto,

• information about the size of the application 120 ,

• unique identifier of the execution environment 110 (for example, ID IVI),

• additional information, for example, about the vehicle or device from which the application was downloaded.

It is worth noting that the identifier of the execution environment 110 refers to the identifier of the component of the TS 100 , which implements the execution environment 110 for the operation of applications 120 . After collecting all the necessary information, the generated list is signed with the key of the execution environment 110 , for example, a cryptographic key, and transmitted for certification in the form of an attestation request to the security gateway 130 .

At step 430, the downloaded application 120 is attested using the security gateway 130 based on the information received from the execution environment 110. During the attestation, the authenticity and integrity of the application 120 are confirmed, in particular, the immutability of the application 120 since the application 120 was verified by the responsible party. The responsible party may be either the vehicle manufacturer (automaker) or a certified third party. The attestation includes at least one of:

• verification of compliance of Appendix 120 with the certificate issued by the responsible party;

• checking the manifest for compliance with all access rights specified in it (permissions for interaction with other applications and components of the TS 100 ), since the application 120 may be complete, but at the same time the number of access rights in the manifest may be changed either more or less than was originally specified by the manufacturer (developer) of the application;

• checking the hash value of the application binary file 120 and its signature.

In other words, the security gateway 130, when attesting the application 120 , checks the access rights of the application 120 in the context of the components 135 of the TS 100 .

In one embodiment, in addition to checking the access rights of application 120, in the context of components 135 of vehicle 100, the role of the user (driver) of vehicle 100 is also taken into account, according to which vehicle 100 is controlled in the corresponding session of application 120 .

In one embodiment, to perform the attestation of the application 120, the security gateway 130 interacts with servers, such as the server 140 and the third-party server 160 , to obtain current information about the application 120 being attested. The current information is information similar to the information about the application received from the runtime environment 110 , in particular, licenses, certificates, vendor and/or manifest. In another embodiment, the security gateway 130 includes a database that contains the said information and has the ability to update or obtain information for storage, wherein the database is populated both at the request of the security gateway 130 and in automatic mode. The populating (updating or obtaining information) of the database is performed both by the security gateway 130 itself and by a third-party component. For example, when loading the application 120 , information about the loaded application 120 is provided, and the security gateway 130 collects and stores the necessary data for subsequent attestation.

In another embodiment, during certification, security policies are generated with respect to the application being certified 120 using the security gateway 130 based on the received certification data, in particular, the application manifest. The security policies include information on the permitted (acceptable) interactions of the certified application 120 with at least one component 135 of the vehicle 100 , including the electronic control unit 180 .

At step 440, based on the attestation result, security gateway 130 generates confirmation of successful attestation, specifically confirmation of the authenticity and integrity of said application 120 in the form of cryptographic material, an example of which is an attestation token. Other examples of cryptographic material implementations include a certificate, a session key, or a MAC generation key. In one embodiment, security gateway 130 generates an attestation token as confirmation, indicating that the attestation check was successfully completed. Additionally, the attestation token is signed with the cryptographic key of security gateway 130 . The attestation token will subsequently ensure the privacy of network interactions between the attested application 120 and security gateway 130 , since the attestation token is personalized for each application 120 .

Personalizing the attestation token for each application 120 allows for the requirement that the attestation results of one application cannot be used for network communication between another application and the security gateway 130 .

In one embodiment, the attestation token is intended to open a network interaction (session) between the attested application 120 and at least one component 135 of the TS 100 , and subsequently, until the session is closed, network interaction between the application 120 and the component 135 of the TS 100 can be carried out without the specified token.

It's worth noting that if attestation fails, security gateway 130 sends a response to application 120 and/or runtime 110 containing information about the reasons for the attestation failure. In a particular implementation, the attestation failure response also includes information about the time limit for re-attestation.

At step 450, a confirmation of successful completion of the attestation is transmitted using the security gateway 130 , in particular, a confirmation of the authenticity and integrity of the mentioned application 120 is transmitted in the form of an attestation token.

Depending on the implementation option, the transfer of said confirmation (attestation token) is carried out either directly to the application 120 that has been attested, or to the execution environment 110 that executes the application 120 , or to the application 120 and the execution environment 110 simultaneously.

The second (main) stage includes steps 460 and 470. These steps are performed during the network interaction of application 120 with components 135 of TS 100 through security gateway 130 .

At step 460, a network connection (session) is established with the security gateway 130 using the execution environment 110 on behalf of the certified application 120 , during which authentication of the application 120 and/or authorization of the access rights of the application 120 are performed. For authentication or authorization of the access rights of the application 120 and further network exchange with at least one component 135 (for example, the ECU 180 ), the TS 100 transmits at least one request together with a previously received attestation token. The attestation token allows the application 120 to be authenticated or authorized, and if the authentication or authorization is successful, the request is transmitted to the corresponding component 135 of the TS 100 . An example of network exchange, in particular the transmission of a command and the receipt of a response between the application 120 and one of the components 135 of the vehicle 100 , for example the ECU 180 , was presented earlier in the description of Fig. 2 .

It is worth noting that if a network connection is established with the security gateway 130 on behalf of the application 120 that does not have access rights to the function it requests, then the security gateway 130 , when checking the access rights of the specified application 120 associated with the current network connection, generates an access error, and the command will not be transmitted to the component 135 of the vehicle 100 , for example, the ECU 180 .

In one implementation option, the attestation token is transmitted only the first time a session is established, and subsequent network exchanges are carried out within the established session, without providing the attestation token until the end of the session.

In another embodiment, a time period is determined after which the application 120 must be re-provided with an attestation token for authentication with the security gateway 130 .

At step 470, each transmitted request from application 120 to one of the components 135 of vehicle 100 via the established network connection is analyzed by security gateway 130 , determining the possibility of transmitting the corresponding command to fulfill the received request using the formed policy. Based on the results of the analysis, a decision is made to permit or deny the transmission of the command to the corresponding vehicle component, for example, to ECU 180 , to fulfill the request received from application 120 .

It is worth noting that the application 120 interacts with the components 135 of the vehicle 100 , in particular with the ECU 180 , through the security gateway 130 , which in turn interacts with the components 135 using the MQTT broker 134 and the CAN-MQTT converter 136. During network interaction, the application 120 sends a request containing a command to read or write the data required by the application 120 to the MQTT broker 134. The MQTT broker 134, in turn, transmits the received commands to the CAN-MQTT converter 136. The CAN-MQTT converter 136 converts the commands into a form that is understood by the corresponding ECU 180 , after which it sends the commands to the corresponding ECU 180 . After the response from ECU 180 , data will be transmitted in the opposite direction to application 120 via CAN-MQTT converter 136 and MQTT broker 134 .

In conclusion, it should be noted that the information provided in the description is exemplary and does not limit the scope of the present invention as defined by the claims. One skilled in the art will recognize that the development of any practical embodiment of the present invention requires making numerous embodiment-specific decisions to achieve specific goals, and these specific goals will vary from embodiment to embodiment. It is understood that such development efforts may be complex and time-consuming, but they will nevertheless be a routine engineering task for those of ordinary skill in the art, given the benefit of this disclosure.

Claims (54)

1. A method for inter-unit control of access of an application to at least one component of a vehicle (TS), wherein said method comprises the steps of: a) load the application into the execution environment, where the application includes at least an application certificate and a manifest containing information about permitted interactions with the components of the TS (access rights); b) collect information using the runtime environment to perform attestation of the downloaded application, where the collected information includes the manifest and/or certificate information of the application, and the collected information is signed with the runtime key; c) certify the downloaded application using the security gateway based on the collected information; d) generate cryptographic material confirming successful completion of certification using a security gateway, and transmit the generated cryptographic material to the specified execution environment using the security gateway; d) establishing a session between the application and at least one component of the TS through a security gateway, during which the application's access rights are authenticated using cryptographic material; e) carry out, using a security gateway, an analysis of at least one received application request within the established session to a TS component, as a result of which a decision is made to execute the received request. 2. The method according to claim 1, wherein the cryptographic material provides authentication of the network connection of the specified application, and which is at least one of: a key for generating a MAC, a session key, an attestation token or a certificate. 3. The method according to claim 1, wherein the application interacts through a security gateway with at least one of the following components of the TS: a) electronic control unit (ECU); b) driver assistance system; c) telematics system. 4. The method according to claim 1, wherein the application execution environment is at least one of: • a local computing component of the TS that has the ability to download and execute an application; • a mobile device interacting with vehicle components; • a remote server that has a connection with the components of the vehicle. 5. The method according to claim 4, wherein the local computing component of the vehicle is an infotainment system. 6. The method according to paragraph 1, in which the information collected for conducting certification of the downloaded application additionally includes: the application identifier, the application vendor, the application hash sum, information about other certificates, the application size, and a unique identifier of the execution environment. 7. The method according to claim 1, wherein the execution environment is a trusted execution environment, and the application is loaded into said trusted execution environment. 8. The method according to paragraph 1, in which, at step c), a security policy is formed in relation to the certified application based on the collected information, wherein the security policy includes information about the permitted interactions of the certified application with at least one component of the TS. 9. The method according to paragraph 8, in which the received application request to the TS component is analyzed using the generated security policy. 10. The method according to paragraph 1, in which the attestation token is intended for an open network connection (session) between the attested application and at least one component of the TS. 11. The method according to paragraph 1, wherein said attestation token confirms the integrity of the application. 12. The method according to paragraph 1, in which at least one received request is analyzed within the established session to the TS component to determine the possibility of transmitting a specific command to the TS component to execute the received request. 13. The method according to paragraph 1, in which the decision taken to execute the received request includes information either on permission and transmission of a command to the TS component to execute the request received from the application, or on rejection of the said request. 14. A system for inter-unit control of access of applications to at least one component of a vehicle (TS), wherein said system includes: a) at least one execution environment, which is a computing component containing at least one processor and memory for implementing an operating system, within which at least one application is executed, interacting with at least one component of the TS, wherein the application includes at least a manifest containing information about permitted interactions with components of the TS (access rights), and an application certificate, and the execution environment is intended for: • downloading and executing the application; • monitoring the integrity of the specified application, including the immutability of the application since its download or last execution; b) a security gateway designed to at least: • data exchange with the execution environment, including with the application and with other components of the TS; • application certification based on information received from the execution environment, during which the identity and integrity of the application is checked; • generation of confirmation of successful completion of certification by the application, which includes the generation of cryptographic material; • authentication of the application's network connection; • establishing a network connection (session) with the application to implement interaction of the application with at least one component of the TS; c) at least one component of the TS with which the specified application interacts within the established session, wherein the interaction is carried out through a security gateway, which during the established session analyzes each received request of the application to the component of the TS and makes a decision on the execution of the received request. 15. The system of claim 14, wherein the cryptographic material is at least one of: a MAC generation key, a session key, an attestation token, or a certificate. 16. The system according to paragraph 14, in which the exchange of data between the security gateway and the execution environment, including with the application, is carried out via a secure communication channel. 17. The system of claim 14, wherein the security gateway is additionally designed to check the integrity of the operating system of the execution environment in order to establish trust in the execution environment and subsequently in the application. 18. The system of claim 14, wherein the component of the TS with which the application interacts through the security gateway is at least one of the following: a) electronic control unit; b) driver assistance system; c) telematics system. 19. The system of claim 14, wherein the application execution environment is at least one of: • a local computing component of the TS that has the ability to download and execute an application; • a mobile device interacting with vehicle components; • a remote server that has a connection with the components of the vehicle. 20. The system according to claim 19, wherein the local computing component of the vehicle is an infotainment system. 21. The system of claim 14, wherein the execution environment is a trusted execution environment into which the application is trusted loaded. 22. The system of paragraph 14, wherein the execution environment additionally collects information for conducting certification of the downloaded or launched application, including: the application identifier, the application vendor, the application hash, information about other certificates, the size of the application, and a unique identifier of the execution environment. 23. The system of claim 14, wherein the security gateway generates a security policy with respect to the attested application based on the collected information, wherein the security policy includes information about the permitted interactions of the attested application with at least one component of the TS. 24. The system of claim 14, wherein said attestation token is intended for an open network connection (session) between the attested application and at least one component of the TS. 25. The system of paragraph 14, wherein said attestation token verifies the integrity of the application. 26. The system according to paragraph 14, in which the decision taken to execute the received request includes information either on permission and transmission of a command to the TS component to execute the request received from the application, or on rejection of the said request.