Resource access control method and device and electronic equipment

Abstract

The invention provides a resource access control method and device and electronic equipment, and relates to the technical field of information security. The method comprises the following steps: receiving a first identity token and a resource access request sent by a consumption process; according to a domain identifier in the first identity token, sending the first identity token and first verification indication information to the second control domain; wherein the first verification indication information is used for indicating the second control domain to verify the first identity token; receiving a first verification result sent by the second control domain; and under the condition that the first verification result indicates that verification succeeds, according to the application identifier in the first identity token, determining whether the consumption process has a resource access permission to the service process. According to the technical scheme provided by the invention, the problem of cross-domain application process identity authentication can be solved.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a resource access control method, device and electronic device. Background Art

[0002] With the development of vehicle electronic and electrical architecture, different control domains have been divided, such as power domain, chassis domain, intelligent cockpit domain, body control domain, central computing domain, etc. This can achieve better functional division and enhance the scalability and performance of the vehicle system.

[0003] Different control domains can communicate with each other, and an application process in one control domain may sometimes have resource access requirements for an application process in another control domain. Considering information security, it is necessary to authenticate the identity information of the application process requesting resource access.

[0004] The identity information of the application process, such as the user identification (UID), process identification (PID), SeLinux security context, etc., is mainly formed based on the kernel capabilities of the operating system, and is independently maintained and managed within an operating system. It can be used as a credential for application authentication within the operating system. However, different control domains span multiple operating systems, and it is difficult for one control domain to determine whether the identity information of the application process in other control domains is credible. Therefore, how to provide a better cross-domain identity authentication solution for application processes has become a technical problem that needs to be urgently solved by technical personnel in this field. Summary of the invention

[0005] Based on the defects and deficiencies of the above-mentioned prior art, the present application proposes a resource access control method, device and electronic device, which can solve the problem of cross-domain application process identity authentication when UID, PID, etc. are used as identity credentials.

[0006] According to a first aspect of an embodiment of the present application, a resource access control method is provided, which is applied to a first control domain in a vehicle-mounted system, and the method includes:

[0007] Receive a first identity token and a resource access request sent by a consumer process; wherein the consumer process belongs to a second control domain in the vehicle-mounted system, the first identity token is issued to the consumer process by the second control domain, and the first identity token includes: an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier; the resource access request is used to request access to resources of a service process in the first control domain;

[0008] According to the domain identifier in the first identity token, sending the first identity token and first verification indication information to the second control domain; wherein the first verification indication information is used to instruct the second control domain to verify the first identity token;

[0009] receiving a first verification result sent by the second control domain;

[0010] When the first verification result indicates that the verification is successful, it is determined whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token.

[0011] According to a second aspect of an embodiment of the present application, a resource access control method is provided, which is applied to a second control domain in a vehicle-mounted system, and the method includes:

[0012] Sending a first identity token and a resource access request to the first control domain in the vehicle system; wherein the first identity token is issued by the second control domain to the consumer process, and the resource access request is used to indicate that the consumer process requests to access the resources of the service process in the first control domain; the first identity token includes: an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier;

[0013] receiving the first identity token and first verification indication information sent by the first control domain; wherein the first verification indication information is used to instruct the second control domain to verify the first identity token;

[0014] Verify the first identity token according to the first verification indication information to obtain a first verification result;

[0015] Send the first verification result to the first control domain.

[0016] According to a third aspect of an embodiment of the present application, a resource access control device is provided, which is applied to a first control domain in a vehicle-mounted system, and the device includes:

[0017] A first receiving module is used to receive a first identity token and a resource access request sent by a consumer process; wherein the consumer process belongs to a second control domain in the vehicle-mounted system, the first identity token is issued to the consumer process by the second control domain, and the first identity token includes: an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier; the resource access request is used to request access to resources of a service process in the first control domain;

[0018] A sending module, used for sending the first identity token and first verification indication information to the second control domain according to the domain identifier in the first identity token; wherein the first verification indication information is used to instruct the second control domain to verify the first identity token, and the verification includes verifying the signature information in the first identity token;

[0019] A second receiving module, used to receive a first verification result sent by the second control domain;

[0020] The permission processing module is used to determine whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token when the first verification result indicates that the verification is successful.

[0021] According to a fourth aspect of an embodiment of the present application, a resource access control device is provided, which is applied to a second control domain in a vehicle-mounted system; the device includes:

[0022] A first sending module, used for sending a first identity token and a resource access request to a first control domain in the vehicle system; wherein the first identity token is issued by the second control domain to a consumer process, and the resource access request is used to indicate that the consumer process requests to access resources of a service process in the first control domain; the first identity token includes: an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier;

[0023] A first receiving module, configured to receive the first identity token and first verification indication information sent by the first control domain; wherein the first verification indication information is used to instruct the second control domain to verify the first identity token;

[0024] A verification module, configured to verify the signature information in the first identity token according to the first verification indication information;

[0025] The second sending module is used to send the first verification result to the first control domain.

[0026] According to a fifth aspect of the embodiments of the present application, there is provided an electronic device, including: a memory and a processor;

[0027] The memory is connected to the processor and is used to store programs;

[0028] The processor is used to implement the resource access control method as described in the first aspect or the second aspect by running the program in the memory.

[0029] According to a sixth aspect of an embodiment of the present application, a storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the resource access control method as described in the first aspect or the second aspect is implemented.

[0030] According to a seventh aspect of an embodiment of the present application, a computer program product or a computer program is provided, wherein the computer program product includes a computer program, and when a processor executes the computer program, the steps in the resource access control method as described in the first aspect or the second aspect are implemented.

[0031] In the technical solution provided in the present application, when a consumer process belonging to the second control domain has a resource access requirement for a service process belonging to the first control domain, it can first request the second control domain to issue an identity token, and use the identity token as an identity credential for resource access and send it to the service process. The identity token includes an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier. After the service process receives the identity token, it can submit the verification task of the identity token to the second control domain corresponding to the domain identifier based on the domain identifier in the identity token. After receiving the verification task, the second control domain verifies the identity token. Since the signature information is generated by the second control domain, the second control domain can verify the signature information. After completing the verification, the verification result is returned to the first control domain. The first control domain can determine whether the consumer process is trustworthy based on the verification result, thereby realizing cross-domain application process identity authentication. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0033] Figure 1 A block diagram of a vehicle-mounted system provided in an embodiment of the present application;

[0034] Figure 2 A schematic diagram of a resource access control method provided in an embodiment of the present application;

[0035] Figure 3 A schematic diagram of the process of processing an identity token by a first control domain provided in an embodiment of the present application;

[0036] Figure 4 A flowchart of another resource access control method provided in an embodiment of the present application;

[0037] Figure 5 A schematic diagram of the life cycle of an identity token provided in an embodiment of the present application;

[0038] Figure 6 A schematic diagram of another life cycle of an identity token provided in an embodiment of the present application;

[0039] Figure 7 A block diagram of a resource access control device provided in an embodiment of the present application;

[0040] Figure 8 A block diagram of another resource access control device provided in an embodiment of the present application;

[0041] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0043] Exemplary In-Vehicle Systems

[0044] The vehicle-mounted system may include multiple control domains, such as a power domain, a chassis domain, a smart cockpit domain, a body control domain, a central computing domain, etc. Figure 1 The first control domain and the second control domain in the vehicle system can be any two of the multiple control domains in the vehicle system. The operating system in the first control domain and the operating system in the second control domain can be any two of Unix, Android, QNX, AutoSar CPOS (Automotive Open System Architecture Classic Platform Operating System, referred to as M core), etc.

[0045] Taking the consumption process in the second control domain requesting to access the resources of the service process in the first control domain as an example, the resource access control method provided in the embodiment of the present application is generally described.

[0046] 1. Before requesting resource access from the service process in the first control domain, the consumer process in the second control domain first applies for an identity token from this domain.

[0047] like Figure 1 As shown, an identity authentication service can be set in each control domain to issue an identity token to the consumer process. Therefore, the consumer process can apply for an identity token from the identity authentication service in the second control domain, such as Figure 1Specifically, the consumer process can apply for an identity token from the identity authentication service of the domain through a communication channel such as a domain socket.

[0048] The identity token mentioned here may include, but is not limited to: an application identifier corresponding to the consumption process, a domain identifier of the second control domain, and signature information generated based on the application identifier.

[0049] Among them, the application identifier is globally unique, that is, in the entire vehicle system, the application identifiers of different applications are different. In the embodiment of the present application, the corresponding application identifier can be found according to the identity information of the application process (such as user identifier, process identifier, process security context). For example, an identity mapping table is set in advance according to the identity information of the application process and the application identifier corresponding to the application. In actual use, the corresponding application identifier can be found in the identity mapping table by looking up the table based on the identity information of the application process.

[0050] It should be noted that when establishing an identity mapping table based on PID, since PID is generated by the operating system and is variable, that is, the PID assigned by the operating system to the same application process each time may be different, therefore, PID can be converted into fixed application information. For example, in Linux system, PID can be converted into a fixed process path; in Android system, PID can be converted into App package name.

[0051] It should also be noted that the user identification and process security context information can be pre-configured, and the user identification of different applications can be configured to be different, and the security context information of different application processes can also be configured to be different, so as to form a fixed correspondence with the application identification. Among them, the process security context refers to some information related to the application process, such as the type and role of the application process.

[0052] 2. The second control domain issues an identity token to the consumer process based on the token application request of the consumer process.

[0053] like Figure 1 As shown in (3), the identity authentication service in the second control domain can issue an identity token to the consumer process.

[0054] Specifically, the identity authentication service can obtain the identity information of the consumer process through the kernel capability of the operating system and map it into an application identifier, and add the application identifier, domain identifier, and signature information to the identity token.

[0055] Optionally, considering security, before issuing the identity token, the identity authentication service can authenticate the consumer process based on the identity information of the consumer process, such as user ID, process ID, process security context (such as SeLinux security context), etc. Figure 1 As shown in (2); if the consumption process passes the identity authentication, it means that the consumption process is legal, and an identity token is issued to it; if the consumption process fails to pass the identity authentication, it means that there are security risks in the consumption process, and the identity token is refused to be issued to it, and an alarm message can also be output.

[0056] 3. After obtaining the identity token, the consumer process in the second control domain sends the identity token and resource access request to the service process in the first control domain, such as Figure 1 As shown in (4) in .

[0057] 4. After receiving the identity token and resource access request sent by the second control domain, the first control domain determines that the identity token belongs to the second control domain based on the domain identifier in the identity token, and then sends the identity token and verification indication information to the second control domain.

[0058] like Figure 1 As shown, the service process in the first control domain sends the received identity token to the identity authentication service of this domain, such as Figure 1 As shown in (5) in the figure. The identity authentication service determines that the identity token belongs to the second control domain according to the domain identifier in the identity token, and then sends the identity token and the verification indication information to the second control domain, such as Figure 1 As shown in (6) in .

[0059] The verification indication information is used to instruct the second control domain to verify the identity token. The verification mentioned here may refer to verifying the signature information in the identity token.

[0060] Since the signature information is generated based on the identity information of the consumption process, and the identity information is difficult to verify across domains, the embodiment of the present application verifies the identity token by the control domain that issues the identity token.

[0061] Optionally, the identity authentication service in the first control domain can obtain the application identifier (APPID) in the identity token to determine whether the application identifier belongs to the second control domain. If not, the identity token is considered to be illegally issued and the verification fails directly; if it does, the identity token and the verification indication information can be sent to the second control domain.

[0062] 5. After receiving the identity token and verification instruction information sent by the first control domain, the second control domain verifies the first identity token according to the first verification instruction information, and sends the first verification result to the service process in the first control domain.

[0063] The first identity token may be verified by the identity authentication service in the second control domain, and the first verification result may be sent to the service process in the first control domain, such as Figure 1 As shown in (7) and (8) in .

[0064] 6. After receiving the verification result sent by the second control domain, the service process in the first control domain determines whether the identity token verification is successful based on the verification result.

[0065] If the verification of the identity token is successful, the consumer process is determined to have resource access rights based on the application identifier in the identity token. If the verification of the identity token is determined to have failed, the consumer is prohibited from accessing the resource.

[0066] The policy enforcement point (PEP) in the service process can send the application identifier in the first identity token to the policy decision point (PDP), such as Figure 1 As shown in (9) in .

[0067] A policy decision point (PDP) can determine whether the consumer process has resource access rights based on an access control list (ACL) / access control policy (ACP) and an application identifier in the first identity token.

[0068] If it is determined that the consumer process has resource access rights, the policy execution point authorizes the consumer process to access the resources, such as Figure 1 As shown in (10) in . If it is determined that the consuming process does not have resource access rights, the policy enforcement point prohibits the consuming process from accessing the resource.

[0069] From the foregoing, it can be seen that the embodiment of the present application can overcome the problem that it is difficult for one control domain to determine whether the identity information of the application process in other control domains is credible by verifying the identity token issued by the domain itself, thereby improving the security of resource access between different control domains.

[0070] It should be noted that the second control domain and the first control domain can also be the same control domain, that is, through the technical solution provided in the embodiment of the present application, the application process authentication of a single domain can also be realized. Therefore, the technical solution of the application process authentication of a single domain implemented by the technical means provided in the embodiment of the present application is also within the protection scope of the embodiment of the present application.

[0071] The resource access control method provided in the embodiment of the present application is described below from the perspectives of the first control domain and the second control domain respectively.

[0072] Exemplary Methods

[0073] The embodiment of the present application provides a resource access control method, which is applied to a first control domain in a vehicle-mounted system, and the first control domain can be any one of a plurality of control domains included in the vehicle-mounted system. The operating system in the first control domain can be one of Unix, Android, QNX, AutoSar CPOS (Automotive Open System Architecture Classic Platform Operating System, referred to as M core), etc.

[0074] The resource access control method is described in detail below through some embodiments. The following embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0075] like Figure 2 As shown, the method may include steps 201 to 204, which are specifically described as follows:

[0076] Step 201: Receive a first identity token and a resource access request sent by a consumer process.

[0077] The consumer process mentioned here refers to a program that has access requirements to the resources of other programs, and the program being accessed is called a service process.

[0078] The resource access requirements described herein may include, but are not limited to, at least one of the following: requirements for performing operations such as reading, writing, modifying, or deleting resources.

[0079] In an embodiment of the present application, the consumption process belongs to the second control domain of the vehicle system, and the service process belongs to the first control domain of the vehicle system. The consumption process and the service process belong to different control domains. In other words, the consumption process has resource access requirements for service processes in different control domains.

[0080] The first identity token mentioned here is the identity certificate provided to the service process when the consumer process requests resource access. The first identity token may include but is not limited to the following information: the application identifier corresponding to the consumer process, the signature information generated based on the application identifier, and the domain identifier of the second control domain.

[0081] Among them, the application identifier is different from the identity information of the consumer process. In the entire vehicle system, the application identifier of each application is globally unique. According to the application identifier and the access control list / access control policy, it can be determined whether the consumer process has resource access rights.

[0082] The signature information may be generated based on the information included in the identity token, and the identity token includes at least the application identifier, that is, the identity token may be generated based on at least the application identifier, and in addition, the identity token may also include the identity information of the application process, the token issuance time, the token expiration time, etc. The signature information may be calculated by a message authentication code (MAC) algorithm or other algorithms.

[0083] In order to facilitate identification of which control domain the identity token belongs to, a domain identifier for indicating the control domain may be added to the identity token.

[0084] Step 202: According to the domain identifier in the first identity token, send the first identity token and first verification indication information to the second control domain.

[0085] The first verification indication information is used to instruct the second control domain to verify the first identity token. The verification mentioned here may include verifying the signature information in the first identity token.

[0086] In an embodiment of the present application, when a control domain receives an identity token issued by another control domain, it can return the identity token to the control domain that issued the identity token (hereinafter referred to as the target control domain, corresponding to the second control domain) based on the domain identifier in the identity token, and instruct the target control domain to verify the identity token.

[0087] After completing verification of the identity token, the target control domain sends the verification result to the control domain where the resource access request object is located (corresponding to the first control domain).

[0088] Step 203: Receive a first verification result sent by the second control domain.

[0089] Step 204: When the first verification result indicates that the verification is successful, determine whether the consumer process has access rights to the service process based on the application identifier in the first identity token.

[0090] After receiving the first verification result, the first control domain determines whether the first identity token is legal according to the first verification result.

[0091] When the first verification result indicates that the verification is successful, it means that the first identity token is legal, and in the vehicle system, the domain controllers on the vehicle are basically directly connected by the switch inside the vehicle, and are usually only one hop away, and the relevant permissions of both the switch and the domain controller system can be controlled, so it can be considered that the vehicle system is an internal network composed of heterogeneous systems. When the permissions of these heterogeneous systems are properly controlled, it is difficult to implement eavesdropping and man-in-the-middle attacks. Therefore, the identity token is difficult to be tampered with during the process of being sent from the second control domain to the first control domain. Therefore, when the identity token is determined to be credible based on the signature information in the identity token, the application identifier included in the identity token is also credible, so that it can be determined whether the consumer process has access rights to the service process based on the application identifier in the first identity token.

[0092] If the consumer process has access rights to the service process, the consumer process is allowed to access the resource; if the consumer process does not have access rights to the service process, the consumer process is prohibited from accessing the resource.

[0093] When the first verification result indicates that the verification has failed, it indicates that the first identity token is illegal and also indicates that the application identifier in the consumption process is untrustworthy, and the consumption process is prohibited from accessing the resource.

[0094] In summary, considering information security, if the consumer process wants to access the resources of the service process, it is necessary to verify the identity information of the consumer process. However, when the resource access request crosses domains, it is difficult for a control domain to determine whether the identity information of the application process in other control domains is credible. Therefore, the technical solution provided in the embodiment of the present application can generate signature information based on the application identifier corresponding to the consumer process, and save the signature information in the identity token, and add the domain identifier of the target control domain in the first identity token. In this way, the control domain where the resource is requested can return the first identity token to the target control domain according to the domain identifier in the first identity token, and the target control domain verifies the first identity token, especially the signature information in the first identity token, to determine whether the first identity token of the consumer process is credible. Then the verification result is returned to the control domain where the resource is requested. In this way, the problem that it is difficult for a control domain to determine whether the identity information of the application process in other control domains is credible can be overcome, and the security of resource access between different control domains is improved.

[0095] In some optional embodiments, before step 202: sending the first identity token and the first verification indication information to the second control domain, the method may further include steps A1 to A3, as described below:

[0096] Step A1: Determine whether the application identifier in the first identity token belongs to the second control domain.

[0097] Step A2: When the application identifier belongs to the second control domain, the control executes the step of sending the first identity token and the first verification indication information to the second control domain.

[0098] Step A3: When the application identifier does not belong to the first control domain, it is determined that the first identity token is an illegally issued token.

[0099] like Figure 3 As shown, after the first control domain receives the first identity token, it can obtain the application identifier and domain identifier in the first identity token. Then determine whether the domain identifier is the identifier of this domain. If yes, it means that the first identity token is issued by this domain, and the first identity token is verified by this domain. If no, it means that the first identity token is not issued by this domain, and then determine whether the target control domain corresponding to the domain identifier has the application identifier. If it does, the first identity token is sent to the target control domain for verification. If it does not, it means that the first identity token may be illegally issued and there is a security risk, then the verification is directly determined to have failed. In this way, it is possible to check in advance whether the first identity token is illegally issued, so that the first identity token can be processed in time.

[0100] In some optional embodiments, in order to improve the verification efficiency, a cache strategy can be adopted, that is, the verified valid identity token is not repeatedly verified, and the first control domain can cache the verification result of the first identity token (i.e., the first verification result). When the first control domain receives the first identity token sent by the second control domain again, the verification result can be obtained from the cache. If the verification result indicates that the verification is successful, step 204 is executed; if the verification result indicates that the verification fails, the consumer process is directly prohibited from accessing the resources of the service process.

[0101] Optionally, in the embodiment of the present application, the identity token may be temporary and have a validity period, but not permanent, so as to prevent long-term identity forgery caused by identity credential leakage to improve security. Different validity periods may be set for application processes of different security levels. For example, the higher the security level of the application process, the shorter the validity period; conversely, the lower the security level of the application process, the longer the validity period.

[0102] In order to ensure the timely use of the identity token by the application process, when the remaining validity period of the identity token reaches the time threshold, the application process can reapply for the token and update the identity token. In this way, there may be two valid identity tokens at the same time, that is, the new and old tokens. Assume that the two identity tokens are the first identity token and the second identity token, where the first identity token is the old identity token, that is, the token that is about to expire; the second identity token is the new identity token.

[0103] In this case, the first control domain can determine whether the consumer process can access the resource based on the verification result of the cached old identity token; at the same time, the new identity token is verified asynchronously, and the second control domain sends the verification result of the new identity token to the first control domain for caching, which is used for the next resource access. The specific implementation is as follows:

[0104] In step 204: after determining whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token, the method may further include steps B1 to B4, as described below:

[0105] Step B1: receiving a first identity token, a second identity token and a new resource access request sent by a consumption process.

[0106] Step B2: When the first verification result is saved and the first verification result indicates that the verification is successful, determine whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token.

[0107] Step B3: Send the second identity token and the second verification indication information to the second control domain according to the domain identifier in the second identity token.

[0108] The second verification indication information is used to instruct to verify the second identity token.

[0109] Step B4: receiving the second verification result sent by the second control domain, and saving the second verification result.

[0110] The embodiment of the present application also provides another resource access control method, which is applied to a second control domain in a vehicle-mounted system, and the second control domain can be any one of a plurality of control domains included in the vehicle-mounted system. The operating system in the second control domain can be one of Unix, Android, QNX, AutoSar CP OS, etc. The operating system of the second control domain is different from that of the first control domain.

[0111] The resource access control method is described in detail below through some embodiments. The following embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0112] like Figure 4 As shown, the method may include steps 401 to 404, which are specifically described as follows:

[0113] Step 401: Send a first identity token and a resource access request to a first control domain in the vehicle system.

[0114] The first identity token is issued by the second control domain to the consumer process, and the first identity token may include: the application identifier corresponding to the consumer process, the domain identifier of the second control domain, and the signature information generated based on the application identifier corresponding to the consumer process. The resource access request is used to indicate that the consumer process requests to access the resources of the service process in the first control domain.

[0115] For detailed explanations of the consumption process, the service process, the first identity token, the resource access request and the first control domain, please refer to the aforementioned embodiments, which will not be repeated here.

[0116] Step 402: Receive a first identity token and first verification indication information sent by a first control domain.

[0117] The first verification indication information is used to instruct the second control domain to verify the first identity token. The verification mentioned here may include verifying the signature information in the first identity token.

[0118] Step 403: According to the first verification indication information, the signature information in the first identity token is verified to obtain a first verification result.

[0119] For example, the signature information is generated based on the information included in the identity token, such as the application identifier, domain identifier, token issuance time, token expiration time and other information in the identity token, calculated by the key and message authentication code algorithm, then the second control domain can use the same key and message authentication code algorithm for the same field information in the first identity token to obtain new signature information, and then compare the new signature information with the signature information in the first identity token. If the two are the same, it means that the first identity token is legal, and the verification is successful; if the two are different, it means that the first identity token is illegal, and the verification fails.

[0120] It is understandable that other methods may be used for verification, which may be selected based on actual needs.

[0121] Step 404: Send the first verification result to the first control domain.

[0122] After receiving the first verification result, the first control domain determines whether the first identity token is legal according to the first verification result.

[0123] If the first verification result indicates that the verification is successful, it means that the first identity token is legal, and it also means that the application identifier in the first identity token and the consumer process are credible. Then, according to the application identifier in the first identity token, it can be determined whether the consumer process has access rights to the corresponding resources. If it does, the consumer process is allowed to access the resources; if not, the consumer process is prohibited from accessing the resources.

[0124] If the first verification result indicates that the verification fails, it means that the first identity token is illegal and also means that the consumer process is not trustworthy, and the consumer process is prohibited from accessing the resource.

[0125] The technical solution provided by the embodiment of the present application is that the target control domain (corresponding to the second control domain) that issues the token verifies the first identity token, thereby overcoming the problem that it is difficult for one control domain to determine whether the identity information of the application process in other control domains is credible, and improving the security of resource access between different control domains.

[0126] Optionally, in order to improve security, the second control domain may encrypt the first verification result to improve the security of the first verification result.

[0127] In some optional embodiments, before step 401: sending the first identity token and the resource access request to the first control domain in the vehicle system, the method may further include steps C1 to C3, as described below:

[0128] Step C1: Receive a token application request sent by the consumer process.

[0129] Step C2: Based on the token application request, the consumer process is authenticated.

[0130] Step C3: When the consumption process passes the identity authentication, a first identity token is generated.

[0131] Considering security, before issuing the first identity token to the consumer process, the second control domain can authenticate the consumer process based on the identity information of the consumer process (such as user ID, process ID, process security context, etc.) and the preset identity information table (including identity information corresponding to different application processes); if the consumer process passes the identity authentication, it means that the consumer process is trustworthy, and a token is issued to it; if the consumer process fails the identity authentication, it means that there are security risks in the consumer process, and a token is not issued to it, and an alarm message can be output at the same time. In this way, the identity token is generated after the identity information of the consumer process is authenticated, thereby improving the security of the identity token.

[0132] Optionally, the kernel capability can be used to authenticate the application process and issue a first identity token. In this way, the authenticated application process cannot break through the system kernel authority control, and even if it is remotely controlled by a hacker, it cannot forge the identity of another application process.

[0133] In some optional embodiments, after the first identity token is generated through step C3, the method may further include steps D1 and D2, as described below:

[0134] Step D1: Determine the remaining validity period of the first identity token according to the validity period of the first identity token.

[0135] Step D2: When the remaining validity period of the first identity token is less than or equal to the duration threshold, the consumption process re-applies for the token.

[0136] In the embodiment of the present application, the identity token can be temporary and have a valid period, but not permanent, to prevent long-term identity forgery caused by identity credential leakage, so as to improve security. Different validity periods can be set for application processes with different security levels.

[0137] In order to ensure that the application process uses the identity token in a timely manner, when the remaining validity period of the identity token reaches a time threshold, the application process can reapply for the token and update the identity token.

[0138] The specific update strategy can be set according to actual needs. For example, a fixed duration threshold is set, and when the remaining valid duration of the identity token is less than or equal to the fixed duration threshold, a new identity token is reapplied. This update strategy can ensure that the application process always has a valid identity token available, which is suitable for various resource access frequencies. For another example, the average time interval can be calculated based on the time interval of the application process requesting resources within a preset time period (set according to actual needs), and a duration threshold is determined based on the average time interval. When the remaining valid duration of the identity token is less than or equal to the duration threshold, a new identity token is reapplied. This update strategy can make more effective use of identity tokens, improve the utilization rate of identity tokens, and reduce the waste of resources caused by identity tokens not being used after application.

[0139] Optionally, the identity token may be set not to expire during the power-on cycle, that is, the identity token is valid while the vehicle system is powered on until the vehicle system is powered off. When the vehicle system is powered on again, a new identity token needs to be re-applied.

[0140] Optionally, for the above example, there may be two valid identity tokens at the same time, namely, the new and old tokens. Assume that the two identity tokens are the first identity token and the second identity token, wherein the first identity token is the old identity token, that is, the token that is about to expire; and the second identity token is the new identity token.

[0141] In view of this situation, considering some high-frequency resource access requirements, in order to improve the verification efficiency, a cache strategy can be adopted, that is, instead of repeatedly verifying the verified valid identity token, the first control domain can cache the verification result of the old identity token so that the consumer process can access resources in time; at the same time, the new identity token is verified asynchronously, and the second control domain sends the verification result to the first control domain for caching for the next resource access. The specific implementation can be as described in the following steps E1 to E4:

[0142] Step E1: Send the first identity token, the second identity token and a new resource access request to the first control domain.

[0143] Step E2: Receive the second identity token and second verification indication information sent by the first control domain.

[0144] The second verification indication information is used to instruct the second control domain to verify the second identity token.

[0145] Since the verification result of the first identity token is stored in the first control domain and the first identity token is valid at this time, the cached verification result can be directly used to perform subsequent processing operations. However, if the verification result of the second identity token is not stored in the first control domain, the second identity token needs to be verified by the second control domain. Therefore, when the first control domain determines that the first verification result is stored, it sends the second identity token and the second verification indication information to the second control domain.

[0146] It should be noted that, when it is detected that the first identity token is expired, the first control domain may delete the verification result of the first identity token.

[0147] Step E3: According to the second verification indication information, the signature information in the second identity token is verified to obtain a second verification result.

[0148] Step E4: Send the second verification result to the first control domain, so that the first control domain saves the second verification result.

[0149] In order to better understand the above scheme, Figure 5 and Figure 6 Provide further explanation.

[0150] like Figure 5 As shown, for the consumption process, there is no identity token at the beginning. When there is a need to access resources, the first identity token (called IdToken1) is applied for. After the application is completed, during the validity period of IdToken1, each time the identity token is used, it can be obtained from the cache.

[0151] When IdToken1 is about to expire, a new identity token (called IdToken2) is asynchronously applied for. After the application is completed, IdToken1 and IdToken2 coexist. During the coexistence of the two tokens, both tokens can be obtained from the cache. After IdToken1 expires, only IdToken2 is valid.

[0152] like Figure 6As shown, after applying for IdToken1, the second control domain receives the verification request of IdToken1 sent by the first control domain and verifies it. After the verification is completed, the verification result is sent to the first control domain, and the first control domain caches the verification result of IdToken1. During the validity period of IdToken1, each time the first control domain receives IdToken1, it obtains the verification result of IdToken1 from the cache, and there is no need to repeat the verification of IdToken1.

[0153] When IdToken1 is about to expire and IdToken2 is applied for asynchronously, the second control domain sends both IdToken1 and IdToken2 to the first control domain. At this stage, the first control domain obtains the verification result of IdToken1 from the cache and instructs the second control domain to asynchronously verify IdToken2. After the second control domain completes the verification of IdToken2, it sends the verification result to the first control domain, and the first control domain caches the verification result of IdToken2. At this time, the cache includes the verification results of IdToken1 and IdToken2. After this, if the first control domain receives verification requests for IdToken1 and IdToken2, it can obtain any one of the verification results from the cache. After IdToken1 expires, its verification result is cleared from the cache, and only the verification result of IdToken2 is retained.

[0154] in, Figure 5 and Figure 6 In the rectangular box used to represent the identity token, the dotted rectangular box indicates that there is no identity token, and the solid rectangular box indicates that there is an identity token.

[0155] In some optional embodiments, different control domains use different encryption keys to generate signature information, that is, each control domain has an encryption key for signing. Compared with the method of setting an encryption password for each application process, the number of keys can be reduced, and the pressure of key storage and management can be reduced. In addition, even if the encryption key is obtained through physical destruction or the identity credentials of a certain application process of a certain vehicle are obtained, it cannot be directly used to attack another vehicle, achieving the effect of one key for each vehicle.

[0156] Optionally, in order to improve information security, the encryption key for generating signature information can be an encryption key randomly generated each time the vehicle system is powered on. When the vehicle system is powered off and then powered on again, a new random key is generated. The key generated in this way can improve key security, reduce the probability of key being cracked, effectively prevent lateral attacks, and improve vehicle safety.

[0157] Optionally, the encryption key may be stored in memory during power-up of the vehicle system.

[0158] Optionally, in the embodiment of the present application, the vehicle system may further include a startup identifier. Each time the vehicle system is started, the value of the startup identifier is automatically increased. The automatically increased value may be 1, but is not limited thereto. It may be set according to actual needs. Accordingly, when the first identity token is generated, the startup identifier is added to the first identity token. The main purpose is to distinguish whether the signature verification failure is caused by the system restart key update or the attacker forging the signature.

[0159] The signature encryption key generated each time the vehicle system is started is randomly generated and stored in the memory, and the previous key will not be recorded. Therefore, after the vehicle system is restarted, the IdToken that was previously issued and is still valid cannot be verified, that is, the verification will fail. Therefore, when the first verification result indicates that the verification of the first identity token has failed, it is possible to prioritize whether the startup identifier in the first identity token is consistent with the startup identifier separately saved by the vehicle system. If they are inconsistent, it is prioritized that the verification failure is caused by the restart of the vehicle system, and you can reapply for the identity token. If they are consistent, it is considered that the signature information in the first identity token is illegal and may be forged by an attacker, and the security of the vehicle system needs to be improved.

[0160] In some optional embodiments, in the embodiments of the present application, it is necessary to downgrade the user (application process), that is, to set all users to non-root users to prevent the root user from maliciously tampering with security information (such as identity tokens, etc.). This can be achieved by setting the value of uid. For example, if the uid value of the root user is 0000, the uid of all users is set to non-0000.

[0161] The above is a description of the resource access control method provided in the embodiment of the present application.

[0162] Exemplary Devices

[0163] Accordingly, an embodiment of the present application further provides a resource access control device, which is applied to a first control domain in a vehicle-mounted system. The method includes:

[0164] like Figure 7 As shown, the device may include:

[0165] The first receiving module 701 is used to receive a first identity token and a resource access request sent by a consumption process.

[0166] Among them, the consumption process belongs to the second control domain in the vehicle-mounted system, the first identity token is issued to the consumption process by the second control domain, and the first identity token includes: the application identifier corresponding to the consumption process, the domain identifier of the second control domain, and the signature information generated based on the application identifier; the resource access request is used to request access to the resources of the service process in the first control domain.

[0167] The sending module 702 is used to send the first identity token and first verification indication information to the second control domain according to the domain identifier in the first identity token.

[0168] The first verification indication information is used to instruct the second control domain to verify the first identity token, and the verification includes verifying the signature information in the first identity token.

[0169] A second receiving module 703, configured to receive a first verification result sent by the second control domain;

[0170] The permission processing module 704 is used to determine whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token when the first verification result is successful.

[0171] Optionally, the device may further include:

[0172] A first determination module, configured to determine whether the application identifier in the first identity token belongs to the second control domain;

[0173] A first processing module, configured to execute the step of sending the first identity token and the first verification indication information to the second control domain when the application identifier belongs to the second control domain;

[0174] The second processing module is configured to determine that the first identity token is an illegally issued token when the application identifier does not belong to the first control domain.

[0175] Optionally, the permission processing module 704 may also be used to: when the first verification result is a verification failure, prohibit the consumer process from accessing the resources of the service process.

[0176] Optionally, the device may further include:

[0177] The first receiving module 701 may also be used to receive the first identity token, the second identity token and a new resource access request sent by the consuming process.

[0178] The first identity token is about to expire, and the second identity token is a newly applied identity token for the consumption process.

[0179] The permission processing module 704 can also be used to: when the first verification result is saved and the first verification result indicates that the verification is successful, determine whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token.

[0180] The sending module 702 may also be configured to: send the second identity token and second verification indication information to the second control domain according to the domain identifier in the second identity token.

[0181] The second verification indication information is used to instruct verification of the second identity token.

[0182] The second receiving module 703 may also be configured to: receive a second verification result sent by the second control domain, and save the second verification result.

[0183] The resource access control device provided in this embodiment belongs to the same application concept as the resource access control method applied to the first control domain provided in the above embodiment of this application, and can execute the resource access control method provided in any of the above embodiments of this application, and has the corresponding functional modules and beneficial effects of the execution method. For the technical details not described in detail in this embodiment, please refer to the specific processing content of the resource access control method provided in the above embodiment of this application, and will not be repeated here.

[0184] Correspondingly, an embodiment of the present application also provides a resource access control device, which is applied to a second control domain in a vehicle-mounted system.

[0185] like Figure 8 As shown, the device may include:

[0186] The first sending module 801 is used to send a first identity token and a resource access request to a first control domain in the vehicle system.

[0187] Among them, the first identity token is issued by the second control domain to the consumer process, and the resource access request is used to indicate that the consumer process requests access to the resources of the service process in the first control domain; the first identity token includes: the application identifier corresponding to the consumer process, the domain identifier of the second control domain, and the signature information generated based on the application identifier.

[0188] The first receiving module 802 is configured to receive the first identity token and first verification indication information sent by the first control domain.

[0189] The first verification indication information is used to instruct the second control domain to verify the first identity token.

[0190] The verification module 803 is used to verify the signature information in the first identity token according to the first verification indication information to obtain a first verification result.

[0191] The second sending module 804 is configured to send the first verification result to the first control domain.

[0192] Optionally, the device may further include:

[0193] The second receiving module is used to receive the token application request sent by the consumption process.

[0194] The identity authentication module is used to perform identity authentication on the consumption process based on the token application request.

[0195] The first identity token generation module is used to generate the first identity token when the consumption process passes the identity authentication.

[0196] Optionally, the device may further include:

[0197] A duration determination module, used to determine the remaining validity duration of the first identity token according to the validity duration of the first identity token;

[0198] A token application module, used for the consumption process to reapply for a token when the remaining validity period of the first identity token is less than or equal to a duration threshold; the duration threshold is a fixed duration value or is determined based on the average time interval of resource requests of the consumption process within a preset time period, and the duration threshold is less than the average time interval.

[0199] Optionally, the first sending module 801 may also be used to send the first identity token, the second identity token and a new resource access request to the first control domain, wherein the second identity token is an identity token newly applied for by the consumer process.

[0200] The first receiving module 802 may also be used to: receive the second identity token and second verification indication information sent by the first control domain. The second verification indication information is used to instruct the second control domain to verify the second identity token; when the first control domain determines that the first verification result is saved, the first control domain sends the second identity token and the second verification indication information to the second control domain.

[0201] The verification module 803 may also be used to verify the signature information in the second identity token according to the second verification indication information to obtain a second verification result.

[0202] The second sending module 804 may also be used to: send the second verification result to the first control domain.

[0203] Optionally, the device may further include:

[0204] A key generation module is used to randomly generate an encryption key each time the vehicle-mounted system is started; wherein the encryption key is used to generate signature information in the identity token.

[0205] Optionally, the vehicle-mounted system further includes a startup identifier, and each time the vehicle-mounted system is started, the value of the startup identifier automatically increases; correspondingly, when the first identity token is generated, the startup identifier is added to the first identity token.

[0206] The device may also include:

[0207] a comparison module, configured to determine whether the startup identifier in the first identity token is the same as the startup identifier additionally stored in the vehicle-mounted system when the first verification result indicates that the verification of the first identity token fails;

[0208] A comparison result analysis module is used to determine that the signature information in the first identity token is forged when the startup identifier in the first identity token is the same as the startup identifier separately saved in the vehicle system; or to determine that the failure of verification of the first identity token is caused by the restart of the vehicle system when the startup identifier in the first identity token is different from the startup identifier separately saved in the vehicle system.

[0209] The resource access control device provided in this embodiment belongs to the same application concept as the resource access control method applied to the second control domain provided in the above embodiment of this application, and can execute the resource access control method provided in any of the above embodiments of this application, and has the corresponding functional modules and beneficial effects of the execution method. For the technical details not described in detail in this embodiment, please refer to the specific processing content of the resource access control method provided in the above embodiment of this application, and will not be repeated here.

[0210] Exemplary Electronic Devices

[0211] The present application also provides an electronic device, which may be an electronic device on a vehicle, such as a vehicle controller. Fig. 9 As shown, the electronic device includes: a memory 900 and a processor 910 .

[0212] The memory 900 is connected to the processor 910 and is used to store programs.

[0213] The processor 910 is used to implement the resource access control method in the above embodiment by running the program stored in the memory 900.

[0214] Specifically, the electronic device may further include: a communication interface 920 , an input device 930 , an output device 940 and a bus 950 .

[0215] The processor 910, the memory 900, the communication interface 920, the input device 930 and the output device 940 are connected to each other via a bus.

[0216] Bus 950 may include a pathway for transferring information between the various components of the computer system.

[0217] The processor 910 may be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the scheme of the present invention. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0218] The processor 910 may include a main processor, and may also include a baseband chip, a modem, and the like.

[0219] The memory 900 stores a program for executing the technical solution of the present invention, and may also store an operating system and other key services. Specifically, the program may include a program code, and the program code includes a computer operation instruction. More specifically, the memory 900 may include a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM), other types of dynamic storage devices that can store information and instructions, a disk storage, a flash, and the like.

[0220] The input device 930 may include a device for receiving data and information input by a user, such as a keyboard, a mouse, a camera, a scanner, a light pen, a voice input device, a touch screen, a pedometer, or a gravity sensor.

[0221] Output device 940 may include devices that allow information to be output to a user, such as a display screen, printer, speaker, etc.

[0222] The communication interface 920 may include any transceiver or the like to communicate with other devices or communication networks, such as Ethernet, a radio access network (RAN), a wireless local area network (WLAN), etc.

[0223] The processor 910 executes the program stored in the memory 900 and calls other devices, which can be used to implement each step of the resource access control method provided in the above embodiment of the present application.

[0224] Exemplary computer program products and storage media

[0225] In addition to the above-mentioned method and device, the embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps in the resource access control method described in the embodiment of the present application.

[0226] The computer program product may be implemented in hardware, software or a combination thereof. In one optional embodiment, the computer program product is implemented as a computer storage medium. In another optional embodiment, the computer program product is implemented as a software product, such as a software development kit (SDK).

[0227] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0228] In addition, the embodiments of the present application may also be a storage medium on which a computer program is stored, and the computer program is executed by a processor to execute the steps of the resource access control method described in the embodiments of the present application.

[0229] For the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0230] It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0231] In the several embodiments provided in the present application, it should be understood that the disclosed terminals, devices and methods can be implemented in other ways. For example, the terminal embodiments described above are only schematic, for example, the division of modules or submodules is only a logical function division, and there may be other division methods in actual implementation, for example, multiple submodules or modules can be combined or integrated into another module, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, which can be electrical, mechanical or other forms.

[0232] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0233] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly by hardware, software units executed by a processor, or a combination of the two. The software units may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

Claims

1. A resource access control method, characterized in that: Applied to a first control domain in a vehicle-mounted system, the method comprises: Receive a first identity token and a resource access request sent by a consumer process; wherein the consumer process belongs to a second control domain in the vehicle-mounted system, the first identity token is issued to the consumer process by the second control domain, and the first identity token includes: an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier; the resource access request is used to request access to resources of a service process in the first control domain; According to the domain identifier in the first identity token, sending the first identity token and first verification indication information to the second control domain; wherein the first verification indication information is used to instruct the second control domain to verify the first identity token; receiving a first verification result sent by the second control domain; When the first verification result indicates that the verification is successful, it is determined whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token.

2. The resource access control method according to claim 1, characterized in that: Before sending the first identity token and the first verification indication information to the second control domain, the method further includes: determining whether the application identifier in the first identity token belongs to the second control domain; In a case where the application identifier belongs to the second control domain, executing the step of sending the first identity token and the first verification indication information to the second control domain; In a case where the application identifier does not belong to the second control domain, it is determined that the first identity token is an illegally issued token.

3. The resource access control method according to claim 1 or 2, characterized in that: After determining whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token, the method further includes: Receive the first identity token, the second identity token and a new resource access request sent by the consumer process; wherein the first identity token is about to expire, and the second identity token is an identity token newly applied for by the consumer process; When the first verification result is saved and the first verification result indicates that the verification is successful, determining whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token; According to the domain identifier in the second identity token, sending the second identity token and second verification indication information to the second control domain; wherein the second verification indication information is used to instruct to verify the second identity token; Receive a second verification result sent by the second control domain, and save the second verification result.

4. The resource access control method according to claim 1 or 2, characterized in that: After receiving the first verification result sent by the second control domain, the method further includes: When the first verification result indicates a verification failure, the consumer process is prohibited from accessing the resources of the service process.

5. A resource access control method, characterized in that: Applied to a second control domain in a vehicle-mounted system, the method comprises: Sending a first identity token and a resource access request to the first control domain in the vehicle system; wherein the first identity token is issued by the second control domain to the consumer process, and the resource access request is used to indicate that the consumer process requests to access the resources of the service process in the first control domain; the first identity token includes: an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier; receiving the first identity token and first verification indication information sent by the first control domain; wherein the first verification indication information is used to instruct the second control domain to verify the first identity token; Verify the first identity token according to the first verification indication information to obtain a first verification result; Send the first verification result to the first control domain.

6. The resource access control method according to claim 5, characterized in that: Before sending the first identity token and the resource access request to the first control domain in the vehicle system, the method further includes: Receiving a token application request sent by the consumption process; Based on the token application request, authenticating the consumption process; When the consumption process passes the identity authentication, the first identity token is generated.

7. The resource access control method according to claim 6, characterized in that: After generating the first identity token, the method further includes: Determining a remaining validity period of the first identity token according to the validity period of the first identity token; When the remaining validity period of the first identity token is less than or equal to a duration threshold, the consumption process reapplies for the token; wherein the duration threshold is a fixed duration value or is determined based on the average time interval of resource requests of the consumption process within a preset time period, and the duration threshold is less than the average time interval.

8. The resource access control method according to claim 7, characterized in that: After sending the first verification result to the first control domain, the method further includes: Sending the first identity token, the second identity token and a new resource access request to the first control domain; wherein the second identity token is an identity token newly applied for by the consumer process; receiving the second identity token and the second verification indication information sent by the first control domain; wherein the second verification indication information is used to instruct the second control domain to verify the second identity token; when the first control domain determines that the first verification result is saved, the second identity token and the second verification indication information are sent to the second control domain; Verify the signature information in the second identity token according to the second verification indication information to obtain a second verification result; Send the second verification result to the first control domain.

9. The resource access control method according to any one of claims 5 to 8, characterized in that: The method further comprises: Each time the vehicle-mounted system is started, an encryption key is randomly generated; wherein the encryption key is used to generate signature information in the identity token.

10. The resource access control method according to claim 9, characterized in that: The vehicle-mounted system further includes a startup identifier, and each time the vehicle-mounted system is started, the value of the startup identifier is automatically increased; accordingly, when the first identity token is generated, the startup identifier is added to the first identity token; The method further comprises: If the first verification result indicates that the verification of the first identity token fails, determining whether the startup identifier in the first identity token is the same as a startup identifier additionally stored in the vehicle-mounted system; If they are the same, determining that the signature information in the first identity token is forged; If different, it is determined that the failure of the verification of the first identity token is caused by the restart of the vehicle system.

11. A resource access control device, characterized in that: Applied to a first control domain in a vehicle-mounted system, the device comprises: A first receiving module is used to receive a first identity token and a resource access request sent by a consumer process; wherein the consumer process belongs to a second control domain in the vehicle-mounted system, the first identity token is issued to the consumer process by the second control domain, and the first identity token includes: an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier; the resource access request is used to request access to resources of a service process in the first control domain; A sending module, used for sending the first identity token and first verification indication information to the second control domain according to the domain identifier in the first identity token; wherein the first verification indication information is used to instruct the second control domain to verify the first identity token, and the verification includes verifying the signature information in the first identity token; A second receiving module, used to receive a first verification result sent by the second control domain; The permission processing module is used to determine whether the consumer process has resource access rights to the service process according to the application identifier in the first identity token when the first verification result indicates that the verification is successful.

12. A resource access control device, characterized in that: Applied to a second control domain in a vehicle-mounted system, the device comprises: A first sending module, used for sending a first identity token and a resource access request to a first control domain in the vehicle system; wherein the first identity token is issued by the second control domain to a consumer process, and the resource access request is used to indicate that the consumer process requests to access resources of a service process in the first control domain; the first identity token includes: an application identifier corresponding to the consumer process, a domain identifier of the second control domain, and signature information generated based on the application identifier; A first receiving module, configured to receive the first identity token and first verification indication information sent by the first control domain; wherein the first verification indication information is used to instruct the second control domain to verify the first identity token; A verification module, configured to verify the signature information in the first identity token according to the first verification indication information; The second sending module is used to send the first verification result to the first control domain.

13. An electronic device, characterized in that: Includes: includes: memory and processor; The memory is connected to the processor and is used to store programs; The processor is used to implement the resource access control method according to any one of claims 1 to 4 or claims 5 to 10 by running the program in the memory.

Images