Semantic gap vulnerability defense method and system based on Arm pointer authentication

Abstract

The invention belongs to the technical field of computer security, and particularly discloses a semantic gap vulnerability defense method and system based on Arm pointer authentication, and the method comprises the steps: obtaining a target request based on a unique identity label bound with the target request, a digital signature corresponding to the target request and a signature of a resource identifier corresponding to a trusted execution environment resource; verifying the access security of the target request to the trusted execution environment resource; under the condition that the verification is passed, in response to the target request, executing an access operation on the trusted execution environment resource; the unique identity identifier of the client application is bound to a target request through an Arm pointer authentication mode when the client application initiates a request for trusted execution environment resources. Through the application, the request parameters and requester identities of the CAs from a common world can be verified, operation and data isolation between different CAs are ensured, and semantic gap vulnerabilities are effectively defended.

Description

Technical Field

[0001] The present application belongs to the field of computer security technology, and more specifically, to a semantic gap vulnerability defense method and system based on Arm pointer authentication. Background Art

[0002] With the rapid development of information technology, the popularity of mobile devices, Internet of Things (IoT) devices, and other smart devices has brought about an urgent need for data security and privacy protection. In these devices, user data and applications often need to process sensitive information, such as personal identity information, payment information, and encryption keys. Therefore, it is particularly important to protect the data on these devices from the threats of malware, viruses, and attackers.

[0003] To address these challenges, the industry has adopted a variety of security technologies, one of which is the Trusted Execution Environment (TEE). TEE is a secure computing environment that uses hardware technology to support the creation of a trusted, isolated execution environment in an untrusted system. In this environment, sensitive data can be processed securely and sensitive operations can be performed securely.

[0004] Arm TrustZone technology is a popular way to implement TEE, which creates the so-called "Secure World" and "Normal World" (Non-secure World) by dividing system resources and execution environments at the processor level. The secure world runs certified software and can process sensitive data securely, while the normal world runs regular operating systems and applications and does not directly access sensitive data. This segmentation is achieved by introducing secure and non-secure states in the processor, where the secure state is used to execute code in the TEE, and the non-secure state is used to execute regular operating systems and applications.

[0005] Although TrustZone provides a strong security framework, it is not without vulnerabilities. In particular, there is a class of security issues known as "Semantic Gap Vulnerabilities" (SGVs) in the TrustZone environment. These vulnerabilities arise from the limited knowledge of the secure world about the operations of the common world, which makes it difficult to verify the request parameters and requester identity from the common world. Attackers can exploit these vulnerabilities to deceive the trusted application (TA) in the secure world by forging requests, thereby accessing or tampering with sensitive data stored by other client applications (CA).

[0006] Known SGVs include but are not limited to the following attack types: Pointer forgery: The attacker forges pointers or data to trick the attacker into performing unexpected memory accesses.

[0007] Session hijacking: The attacker illegally gains control of the TA session by forging a session identifier.

[0008] Global variable tampering: In single-instance mode, an attacker can steal or tamper with data stored by other CAs by accessing global variables in TA.

[0009] Persistent storage leakage: An attacker can illegally access other CA's persistent data by abusing the persistent storage identifier.

[0010] Opaque handle attack: The attacker obtains an opaque handle to sensitive resources (such as encryption keys) and abuses the services provided by the TA.

[0011] The existence of these vulnerabilities shows that although TrustZone provides hardware-level isolation, further measures are still needed at the software level to ensure the security of data and operations. For the Arm TrustZone environment, how to effectively defend against semantic gap vulnerabilities is a technical problem that needs to be solved urgently in this field. Summary of the invention

[0012] In view of the defects of the prior art, the purpose of this application is to effectively defend against semantic gap vulnerabilities in the Arm TrustZone environment.

[0013] To achieve the above objectives, in a first aspect, the present application provides a semantic gap vulnerability defense method based on Arm pointer authentication, the method comprising: Verify the security of the target request's access to the TEE resources based on the unique identity bound to the target request, the digital signature corresponding to the target request, and the signature of the resource identifier (resource ID) corresponding to the TEE resource; When the verification is successful, in response to the target request, an access operation to the trusted execution environment resources is performed; Among them, the target request is used to request access to the trusted execution environment resources; the unique identity of the client application (CA) is bound to the target request through the Arm pointer authentication method when the client application initiates a request for the trusted execution environment resources; the digital signature corresponding to the target request is generated based on the identity information of the client application that initiates the request; the signature of the resource identifier is generated based on the identity information of the client application to which the resource belongs.

[0014] It can be understood that by using Arm Pointer Authentication (PA) technology to bind the unique identity of the CA to the target request and by using the identity information of the CA to sign the resource ID, when the request is processed, based on the unique identity bound to the target request, the digital signature corresponding to the target request and the signature of the resource ID corresponding to the TEE resource, the security of the target request's access to the trusted execution environment resources can be verified. The request parameters and requester identity of the CA from the ordinary world can be verified, and the identity of the client application (CA) can be strongly bound and authenticated, effectively preventing malicious CAs from forging requests, improving the security of the system, and at the same time, ensuring that only authorized CAs can access specific resources, thereby enhancing the protection of sensitive data and operations.

[0015] Therefore, the semantic gap vulnerability defense method based on Arm pointer authentication provided by this application can verify the request parameters and requester identity of the CA from the ordinary world, ensure the operation and data isolation between different CAs, and effectively defend against semantic gap vulnerabilities.

[0016] In a possible implementation, before verifying the security of the target request's access to the trusted execution environment resources based on the unique identity identifier bound to the target request, the digital signature corresponding to the target request, and the signature of the resource identifier (resource ID) corresponding to the trusted execution environment (TEE) resource, the following is further included: Generate an identifier for the client application using a random number generator; Based on the identifier database, determining whether the generated identifier already exists in the identifier database; If the generated identifier does not exist in the identifier database, the generated identifier is used as the unique identity of the client application, and the generated identifier is stored in the identifier database.

[0017] In a possible implementation, the random number generator is specifically a secure random number generator, and the random numbers generated by the secure random number generator cannot be predicted.

[0018] In a possible implementation, the secure random number generator is specifically used to generate an identifier of the client application based on a random number, a timestamp, and specific information of the device (eg, a device serial number).

[0019] A secure random number generator is a special type of random number generator that generates random numbers with a high degree of unpredictability and security, and can resist various attacks, including prediction attacks and replay attacks. A secure random number generator can be based on encryption algorithms and rely on multiple entropy sources to ensure that the generated random numbers are statistically random, and is suitable for security-sensitive application scenarios such as encryption, authentication, and key generation.

[0020] In a possible implementation, the method further includes: When the client application (CA) initiates a target request for a trusted execution environment resource, the unique identity of the client application is bound to the target request through Arm pointer authentication; Based on the identity information of the client application and the summary information of the target request, a digital signature corresponding to the target request is generated through an encryption algorithm.

[0021] The identity information of the client application usually includes information such as the application name, application version, and application developer.

[0022] The summary information is obtained by performing a hash operation on the request content (such as request parameters, request path, etc.). Commonly used hash algorithms include SHA-256, SHA-1, etc.

[0023] The encryption algorithm can be used to encrypt the identity information of the client application and the summary information of the target request to obtain the digital signature corresponding to the target request.

[0024] In a possible implementation, the method further includes: When the client application (CA) is assigned a trusted execution environment (TEE) resource, a resource identifier (resource ID) corresponding to the trusted execution environment resource is generated; Based on the identity information of the client application to which the trusted execution environment resource belongs, a signature of the resource identifier corresponding to the trusted execution environment resource is generated through an encryption algorithm.

[0025] In a possible implementation, the method further includes: Store the data of different client applications (CA) on different storage media; Encrypt client application data and configure access control lists (ACLs).

[0026] By setting up access control lists, you can limit which CAs can access specific data.

[0027] In a possible implementation, the method further includes: Detect abnormal behavior in system logs and client application (CA) requests; When abnormal behavior is detected, exception handling is performed based on the preset security policy.

[0028] In a second aspect, the present application provides a semantic gap vulnerability defense system based on Arm pointer authentication, including: A request verification module, used to verify the security of the target request's access to the trusted execution environment resources based on the unique identity identifier bound to the target request, the digital signature corresponding to the target request, and the signature of the resource identifier corresponding to the trusted execution environment resource; The request response module is used to respond to the target request and perform access operations on the trusted execution environment resources when the verification is passed; Among them, the target request is used to request access to the trusted execution environment resources; the unique identity of the client application is bound to the target request through the Arm pointer authentication method when the client application initiates a request for the trusted execution environment resources; the digital signature corresponding to the target request is generated based on the identity information of the client application that initiates the request; the signature of the resource identifier is generated based on the identity information of the client application to which the resource belongs.

[0029] In a third aspect, the present application provides an electronic device comprising: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0030] In general, the above technical solutions conceived by this application have the following beneficial effects compared with the prior art: (1) By using Arm Pointer Authentication technology in the Arm TrustZone environment, strong binding and authentication of the identity of the client application (CA) is achieved, effectively preventing malicious CAs from forging requests and improving system security.

[0031] (2) By signing the resource ID when allocating resources and incorporating the CA's identity information into the signing process, it ensures that only authorized CAs can access specific resources, thereby enhancing the protection of sensitive data and operations.

[0032] (3) Without modifying the existing CA and TA, isolated storage of sensitive data between different CAs is achieved, reducing the cost and complexity of system transformation, while providing more sophisticated data protection measures.

[0033] (4) The anomaly detection and processing mechanism provided can respond quickly when signature verification failure or other abnormal behavior is detected, and terminate the execution of malicious CA in time, effectively avoiding potential security threats.

[0034] (5) The performance evaluation and optimization mechanism provided ensures that the introduction of security enhancements will not significantly affect system performance, thus ensuring the efficient operation of the system.

[0035] (6) It is compatible and easy to deploy. It can be easily integrated with existing CA and TA without modifying them, which simplifies the deployment process and reduces costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 This is one of the flow diagrams of the semantic gap vulnerability defense method based on Arm pointer authentication provided in an embodiment of the present application; Figure 2 It is a general architecture diagram of semantic gap vulnerability defense based on Arm pointer authentication provided by an embodiment of the present application; Figure 3 This is the second flow chart of the semantic gap vulnerability defense method based on Arm pointer authentication provided in the embodiment of the present application; Figure 4 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0038] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0039] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more than two. For example, multiple processing units refer to two or more processing units, etc.; multiple elements refer to two or more elements, etc.

[0040] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application.

[0041] Figure 1 This is one of the flow charts of the semantic gap vulnerability defense method based on Arm pointer authentication provided in the embodiment of the present application, such as Figure 1 As shown, the method includes the following steps S101 and S102.

[0042] Step S101, verifying the security of the target request's access to the trusted execution environment resources based on the unique identity identifier bound to the target request, the digital signature corresponding to the target request, and the signature of the resource identifier (resource ID) corresponding to the trusted execution environment (TEE) resource; Step S102, when the verification is passed, in response to the target request, performing an access operation to the trusted execution environment resources; Among them, the target request is used to request access to the trusted execution environment resources; the unique identity of the client application (CA) is bound to the target request through the Arm pointer authentication method when the client application initiates a request for the trusted execution environment resources; the digital signature corresponding to the target request is generated based on the identity information of the client application that initiates the request, and the unique identity of the client application (CA) can be used as the identity information; the signature of the resource identifier is generated based on the identity information of the client application to which the resource belongs.

[0043] It can be understood that by using Arm Pointer Authentication (PA) technology to bind the unique identity of the CA to the target request and by using the identity information of the CA to sign the resource ID, when the request is processed, based on the unique identity bound to the target request, the digital signature corresponding to the target request and the signature of the resource ID corresponding to the TEE resource, the security of the target request's access to the trusted execution environment resources can be verified. The request parameters and requester identity of the CA from the ordinary world can be verified, and the identity of the client application (CA) can be strongly bound and authenticated, effectively preventing malicious CAs from forging requests, improving the security of the system, and at the same time, ensuring that only authorized CAs can access specific resources, thereby enhancing the protection of sensitive data and operations.

[0044] Therefore, the semantic gap vulnerability defense method based on Arm pointer authentication provided by this application can verify the request parameters and requester identity of the CA from the ordinary world, ensure the operation and data isolation between different CAs, and effectively defend against semantic gap vulnerabilities.

[0045] The following is an illustrative description of the semantic gap vulnerability defense method based on Arm pointer authentication provided by this application with reference to several examples.

[0046] This application provides a trusted execution environment security system based on Arm TrustZone, called a Mate System for the TEE, referred to as MaTEE. The overall framework is as follows Figure 2 As shown, Figure 2 PAC stands for Pointer Authentication Code. Figure 3 As shown, the following steps are included: S1. CA identity generation; In this step, the system generates a unique identity for each client application (CA). This process consists of two sub-steps.

[0047] S1.1, Identifier generation mechanism; The system uses a secure random number generator to create a unique identifier for each CA. This generator is designed to resist prediction attacks, ensuring that each identifier generated is unpredictable. The generated identifier is then securely stored along with the CA's metadata in an isolated storage area of ​​the TEE that can only be accessed by the secure world.

[0048] S1.2, Identifier uniqueness verification; To ensure the uniqueness of the identifier, each time a new identifier is generated, it is compared to a centrally stored database of identifiers. This database contains all the assigned identifiers. If any duplications are found, the system will regenerate the identifier until a unique identifier is obtained. To further increase the uniqueness of the identifier, the generation process also takes into account the current timestamp and device-specific information, such as the device serial number.

[0049] S2, request binding and signature; In this step, the system ensures that each client application (CA) request is bound to its unique identity and generates a digital signature for each request. This process consists of two sub-steps.

[0050] S2.1, binding mechanism; When the CA initiates a request for TEE resources (such as secure storage, cryptographic services, etc.), the system uses Arm Pointer Authentication (PA) technology to bind the CA's unique identity to the request. This process involves encapsulating the request at the operating system level to ensure the security and integrity of the request during transmission. PA technology ensures the authenticity and integrity of the pointer by signing the memory address. This mechanism ensures the security of the request during transmission by encrypting the request at the software level.

[0051] Arm pointer authentication is a security feature designed to enhance the security of computer systems, especially in preventing certain types of attacks (such as buffer overflows and code injection attacks). It is part of the Arm architecture and is mainly used in Armv8.3-A and later. The basic idea of ​​Arm pointer authentication is to add an authentication code (or signature) to pointers (such as function pointers and data pointers). This authentication code is generated based on the value of the pointer and a key. Specifically, the process of pointer authentication can be divided into the following steps. (1) Generate authentication code: Before a pointer is created or used, the system generates an authentication code using a key and the value of the pointer. This authentication code is appended to the value of the pointer. (2) Storing pointers: Authenticated pointers can be securely stored in memory. Since the authentication code is generated based on the value of the pointer, even if an attacker tries to tamper with the value of the pointer, the authentication code will become invalid. (3) Verify the pointer: Before using the pointer, the system checks whether the authentication code of the pointer is valid. If the authentication code matches the authentication code generated by the pointer value and the key, the pointer is considered valid; otherwise, the system denies access to prevent potential attacks.

[0052] The above uses Arm Pointer Authentication (PA) technology to bind the CA's unique identity to the request. Specifically, an authentication code can be generated using the CA's unique identity, the requested memory address and a key (usually a key securely stored in the TEE); or an authentication code can be generated using the CA's unique identity (as a key) and the requested memory address. The generated authentication code will be attached to the request.

[0053] S2.2, signature generation; For each request, the system generates a digital signature. This signature contains the CA's identity information and the summary information of the request to ensure the integrity of the request and the verifiability of the source. CA is the application that users rely on to communicate with TA. The operating system assigns an exclusive ID (that is, the CA's unique identity) to each application as identity information, and this system uses this ID for signing. The signing process uses a secure hash algorithm (such as SHA-256) and asymmetric encryption technology (such as RSA or ECDSA) to ensure the security and non-repudiation of the signature. The generation of the digital signature is completed before the request is sent to the TEE, ensuring the security of the request during transmission.

[0054] S3, resource ID signature; In this step, the system assigns a unique resource ID to each resource and signs these resource IDs to ensure the security of the resources. This process includes two sub-steps.

[0055] S3.1, resource ID allocation; The system assigns a unique resource ID to each resource and signs the resource ID using the CA's identity information. This process ensures that only authorized CAs can access specific resources. The resource ID signature uses the same encryption technology as the request signature to ensure security. Resource IDs are assigned when resources are created or allocated, ensuring that each resource has a unique identifier.

[0056] S3.2, the signature contains identity information; The signature of the resource ID contains the CA's identity information, so when the CA attempts to access the resource, the system can verify the CA's identity and authorization status by verifying the signature. This mechanism effectively prevents unauthorized access and resource abuse. The signature verification is performed when the resource is accessed, ensuring the security of the resource and the accuracy of access control.

[0057] S4, Sensitive data isolation; In this step, the system implements data isolation strategy to ensure that sensitive data between different CAs is stored in isolation to protect the data from being accessed by unauthorized CAs. This process includes two sub-steps.

[0058] S4.1. Data isolation strategy; The system implements a data isolation strategy to ensure that sensitive data between different CAs is stored in isolation. This strategy is based on the CA's identity and resource ID to ensure that data can only be accessed by authorized CAs. Data isolation strategies include physical isolation and logical isolation. Physical isolation is achieved by storing data on different storage media, while logical isolation is achieved through encryption and access control lists (ACLs).

[0059] S4.2. Implementation of data isolation; The implementation of data isolation involves the physical and logical isolation of data storage. Physical isolation is achieved by storing data on different storage media, for example, using different physical hard disks or solid-state drives to store data from different CAs. Logical isolation is achieved through encryption and access control lists (ACLs) to ensure that only authorized users can access specific data. The implementation of data isolation is performed when data is stored, ensuring the security and isolation of data.

[0060] S5, access control and authentication; In this step, the system implements access control mechanisms to ensure that only authorized CAs can access TEE resources. This process consists of two sub-steps.

[0061] S5.1, access control mechanism; The system implements an access control mechanism to ensure that only authorized CAs can access TEE resources. Access control is based on the signature verification results of the CA's identity and resource ID. If the signature verification succeeds, the request will be allowed to proceed; if the verification fails, the request will be rejected. The access control mechanism is performed when the request is processed, ensuring the security of resources and the accuracy of access control.

[0062] S5.2, verification process; The verification process involves checking whether the signature in the request matches the CA's identity and resource ID. This process is performed in the secure world to ensure the security and accuracy of the verification. The verification process involves verifying the digital signature and confirming the CA's identity. If the verification is successful, the system will allow the CA to access the requested resources; if the verification fails, the system will deny access and may trigger a security alert.

[0063] S6, anomaly detection and processing; In this step, the system implements anomaly detection and handling mechanisms to identify and respond to potential security threats. This process consists of two sub-steps.

[0064] S6.1, anomaly detection mechanism; The system implements an anomaly detection mechanism to monitor and identify potential security threats. This includes analysis of the frequency, pattern, and content of requests to identify anomalous behavior. Anomaly detection mechanisms may also include real-time monitoring and analysis of system logs and monitoring of network traffic to identify suspicious activity.

[0065] Here is an example of the request frequency analysis process: (1) Baseline establishment: First, establish a baseline for the request frequency under normal operation. This includes the user's login frequency, data access times, etc. (2) Frequency threshold setting: Set the frequency threshold based on the baseline data. When the request frequency exceeds the normal range, an alarm will be triggered. (3) Dynamic adjustment: Dynamically adjust the threshold based on historical data and current trends to adapt to environmental changes.

[0066] Here is an example of the request pattern analysis process: (1) Behavior pattern recognition: learn the normal behavior pattern of CA through machine learning algorithms, including operation time, operation type, etc. (2) Abnormal pattern detection: when the request pattern does not match the normal behavior pattern of CA, it will be marked as abnormal. (3) Pattern matching: compare the request pattern with the known attack pattern to identify possible attack behaviors.

[0067] Here is an example of the request content analysis process: (1) Content review: In-depth analysis of the request content. (2) Data encryption verification: For sensitive data, its encryption status will be verified to ensure data security. (3) File type check: The uploaded file type will be checked to prevent malicious files from being uploaded.

[0068] Here is an example of the process of real-time monitoring and analysis of system logs: (1) Log collection: The system collects logs generated by the operating system, applications, and network security devices. (2) Log analysis: Through log analysis tools, the system can identify abnormal system behaviors, such as frequent login failures, permission changes, etc. (3) Real-time alarm: Once an abnormal log is detected, the system will immediately issue an alarm to notify the security administrator.

[0069] Here is an example of the process of monitoring network traffic: (1) Traffic analysis: The system monitors network traffic and analyzes the size, direction, and protocol type of the traffic. (2) Abnormal traffic identification: By comparing the normal traffic pattern, the system can identify abnormal traffic, such as DDoS attacks, port scanning, etc. (3) Traffic control: For the identified abnormal traffic, the system can take measures to restrict it, such as speed limiting, blocking, etc.

[0070] S6.2, exception handling strategy; Once abnormal behavior is detected, the system will take appropriate action according to the preset security policy. This may include sending an alert, terminating suspicious requests, or performing a deeper security check. Exception handling policies are designed to quickly respond to potential security threats to protect the integrity of the system. Actions may also include isolating the affected system or network portion and notifying the system administrator for further investigation.

[0071] S7, performance evaluation and optimization; In this step, the system periodically performs performance evaluations and implements optimization measures based on the evaluation results to ensure efficient operation of the system. This process consists of two sub-steps.

[0072] S7.1, Performance evaluation; The system is regularly evaluated for performance to ensure that security enhancements do not negatively impact system performance. The evaluation includes monitoring of system resource usage, response time, and throughput. Performance evaluation can be performed using automated tools to ensure accuracy and consistency. The evaluation results will be used to guide the implementation of performance optimization measures.

[0073] S7.2, performance optimization implementation; Based on the results of the performance evaluation, the system will implement necessary optimization measures. This may include adjusting the parameters of the security policy, optimizing the implementation of the algorithm, or upgrading the hardware resources. The purpose of performance optimization is to ensure that the system can maintain efficient operation while providing security. Optimization measures may also include adjustments to the system configuration, as well as updates to software and firmware.

[0074] S8, Compatibility and deployment; In this step, the system performs compatibility testing and develops deployment strategies to ensure that the MaTEE system can be seamlessly integrated with existing CAs and TAs. This process includes two sub-steps.

[0075] S8.1. Compatibility test; The system performs compatibility testing to ensure that the MaTEE system can be seamlessly integrated with existing CAs and TAs. The test includes compatibility verification of different versions of CAs and TAs. The purpose of compatibility testing is to ensure that the MaTEE system can adapt to different software and hardware environments. The testing process may include testing in a simulated environment, as well as testing in an actual deployment environment.

[0076] S8.2, deployment strategy; The deployment strategy aims to simplify the deployment process of the MaTEE system and ensure that it can be easily integrated with existing applications. This includes providing detailed deployment guides and automation tools to reduce the complexity and cost of deployment. The deployment strategy also takes into account the scalability of the system and future upgrade paths. The deployment process may include an assessment of the existing system, as well as the configuration and installation of the new system.

[0077] Through the above solution, the MaTEE system can effectively defend against semantic gap vulnerabilities (SGVs) in the Arm TrustZone environment while maintaining the high performance and ease of use of the system. This solution not only improves the security of the system, but also reduces the complexity of deployment and maintenance.

[0078] The semantic gap vulnerability defense system based on Arm pointer authentication provided by the present application is described below. The semantic gap vulnerability defense system based on Arm pointer authentication described below and the semantic gap vulnerability defense method based on Arm pointer authentication described above can be referenced to each other.

[0079] The present application provides a semantic gap vulnerability defense system based on Arm pointer authentication, including: A request verification module, used to verify the security of the target request's access to the trusted execution environment resources based on the unique identity identifier bound to the target request, the digital signature corresponding to the target request, and the signature of the resource identifier corresponding to the trusted execution environment resource; The request response module is used to respond to the target request and perform access operations on the trusted execution environment resources when the verification is passed; Among them, the target request is used to request access to the trusted execution environment resources; the unique identity of the client application is bound to the target request through the Arm pointer authentication method when the client application initiates a request for the trusted execution environment resources; the digital signature corresponding to the target request is generated based on the identity information of the client application that initiates the request; the signature of the resource identifier is generated based on the identity information of the client application to which the resource belongs.

[0080] It can be understood that the detailed functional implementation of each of the above-mentioned units / modules can be found in the introduction of the aforementioned method embodiment, and will not be repeated here.

[0081] It should be understood that the above-mentioned system is used to execute the methods in the above-mentioned embodiments. The implementation principles and technical effects of the corresponding program modules in the system are similar to those described in the above-mentioned methods. The working process of the system can refer to the corresponding process in the above-mentioned method and will not be repeated here.

[0082] Based on the method in the above embodiment, an embodiment of the present application provides an electronic device, Figure 4 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application, such as Figure 4 As shown, the electronic device may include: a processor (Processor) 810, a communication interface (Communications Interface) 820, a memory (Memory) 830 and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other through the communication bus 840. The processor 810 can call the logic instructions in the memory 830 to execute the method in the above embodiment.

[0083] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application.

[0084] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0085] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0086] It is understandable that the processor in the embodiment of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0087] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0088] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can 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 process or function described in the embodiment of the present application is 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 through the computer-readable storage medium. The computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

[0089] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0090] It will be easily understood by those skilled in the art that the above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A semantic gap vulnerability defense method based on Arm pointer authentication, characterized in that: include: Verify the security of the target request's access to the trusted execution environment resources based on the unique identity identifier bound to the target request, the digital signature corresponding to the target request, and the signature of the resource identifier corresponding to the trusted execution environment resource; When the verification is successful, in response to the target request, an access operation to the trusted execution environment resources is performed; Among them, the target request is used to request access to the trusted execution environment resources; the unique identity of the client application is bound to the target request through the Arm pointer authentication method when the client application initiates a request for the trusted execution environment resources; the digital signature corresponding to the target request is generated based on the identity information of the client application that initiates the request; the signature of the resource identifier is generated based on the identity information of the client application to which the resource belongs.

2. The semantic gap vulnerability defense method based on Arm pointer authentication according to claim 1 is characterized in that: Before verifying the security of the target request's access to the trusted execution environment resource based on the unique identity identifier bound to the target request, the digital signature corresponding to the target request, and the signature of the resource identifier corresponding to the trusted execution environment resource, the method further includes: Generate an identifier for the client application using a random number generator; Determining whether the generated identifier already exists in the identifier database; If the generated identifier does not exist in the identifier database, the generated identifier is used as the unique identity of the client application, and the generated identifier is stored in the identifier database.

3. The semantic gap vulnerability defense method based on Arm pointer authentication according to claim 2 is characterized in that: The random number generator is specifically a secure random number generator, and the random numbers generated by the secure random number generator cannot be predicted.

4. The semantic gap vulnerability defense method based on Arm pointer authentication according to claim 3 is characterized in that: The secure random number generator is specifically used to generate an identifier of a client application based on a random number, a timestamp and specific information of a device.

5. The semantic gap vulnerability defense method based on Arm pointer authentication according to claim 1 is characterized in that: Also includes: When a client application initiates a target request for a trusted execution environment resource, the unique identity of the client application is bound to the target request through Arm pointer authentication; Based on the identity information of the client application and the summary information of the target request, a digital signature corresponding to the target request is generated through an encryption algorithm.

6. The semantic gap vulnerability defense method based on Arm pointer authentication according to claim 1, characterized in that: Also includes: When the client application is allocated with the trusted execution environment resource, generating a resource identifier corresponding to the trusted execution environment resource; Based on the identity information of the client application to which the trusted execution environment resource belongs, a signature of the resource identifier corresponding to the trusted execution environment resource is generated through an encryption algorithm.

7. The semantic gap vulnerability defense method based on Arm pointer authentication according to claim 1, characterized in that: Also includes: Store data of different client applications on different storage media; Encrypt client application data and configure access control lists.

8. The semantic gap vulnerability defense method based on Arm pointer authentication according to claim 1, characterized in that: Also includes: Detect abnormal behavior in system logs and client application requests; When abnormal behavior is detected, exception handling is performed based on the preset security policy.

9. A semantic gap vulnerability defense system based on Arm pointer authentication, characterized in that: include: A request verification module, used to verify the security of the target request's access to the trusted execution environment resources based on the unique identity identifier bound to the target request, the digital signature corresponding to the target request, and the signature of the resource identifier corresponding to the trusted execution environment resource; The request response module is used to respond to the target request and perform access operations on the trusted execution environment resources when the verification is passed; Among them, the target request is used to request access to the trusted execution environment resources; the unique identity of the client application is bound to the target request through the Arm pointer authentication method when the client application initiates a request for the trusted execution environment resources; the digital signature corresponding to the target request is generated based on the identity information of the client application that initiates the request; the signature of the resource identifier is generated based on the identity information of the client application to which the resource belongs.

10. An electronic device, characterized in that: include: at least one memory for storing a computer program; At least one processor is used to execute the program stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method according to any one of claims 1 to 8.

Images