WO2023179102A1

WO2023179102A1 - Method for determining trusted identity of application, and management unit and device

Info

Publication number: WO2023179102A1
Application number: PCT/CN2022/137827
Authority: WO
Inventors: 周广宇; 赵俊化
Original assignee: 华为技术有限公司
Priority date: 2022-03-22
Filing date: 2022-12-09
Publication date: 2023-09-28
Also published as: CN114844672A; CN114844672B

Abstract

Disclosed in the embodiments of the present application are a method for determining a trusted identity of an application, and a management unit and a device, which can be applied to the field of vehicles. The method comprises: pre-constructed user mode software (i.e. a middleware trusted base) firstly establishing an identity connection with a target application (e.g. a first application, a second application, etc.), and receiving, by means of a first identity channel, "request to communicate with the second application", which is sent by the first application; and the middleware trusted base obtaining a second request according to identity information, which is injected into the first request, of the first application, and sending the second request to the second application by means of a second identity channel, so that the second application determines, on the basis of the identity information in the second request, whether to establish a first communication channel with the first application. In the embodiments of the present application, an identity connection with each application is constructed completely on the basis of a middleware trusted base of user state software, with little dependence on a kernel, and a higher flexibility is achieved. In addition, on the basis of the constructed identity connection, communication data can be fused with identity data, such that the number of times of communication is reduced, thereby improving the performance of a device.

Description

An application trusted identity confirmation method, management unit and device

This application requests the priority of the Chinese patent application submitted to the China Patent Office on March 22, 2022, with the application number 202210283816.4 and the application title "A method, management unit and device for confirming trusted identity", and its entire content incorporated herein by reference.

Technical field

This application relates to the field of data security, and in particular to a method, management unit and device for confirming an application's trusted identity.

Background technique

With the rapid development of the Internet, data security issues have become increasingly prominent. For example, compared with traditional fuel vehicles, intelligent connected vehicles need to face attackers from the entire Internet. Therefore, in the field of autonomous driving, automotive software practitioners need to deal with new security issues brought about by intelligence. Only by solving digital security The problem is that only the autonomous driving platform can ensure the safe driving of end users. A complete intelligent connected car usually involves a dozen or even dozens of electronic control units (ECUs). Each ECU deploys different software stacks based on its electronic device architecture complexity requirements. As the core computing center of intelligent connected vehicles, the core operating system of the intelligent driving platform usually has various atomic services deployed on it. Communication is required between these services and between clients and services to complete the function of car driving. In these communications, data security issues such as user privacy are often involved. Some critical communications also affect the driving safety of the vehicle. In this case, how to ensure the security of communications involved in car driving becomes crucial.

Currently, the identity authentication mechanism based on SSL/TLS/HTTPS is widely used in Internet applications. Taking TLS as an example, a two-way certificate authentication process requires a four-way handshake process. In a complete TLS two-way authentication handshake process, the server verifies the certificate from the client, and the client verifies the certificate from the server, thereby establishing a trust mechanism based on cryptography. After completing the two-way authentication, the server and the client conduct encrypted secure communication based on the negotiated key.

The process of the above-mentioned certificate-based authentication mechanism requires the participation of a trusted third-party organization, such as a certificate authority (certificate authority, CA). And the CA needs to issue certificates for both ends of the communication. This will introduce certificate issuance costs, certificate storage costs, and certificate maintenance costs, making it a complex solution. In addition, when building a TLS chain, a handshake mechanism needs to be introduced based on certificate authentication, and the handshake mechanism requires multiple certificate verification processes, which is time-consuming. Therefore, in the car, some scenarios that are highly sensitive to delay are not suitable for using TLS-based authentication communication methods.

Contents of the invention

The embodiments of this application provide an application trusted identity confirmation method, management unit and device, which are used to build an identity connection with the target application based entirely on a middleware trusted base of user-mode software, which is independent of the kernel and more flexible; In addition, based on the built identity connection, communication data can be integrated with identity data, saving the number of communications and improving device performance.

Based on this, the embodiments of this application provide the following technical solutions:

In the first aspect, the embodiments of this application first provide a method for confirming an application's trusted identity, which can be used in the field of data security, especially in the field of intelligent connected cars. The method includes: first, establishing a middleware trusted base The identity connection with the target application. The middleware trust base is pre-built user mode software. The target application at least includes the first application and the second application. After the identity connection with the target application is established, The middleware trusted base then receives the first request sent by the first application through the first identity channel. The first request can also be called a communication initialization request, which is used to indicate that the first application requests to communicate with the second application. The first request The identity channel is an identity channel corresponding to the first application. Afterwards, the middleware trusted base can obtain a second request based on the first request, wherein the second request includes the identity information of the first application, and the middleware trusted base will pass the third request established when establishing the identity connection. The second identity channel sends the second request to the second application. It should be noted that the second identity channel is an identity channel corresponding to the second application. After receiving the second request sent by the middleware trusted base, the second application will obtain the identity information of the first application from the data message of the second request, and decide whether to establish a communication channel with the first application based on the identity information. , this communication channel can be called the first communication channel (ie, safe channel).

In the above embodiments of the present application, the embodiment of the present application establishes identity connections with each application process based on the constructed middleware trust base, which is more flexible; and in the communication initialization stage of the process, the middleware trust base The identity information of the initiating process is added to the communication initialization request to enable the receiving process to identify whether the initiating process is a reliable application process. This eliminates the need for additional identity transmission processes, saves the number of communications, and improves communication performance; in addition, the intermediate The software trust base is completely user-mode software, has no dependence on the kernel, and is more universal.

In a possible implementation manner, the middleware trust base establishes an identity connection with the target application in the following manner: the middleware trust base establishes an identity connection with the target application through execution management.

In a possible implementation manner, the middleware trustworthy base establishing an identity connection with the target application may also be: the middleware trustworthy base establishes an identity connection with the target application using the configuration file of the target application.

In a possible implementation manner, the middleware trusted base obtains the second request based on the first request. The middleware trusted base injects the identity information of the first application into the first request, thereby obtaining the second request containing the first request. The second request for the identity information of the first application integrates the communication data with the identity data, thereby eliminating the need for additional identity transmission processes, saving the number of communications, and improving communication performance.

In a possible implementation, the access rights of the first identity channel are subject to a first restriction, and the first restriction includes at least any one of the following: the identity connection between the third application and the middleware trusted base cannot be created or accessed, Wherein, the third application and the first application are different applications; or, the data transmitted on the second communication channel cannot be accessed, wherein the second communication channel is a communication channel different from the first communication channel.

In a possible implementation, the access rights of the second identity channel are subject to a second restriction, and the second restriction includes at least any of the following: the identity connection between the fourth application and the middleware trusted base cannot be created or accessed, Wherein, the fourth application and the second application are different applications; or the data transmitted on the second communication channel cannot be accessed, wherein the second communication channel is a different communication channel from the first communication channel.

In a possible implementation, the access permission of the first communication channel is subject to a third restriction, and the third restriction includes at least any of the following: the identity connection between the target application and the middleware trusted base cannot be created or accessed; or , data transmitted on the second communication channel cannot be accessed, wherein the second communication channel is a communication channel different from the first communication channel.

In the above embodiments of the present application, in order to prevent malicious processes from launching attacks on the identity connection during the communication process, for example, trying to create other people's identity connections to launch counterfeit attacks, or maliciously tampering with the identity injected by the middleware trust base during the communication process Information etc. The access rights of the above-mentioned channels (such as the first identity channel, the second identity channel, the first communication channel, etc.) are restricted by the operating system kernel, thereby improving data security.

In a possible implementation, the first application and the second application belong to application programs in the same operating system.

The second aspect of the embodiments of the present application provides a management unit that has the function of implementing the method of the above-mentioned first aspect or any possible implementation of the first aspect. This function can be implemented by hardware, or it can be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

The third aspect of the embodiment of the present application provides a device, which may include a memory, a processor and a bus system, wherein the memory is used to store programs, and the processor is used to call the program stored in the memory to execute the first aspect of the embodiment of the present application or The first aspect is any possible implementation method.

The fourth aspect of the embodiments of the present application provides a computer-readable storage medium. The computer-readable storage medium stores instructions. When run on a computer, the computer can execute the first aspect or any one of the first aspects. Possible implementation methods.

The fifth aspect of the embodiment of the present application provides a computer program that, when run on a computer, causes the computer to execute the method of the above-mentioned first aspect or any possible implementation of the first aspect.

The sixth aspect of the embodiment of the present application provides a chip. The chip includes at least one processor and at least one interface circuit. The interface circuit is coupled to the processor. The at least one interface circuit is used to perform a transceiver function and send instructions to At least one processor, at least one processor is used to run computer programs or instructions, which has the function of implementing the above-mentioned first aspect or any of the possible implementation methods of the first aspect. This function can be implemented by hardware or software. Implementation can also be achieved through a combination of hardware and software. The hardware or software includes one or more modules corresponding to the above functions. In addition, the interface circuit is used to communicate with other modules outside the chip.

Description of the drawings

Figure 1 is a schematic flow chart of a method for confirming an application's trusted identity provided by an embodiment of the present application;

Figure 2 is a schematic diagram of the middleware trusted base provided by the embodiment of the present application to establish an identity connection;

Figure 3 is a schematic diagram of the middleware trusted base provided by the embodiment of the present application using execution management to establish an identity connection;

Figure 4 is a schematic diagram of the middleware trusted base provided by the embodiment of the present application using a configuration file to establish an identity connection;

Figure 5 is a schematic flow chart of the middleware trusted base for transferring identity information provided by the embodiment of the present application;

Figure 6 is a diagram illustrating the overall architecture of the vehicle system access from start to finish according to the embodiment of the present application;

Figure 7 is a schematic structural diagram of a management unit provided by an embodiment of the present application;

Figure 8 is a schematic structural diagram of the equipment provided by the embodiment of the present application.

Detailed ways

The embodiment of the present application provides a method, management unit and device for confirming an application's trusted identity, which is used to build an identity connection with a target application (application, APP) based entirely on a middleware trusted base based on user-mode software, without affecting the kernel. Dependence, more flexible; in addition, based on the built identity connection, communication data can be integrated with identity data, saving the number of communications and improving device performance.

The terms "first", "second", etc. in the description and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the terms so used are interchangeable under appropriate circumstances, and are merely a way of distinguishing objects with the same properties in describing the embodiments of the present application. Furthermore, the terms "include" and "having" and any variations thereof, are intended to cover non-exclusive inclusions, such that a process, method, system, product or apparatus comprising a series of elements need not be limited to those elements, but may include not explicitly other elements specifically listed or inherent to such processes, methods, products or equipment.

In order to facilitate understanding of the solution of this application, before introducing the embodiments of this application, a brief description of the identity authentication mechanism commonly used in this field is given:

(1) Identity authentication mechanism based on SSL/TLS/HTTPS

The identity authentication mechanism based on SSL/TLS/HTTPS is currently widely used in Internet applications. Among them, SSL is the predecessor of TLS, and its full name is secure sockets layer. It is no longer updated; the full name of TLS is transport layer security, which is An encryption protocol for network-based transmission that can authenticate the identity of both parties based on a trusted third-party notarization; the full name of HTTPS is hyper text transfer protocol over secure socket layer, which is an HTTP channel targeting security. Based on HTTP, the security of the transmission process is ensured through transmission encryption and identity authentication.

Taking TLS as an example, a two-way certificate authentication process requires a four-way handshake process, and the certificate is an authentication mechanism based on asymmetric encryption and decryption. In a complete TLS two-way authentication handshake process, the server verifies the certificate from the client, and the client verifies the certificate from the server, thereby establishing a trust mechanism based on cryptography. After completing the two-way authentication, the server and the client conduct encrypted secure communication based on the negotiated key.

The process of certificate-based authentication mechanism requires the participation of a trusted third-party organization, such as a CA. And the CA needs to issue certificates for both ends of the communication. Using this solution for identity authentication requires the introduction of certificates and the maintenance of the certificate life cycle, which increases costs. In addition, when building a TLS chain, a handshake mechanism needs to be introduced based on certificate authentication, and the handshake mechanism needs to complete multiple certificate verification processes. The number of verifications needs to be at least two, and usually the working certificate is not the root certificate, so certificate chain verification is usually introduced during certificate verification. The number of certificate verifications may be far more than 2 times, and each certificate verification needs to go through the cloud. The public key infrastructure (PKI) queries the certificate validity and completes the asymmetric encryption and decryption algorithm process. Each step is a time-consuming operation. Therefore, TLS-based authentication communication methods are not suitable for use in some scenarios that are highly sensitive to delay in the car.

(2) Obtain UID/GID/PID for identity authentication based on Linux UDS SCM_CREDENTIALS

A socket whose Family attribute is configured as AF_UNIX is called a unix domain socket, or UDS for short. It is an inter-process communication method provided by the Linux kernel and is used to implement inter-process communication (IPC) on the same host. UDS can be used Efficient inter-process communication within the operating system. UDS provides a way to transfer identities between processes. When the sender process indicates that the message type sent is SCM_CREDENTIALS, the receiver process can obtain the UID/GID/PID of the initiator process through the Linux C library function. This further obtains the identity of the initiating process. It should be noted that the SCM_CREDENTIALS mechanism of UDS is implemented through the kernel socket, that is, the Linux kernel transfers the UID/GID/PID information of the initiating process between the two processes.

However, although UDS can complete the basic identity transfer function, this function can be used as long as it is a Linux system and is very versatile. But along with it, UDS still cannot solve some business-related problems, including:

a. Another way of UDS is to use the SO_PEERCRED mechanism, which can integrate identity and data transmission, but requires an additional system call to obtain the identity, which will cause a loss of communication performance and thus reduce communication efficiency;

b. Identity information can only be UID/GID/PID, and business code needs to be mapped to implement the logic required by the business;

c. Information transfer is implemented in the kernel, requiring additional system calls to transfer identity information, which reduces the certainty of IPC communication.

(3) Transfer identity information based on binder driver

Due to the problems introduced by the universal UDS transfer identity, the Linux mainline introduced an inter-process communication method based on the binder driver. This communication method is widely used in Android systems. binder provides a universal IPC framework, initially introduced by open binder and customized by Google for widespread use in IPC scenarios in Android. The binder was merged into the mainline in Linux 3.19. Android encapsulates binder into a java native interface (java native interface, JNI) for use by upper-layer applications. The JNI interface will use the driver layer interface, which is /dev/binder. The binder driver injects caller identity information into IPC data in the kernel. This solution solves problem a in the second way above. The binder-based communication method combines the data message and the identity information of the initiator. The receiving end can access the identity information of the peer through the get calling UID class interface.

However, the binder solution still cannot handle the problems b and c mentioned in the second method above, that is: the binder can still only transmit the logical concept information provided by the UID/GID/PID operating system. Android solves this problem by giving each process a unique UID. However, this type of solution is not a universal solution and is not suitable for vehicle operating systems; the identity information acquisition logic of binder is in the kernel, which increases the kernel processing time and is still not performance friendly enough. Since binder has been merged into the kernel mainline, maintainability has been alleviated, but it is more difficult to push similar functions into the kernel.

To sum up, some existing identity authentication mechanism solutions are mostly based on the kernel to obtain the UID/GID/PID information of the peer process, which usually introduces the following problems: 1) It cannot be integrated with business communication and requires additional communication to obtain it from the kernel. Information corresponding to the process; 2) It can only transfer the existing logical concepts of the operating system, such as UID/GID/PID, and cannot be closely integrated with the business. When using the identity, a table lookup mapping is still required; 3) The identity authentication process is Kernel implementation introduces multiple system calls, which reduces performance, and introduces kernel modifications, making maintenance difficult.

Based on this, the embodiment of the present application provides a method, management unit and device for confirming an application's trusted identity, which can solve the above three problems. Specifically, the embodiment of the present application is entirely based on the middleware trusted base of user-mode software. The identity connection with the target application has no dependence on the kernel and is more flexible; in addition, based on the built-in identity connection, communication data can be integrated with identity data, saving the number of communications and improving device performance.

The embodiments of the present application are described below with reference to the accompanying drawings. Persons of ordinary skill in the art know that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

Please refer to Figure 1 for details. Figure 1 is a schematic flowchart of a method for confirming an application's trusted identity provided by an embodiment of the present application. Specifically, it may include the following steps:

101. The middleware trust base establishes an identity connection with the target application. The middleware trust base is user-mode software built in advance. The target application at least includes a first application and a second application.

First, the embodiment of this application will build a middleware trust base in advance. The middleware trust base can also be called identity manager, which is a kind of user-mode software. The middleware trust base itself is trustworthy.

In this embodiment of the present application, a middleware trust base is constructed corresponding to an operating system. After the middleware trust base is constructed, the middleware trust base can be established and related to related applications (which can be called target applications, target processes). etc., for ease of explanation, applications are used as examples to illustrate the identity connection between). In this embodiment of the present application, the target application includes at least two different applications, which may be called a first application and a second application. Specifically, in some embodiments of the present application, the target application may refer to any one or more applications (for example, it may be all applications) belonging to the same operating system. In this case, the first application and the second application Applications refer to applications that belong to the same operating system.

Specifically, when the middleware trust base is started, it will establish a communication channel for marking identities with the processes belonging to all applications in the operating system. As shown in Figure 2, this communication channel can be called an identity channel. In this article In the application embodiment, there are multiple ways to establish identity connections, including but not limited to:

(1) The middleware trust base establishes an identity connection with the target application through execution management.

In this way of establishing an identity connection, the middleware trusted base can use execution management (execution management is a service process) to establish an identity connection with the target application. For example, execution management can notify the middleware trust base which APP processes have been started, and then the middleware trust base can actively initiate identity connections.

In order to facilitate understanding of the above process, the following uses the vehicle platform software business as an example to illustrate the establishment of identity connection with the help of execution management. The specific process can be as follows: The vehicle platform software business processes are all started by execution management. The role of execution management is similar to Android's zygote process. Execution management is called through the fork-exec system and ultimately starts the business process. During the process of launching the APP process, the execution management assists in establishing the identity channel. Please refer to Figure 3 for details. The creation process is as follows:

① The execution management calls the fork system call to create a child process. At this time, the execution management code is still running;

② Execute the management sub-process to open the identity connection channel of the APP process;

③The sub-process initiates IPC communication to the middleware trusted base, notifying the middleware trusted base that it is about to launch an APP process;

④The middleware trust base attempts to open the identity connection channel of the APP process.

(2) The middleware trust base uses the configuration file of the target application to establish an identity connection with the target application.

In this way of establishing an identity connection, the middleware trusted base can use the configuration file to establish an identity connection with the target application. For example, the middleware trust base can statically obtain the APP process information that needs to be started on the current platform, and then initiate an identity connection.

In order to facilitate understanding of the above process, the following uses the vehicle platform software business as an example to illustrate the establishment of identity connection through execution management. The specific process can be:

The vehicle platform software business process has its own configuration file. When the configuration file is packaged and integrated by the software, it is installed in the root file system of the vehicle platform. The file is in a read-only file system, and when it is started, it will be verified with the entire system to ensure its integrity. Both the middleware trust base and the APP process can obtain the identity connection information of the APP process based on this configuration file. Since the mandatory access control (MAC) policy of the operating system stipulates that the APP process can only access the identity connection channel corresponding to its identity, the identity connection created by the embodiment of this application is also safe and trustworthy. Please refer to Figure 4 for details. , its creation process is as follows:

① When starting, the middleware trust base traverses the configuration files of all APP processes under the same operating system, opens its identity connection channel for each APP process, and attempts to establish an identity connection with the APP;

② When the APP process communicates for the first time, it opens its own identity connection channel by reading the identity connection information in the configuration file, thereby establishing a trusted secure identity channel with the middleware trust base.

It should be noted that once the middleware trust base establishes identity connections with all application processes under the same operating system, the identity information provided by the kernel trust base can be transferred to the middleware trust base.

102. The middleware trusted base receives the first request sent by the first application through the first identity channel, where the first request is used to represent the first application's request to communicate with the second application.

After the middleware trust base establishes the identity connection with the target application, the entire operating system can transfer the identity information of each application through the middleware trust base. In this embodiment of the present application, when an application process (can be called the first application, that is, APP1, also can be called the initiating end process) wants to communicate with another application process (can be called the second application, that is, APP2, can also be called When communication occurs with a receiving process), the receiving process needs to be able to determine the identity of the initiating process. If the initiating process is an unidentified process, for the sake of communication security, the receiving process will refuse to communicate with it. Therefore, during communication initialization, the initiating process cannot communicate directly with the receiving process. If the initiating end attempts to access directly, the communication will be directly rejected by the receiving end. At this time, it is required that the identity of the initiating process can be safely transmitted to the receiving process. But it cannot be transmitted directly through the communication channel load between two application processes, because if this transmission method is used, an untrustworthy process or a malicious process can arbitrarily adjust the communication load to imitate other application processes. This will prevent the receiving process from making correct and reliable judgments. Therefore, during communication initialization, the first application needs to communicate with the middleware trusted base to attempt to establish a communication channel with the second application via the middleware trusted base.

Specifically, the middleware trusted base may receive the first request sent by the first application through the first identity channel established when establishing the identity connection. The first request may also be called a communication initialization request and is used to characterize the first application request. Communicate with the second application. It should be noted that the first identity channel is an identity channel corresponding to the first application.

103. The middleware trusted base obtains the second request according to the first request, and the second request includes the identity information of the first application.

After receiving the first request (ie, communication initialization request) sent by the first application, the middleware trusted base will further obtain a second request based on the first request. The second request includes the identity information of the first application.

It should be noted that in some implementations of the present application, the way in which the middleware trusted base obtains the second request based on the first request may be: the middleware trusted base injects the identity information of the first application into the first request, Thus, a second request containing the identity information of the first application is obtained.

104. The middleware trusted base sends the second request to the second application through the second identity channel.

Afterwards, the middleware trusted base will send the second request to the second application through the second identity channel established when establishing the identity connection. It should be noted that the second identity channel is an identity channel corresponding to the second application. In some implementations of the present application, the middleware trust base can determine which application the second application is based on the APP ID maintained by itself, as shown in Figure 5.

105. The second application determines whether to establish a first communication channel with the first application based on the identity information in the second request.

After receiving the second request sent by the middleware trusted base, the second application will obtain the identity information of the first application from the data message of the second request, and decide whether to establish a communication channel with the first application based on the identity information. , this communication channel can be called the first communication channel (ie, safe channel).

It should be noted here that since the middleware trust base itself is trustworthy, it follows that the identity information in the request forwarded via the middleware trust base is also trustworthy. Therefore, the second application can make a judgment based on the identity information of the first application. In addition, the first communication channel between the middleware trust base and the processes at both ends of the communication is jointly established by the system execution management and the middleware trust base during initialization. Since the execution management of the system belongs to the same security level as the middleware trust base described in this application, data requests sent through these two channels are also trustworthy.

It can be seen from the above steps that the application trusted identity confirmation method provided by the embodiment of the application is based on the constructed middleware trusted base to establish the identity connection with each application process, which is more flexible; and in the communication initialization stage, the process is The middleware trust base injects the identity information of the initiating process into the communication initialization request (that is, the communication data and the identity data are fused), so that the receiving process can identify whether the initiating process is a reliable application process, thereby eliminating the need for additional identities. The transmission process saves the number of communications and improves communication performance; in addition, the middleware trust base is completely user-mode software, which has less dependence on the kernel and is more universal.

It should be noted that in some implementations of this application, in order to prevent malicious processes from launching attacks on the identity connection during the communication process, for example, trying to create someone else's identity connection to launch a counterfeit attack, or maliciously tampering with the middleware during the communication process Identity information injected by the trusted base, etc. The access rights of the above-mentioned channels (such as the first identity channel, the second identity channel, the first communication channel, etc.) must be restricted. Specifically, the access rights of the first identity channel are subject to a first restriction, and the first restriction is at least Including any of the following: the inability to create or access the identity connection between the third application and the middleware trusted base, where the third application and the first application are different applications; or the inability to access the data passed on the second communication channel. Data, wherein the second communication channel is a communication channel different from the first communication channel. Similarly, the access permission of the second identity channel is subject to a second restriction, and the second restriction includes at least any of the following: the identity connection between the fourth application and the middleware trusted base cannot be created or accessed, wherein the fourth The application and the second application are different applications; or the data transmitted on the second communication channel cannot be accessed, wherein the second communication channel is a communication channel different from the first communication channel. The access rights of the first communication channel are subject to a third restriction, which includes at least one of the following: the inability to create or access the identity connection between the target application and the middleware trusted base; or the inability to access the transfer on the second communication channel. data, wherein the second communication channel is a communication channel different from the first communication channel.

In other words, each channel mentioned above cannot create or access identity connections between other processes and the middleware trusted base to ensure that the identity mechanism is safe and trustworthy; in addition, each channel cannot access communication data between other processes. Ensure data security within secure communication channels to avoid tampering and information leakage. In some implementations of this application, in order to achieve the above objectives, embodiments of this application can use the access control mechanism provided by the Linux kernel to protect all communication channels, including but not limited to:

a. Use the kernel's MAC mechanism, such as security-enhanced Linux (SELinux), to restrict the behavior of application processes. It is only allowed to access channels related to itself (such as pipes, UDS, shared memory, etc.), including identity connections with Identity Manager, secure communication channels established with other processes, etc.

b. Adopt discretionary access control (DAC), such as building an APP sandbox and running each APP with a different user to achieve isolation. This ensures that each process can only access channels related to itself.

In summary, the embodiments of this application take into account the shortcomings of existing methods, and the proposed method for confirming application trusted identity based on a middleware trust base can be integrated with the communication framework to achieve the integration of data communication and identity transfer; and , based on a pure user-mode middleware trust base, avoids being trapped in kernel operations too much and for too long, and improves communication performance and certainty; finally, the embodiment of this application fully conforms to the business ID system and avoids the direct use of UID and other operations. System logic concept, more flexible.

Since the application trusted identity determination method described in the embodiments of this application can be used in smart cities, smart driving and other fields to ensure data security, a typical application scenario implemented in products is introduced below.

In the field of digital security, access control can be an important means to avoid malicious intrusions. When an invasion occurs, it can also be used as a resilient means to control the intruder's access to higher-level resources. Therefore, access control for key resources that need to be used in software systems is a very important technology in the security field. Access control must be based on a trusted identity mechanism to be effectively implemented. In the Internet field, trusted identities are usually implemented based on certificate systems and cryptography. However, in scenarios such as vehicle-mounted software that require very high reliability and real-time performance, an identity mechanism based entirely on a certificate system or cryptography is not fully applicable. In view of the characteristics of vehicle-mounted software, the present invention implements a complete trusted identity mechanism based on user mode. The application system framework of the present invention is shown in Figure 6. The application trusted identity confirmation method provided by the embodiment of the present application can be implemented in the IAM module in Figure 6.

It should be noted that the technology involved in this application is not limited to autonomous driving platforms, but also includes all access control scenarios built on user-mode trusted bases, including but not limited to industrial control, railways, aviation and other types of applications that have a high level of digital security. The systems and solutions required by the specifications belong to a universal user-space secure identity transfer mechanism. It can be applied to almost any scenario and is highly customizable and scalable.

On the basis of the above embodiments, in order to better implement the above solutions in the embodiments of the present application, relevant units for implementing the above solutions are also provided below. Specifically referring to Figure 7, Figure 7 is a schematic structural diagram of a management unit provided by an embodiment of the present application. The management unit 700 may specifically include: a creation module 701, a first sending module 702, an acquisition module 703, and a second sending module 704, where , the establishment module 701 is used to establish an identity connection with the target application, which includes at least a first application and a second application; the first sending module 702 is used to receive the information sent by the first application through the first identity channel. The first request is used to represent that the first application requests communication with the second application, and the first identity channel corresponds to the first application; the acquisition module 703 is used to obtain the second request according to the first request. , the second request includes the identity information of the first application; the second sending module 704 is configured to send the second request to the second application through the second identity channel, so that the second application is based on the second The identity information in the request determines whether to establish a first communication channel with the first application, and the second identity channel corresponds to the second application.

In one possible design, the establishment module 701 is specifically configured to establish an identity connection with the target application through execution management.

In one possible design, the establishment module 701 is specifically configured to: establish an identity connection with the target application using the configuration file of the target application.

In one possible design, the acquisition module 703 is specifically configured to inject the identity information of the first application into the first request to obtain the second request.

In a possible design, the access rights of the first identity channel are subject to a first restriction, which first restriction includes at least any of the following: an identity connection between a third application and the middleware trusted base cannot be created or accessed , the third application and the first application are different applications; or, the data transmitted on the second communication channel cannot be accessed, and the second communication channel is a communication channel different from the first communication channel.

In a possible design, the access rights of the second identity channel are subject to a second restriction, and the second restriction includes at least any of the following: the identity connection between the fourth application and the middleware trusted base cannot be created or accessed. , the fourth application and the second application are different applications; or, the data transmitted on the second communication channel cannot be accessed, and the second communication channel is a communication channel different from the first communication channel.

In a possible design, the access permission of the first communication channel is subject to a third restriction, and the third restriction includes at least any of the following: the identity connection between the target application and the middleware trusted base cannot be created or accessed. ; Or, the data transmitted on the second communication channel cannot be accessed, and the second communication channel is a communication channel different from the first communication channel.

In a possible design, the first application and the second application belong to application programs in the same operating system.

It should be noted that the information interaction, execution process, etc. between the modules/units in the management unit 700 are based on the same concept as the method embodiment corresponding to Figure 1 in this application. For specific content, please refer to the method shown above in this application. The descriptions in the embodiments will not be repeated here.

Next, a device provided by an embodiment of the present application is introduced. Please refer to Figure 8. Figure 8 is a schematic structural diagram of a device provided by an embodiment of the present application. The management described in the corresponding embodiment of Figure 7 can be deployed on the device 800. Unit 700 is used to implement the functions of the management unit 700 in the corresponding embodiment of Figure 7. Specifically, the device 800 is implemented by one or more servers. The device 800 may vary greatly due to different configurations or performance, and may include one or more servers. One or more central processing units (CPU) 822 and memory 832, and one or more storage media 830 (such as one or more mass storage devices) storing application programs 842 or data 844. Among them, the memory 832 and the storage medium 830 may be short-term storage or persistent storage. The program stored in the storage medium 830 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the device 800 . Furthermore, the central processor 822 may be configured to communicate with the storage medium 830 and execute a series of instruction operations in the storage medium 830 on the device 800 .

Device 800 may also include one or more power supplies 826, one or more wired or wireless network interfaces 850, one or more input and output interfaces 858, and/or, one or more operating systems 841, such as Windows Server™, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM and many more.

In this embodiment of the present application, the central processor 822 is used to execute the trusted identity confirmation method in the corresponding embodiment of Figure 1. For specific content, please refer to the description in the method embodiments shown above in this application, and will not be described again here. .

It should be noted that the specific manner in which the central processor 822 executes each of the above steps is based on the same concept as the method embodiment corresponding to Figure 1 in this application, and the technical effects it brings are also the same as the above-mentioned embodiments in this application. The specific content can be Please refer to the descriptions in the method embodiments shown above in this application, which will not be described again here.

An embodiment of the present application also provides a computer-readable storage medium, which stores a program for signal processing. When it is run on a computer, it causes the computer to execute the embodiment shown in Figure 1 Describes the steps performed by the middleware trustbase.

The device provided by the embodiment of the present application may specifically be a chip. The chip may include: a processing unit and a communication unit. The processing unit may be, for example, a processor. The communication unit may be, for example, an input/output interface, a pin, or a circuit. The processing unit can execute computer execution instructions stored in the storage unit, so that the chip in the device performs the steps performed by the middleware trusted base described in the embodiment shown in FIG. 1 .

Optionally, the storage unit is a storage unit within the chip, such as a register, cache, etc. The storage unit may also be a storage unit located outside the chip in the wireless access device, such as Read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (random access memory, RAM), etc.

In addition, it should be noted that the device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physically separate. The physical unit can be located in one place, or it can be distributed across multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between modules indicates that there are communication connections between them, which can be specifically implemented as one or more communication buses or signal lines.

Through the above description of the embodiments, those skilled in the art can clearly understand that the present application can be implemented by software plus necessary general hardware. Of course, it can also be implemented by dedicated hardware including dedicated integrated circuits, dedicated CPUs, dedicated memories, Special components, etc. to achieve. In general, all functions performed by computer programs can be easily implemented with corresponding hardware. Moreover, the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits or special-purpose circuits. circuit etc. However, for this application, software program implementation is a better implementation in most cases. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product in essence or that contributes to the existing technology. The computer software product is stored in a readable storage medium, such as a computer floppy disk. , U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk, etc., including several instructions to cause a computer device (which can be a personal computer or network device, etc.) to execute the method described in each embodiment of the application.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product.

The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another, e.g., the computer instructions may be transmitted over a wired connection from a website, computer, or data center. (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) to another website, computer, device or data center. The computer-readable storage medium may be any available medium that a computer can store, or a data storage device such as a device integrated with one or more available media, a data center, or the like. The available media may be magnetic media (eg, floppy disk, hard disk, tape), optical media (eg, DVD), or semiconductor media (eg, solid state disk (SSD)), etc.

Claims

A method for confirming an application's trusted identity, which is characterized by including:

The middleware trust base establishes an identity connection with the target application. The middleware trust base is user-mode software built in advance. The target application at least includes a first application and a second application;

The middleware trusted base receives the first request sent by the first application through the first identity channel. The first request is used to represent the first application's request to communicate with the second application. The first identity The channel corresponds to the first application;

The middleware trusted base obtains a second request according to the first request, and the second request includes the identity information of the first application;

The middleware trusted base sends the second request to the second application through a second identity channel, so that the second application decides whether to communicate with the third application based on the identity information in the second request. An application establishes a first communication channel, and the second identity channel corresponds to the second application.
The method according to claim 1, characterized in that establishing an identity connection between the middleware trusted base and the target application includes:

The middleware trusted base establishes an identity connection with the target application by means of execution management.
The method according to claim 1, characterized in that establishing an identity connection between the middleware trusted base and the target application includes:

The middleware trusted base establishes an identity connection with the target application by means of the configuration file of the target application.
The method according to any one of claims 1-3, wherein the middleware trusted base obtains the second request according to the first request including:

The middleware trusted base injects the identity information of the first application into the first request to obtain the second request.
The method according to any one of claims 1-4, characterized in that the access authority of the first identity channel is subject to a first restriction, and the first restriction at least includes any one of the following:

An identity connection between a third application and the middleware trusted base cannot be created or accessed, and the third application and the first application are different applications;

or,

Data transferred on the second communication channel, which is a different communication channel than the first communication channel, cannot be accessed.
The method according to any one of claims 1-5, characterized in that the access rights of the second identity channel are subject to a second restriction, and the second restriction at least includes any one of the following:

An identity connection between a fourth application and the middleware trusted base cannot be created or accessed, and the fourth application and the second application are different applications;

or,

Data transferred on the second communication channel, which is a different communication channel than the first communication channel, cannot be accessed.
The method according to any one of claims 1-6, characterized in that the access authority of the first communication channel is subject to a third restriction, and the third restriction at least includes any one of the following:

An identity connection between the target application and the middleware trust base cannot be created or accessed;

or,

Data transferred on the second communication channel, which is a different communication channel than the first communication channel, cannot be accessed.
The method according to any one of claims 1-7, characterized in that,

The first application and the second application belong to application programs in the same operating system.
A management unit is characterized by including:

An establishment module, configured to establish an identity connection with a target application, where the target application at least includes a first application and a second application;

A first sending module, configured to receive a first request sent by the first application through a first identity channel. The first request is used to represent that the first application requests communication with the second application. The first identity The channel corresponds to the first application;

An acquisition module, configured to obtain a second request according to the first request, where the second request includes the identity information of the first application;

A second sending module, configured to send the second request to the second application through a second identity channel, so that the second application decides whether to communicate with the third application based on the identity information in the second request. An application establishes a first communication channel, and the second identity channel corresponds to the second application.
The management unit according to claim 9, characterized in that the establishment module is specifically used for:

Establish an identity connection with the target application using execution management.
The management unit according to claim 9, characterized in that the establishment module is specifically used for:

Establish an identity connection with the target application using the configuration file of the target application.
The management unit according to any one of claims 9-11, characterized in that the acquisition module is specifically used for:

Inject the identity information of the first application into the first request to obtain the second request.
The management unit according to any one of claims 9-12, characterized in that the access rights of the first identity channel are subject to a first restriction, and the first restriction at least includes any one of the following:

The identity connection between the third application and the management unit cannot be created or accessed, and the third application and the first application are different applications;

or,

Data transferred on the second communication channel, which is a different communication channel than the first communication channel, cannot be accessed.
The management unit according to any one of claims 9-13, characterized in that the access rights of the second identity channel are subject to a second restriction, and the second restriction at least includes any one of the following:

The identity connection between the fourth application and the management unit cannot be created or accessed, and the fourth application and the second application are different applications;

or,

Data transferred on the second communication channel, which is a different communication channel than the first communication channel, cannot be accessed.
The management unit according to any one of claims 9-14, characterized in that the access authority of the first communication channel is subject to a third restriction, and the third restriction at least includes any one of the following:

An identity connection between the target application and the management unit cannot be created or accessed;

or,

Data transferred on the second communication channel, which is a different communication channel than the first communication channel, cannot be accessed.
The management unit according to any one of claims 9 to 15, characterized in that the first application and the second application belong to application programs in the same operating system.
A device including a processor and a memory, the processor being coupled to the memory, characterized in that:

The memory is used to store programs;

The processor is configured to execute a program in the memory, so that the device executes the method according to any one of claims 1-8.
A computer-readable storage medium includes a program that, when run on a computer, causes the computer to perform the method according to any one of claims 1-8.
A computer program product containing instructions that, when run on a computer, cause the computer to perform the method according to any one of claims 1-8.
A chip. The chip includes a processor and a data interface. The processor reads instructions stored in a memory through the data interface and executes the method according to any one of claims 1-8.