Communication method based on trusted execution environment and electronic device
By obtaining the virtual address range of the CA in the mobile terminal and determining whether it includes the function address that calls the TEE communication interface, the problem of TEE data being easily accessed illegally by attackers is solved, thus achieving higher data security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HONOR DEVICE CO LTD
- Filing Date
- 2024-03-22
- Publication Date
- 2026-05-29
AI Technical Summary
In existing technologies, data stored in the Trusted Execution Environment (TEE) of a mobile terminal is vulnerable to unauthorized access by attackers, leading to data leakage and reduced data security.
By obtaining the virtual address range of the client application (CA), it is determined whether it includes the virtual address of the function that calls the TEE communication interface. If they match, communication is allowed; otherwise, communication is prohibited to prevent unauthorized attackers from stealing data from the TEE.
It improves the security of important data, prevents data stored in TEE from being obtained by unauthorized third parties, and enhances data protection capabilities.
Smart Images
Figure CN120724426B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of terminals, and more particularly to a communication method and electronic device based on a trusted execution environment. Background Technology
[0002] With the development of terminal technology, mobile terminals involve more and more important data (e.g., sensitive user data). To improve the security of mobile terminals, a Trusted Execution Environment (TEE) has been proposed. The TEE is an independent runtime environment that can be isolated from the rich execution environment (REE) on the mobile terminal, and is used to store important data.
[0003] Applications running in the TEE are called trusted applications (TAs), while applications running in the REE are called client applications (CAs). CAs can communicate with TAs. For example, when important data needs to be stored in the TEE, the CA can send the important data to the TA, so that the TA can store the important data in the relevant storage media of the TEE.
[0004] However, in the existing technology, the communication between CA and TA has at least the following problems: when the mobile terminal is attacked by an attacker using a vulnerability, the data stored in the TEE may be illegally accessed by the attacker, causing the data stored in the TEE to be leaked to a third party other than the CA, thereby reducing the security of the data. Summary of the Invention
[0005] This application provides a communication method and electronic device based on a trusted execution environment, which prevents TA1 data from being leaked to third parties other than CA1, thereby improving the security of important data.
[0006] Firstly, this application provides a communication method based on a Trusted Execution Environment (TEE), applied to an electronic device including a Rich Execution Environment (REE) and a Trusted Execution Environment (TEE). The method includes: when a first client application (CA) in the REE sends a first access request to the TEE communication interface through a first function, obtaining a first virtual address of the first function. The first access request is used to trigger a first TA to perform a first operation. A first virtual address segment is obtained, wherein the first virtual address segment is used to store the program execution code of the first CA. It is determined whether the first virtual address segment includes the first virtual address. If the first virtual address segment includes the first virtual address, the first TA responds to the first access request sent by the TEE communication interface and performs the first operation.
[0007] In one possible implementation, the first access request includes the identifier of the first CA. Obtaining the first virtual address range specifically includes: based on the identifier of the first CA, retrieving the first virtual address range corresponding to the identifier of the first CA from a mapping record table in the electronic device. The mapping record table is used to record the identifiers of one or more CAs and the virtual address ranges corresponding to the identifiers of the one or more CAs.
[0008] In one possible implementation, the method further includes: if the first virtual address range does not include the first virtual address, prohibiting the first access request from being sent to the first TA.
[0009] In one possible implementation, the electronic device further includes a TEE OS driver. Obtaining the first virtual address of the first function specifically includes: obtaining the first virtual address of the first function through the TEE communication interface. After obtaining the first virtual address of the first function, the method further includes: sending the first virtual address to the TEE OS driver through the TEE communication interface.
[0010] In one possible implementation, obtaining the first virtual address range specifically includes: obtaining the first virtual address range through the TEE OS driver.
[0011] In one possible implementation, the TEE in the electronic device includes an authentication module. Before determining whether the first virtual address range includes the first virtual address, the method further includes: sending the first virtual address and the first virtual address range to the authentication module through the TEE OS driver. The determination of whether the first virtual address range includes the first virtual address specifically includes: determining whether the first virtual address range includes the first virtual address through the authentication module.
[0012] In one possible implementation, the first operation includes one or more of the following: encrypting important data in CA1, decrypting important data in CA1, storing the private key of CA1, and storing the private key certificate of CA1.
[0013] In a second aspect, this application provides an electronic device including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, the computer program code including computer instructions. The one or more processors are used to execute the computer instructions to cause the electronic device to perform a method as described in any of the possible implementations of the first aspect above.
[0014] Thirdly, this application provides a chip system applied to an electronic device, the chip system including one or more processors, the processors being configured to invoke computer instructions to cause the electronic device to perform a method as described in any of the possible implementations of the first aspect above.
[0015] Fourthly, this application provides a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform a method as described in any of the possible implementations of the first aspect above.
[0016] Fifthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform a method as described in any of the possible implementations of the first aspect above. Attached Figure Description
[0017] Figure 1A This is a schematic diagram illustrating a method for communication between a CA and a TA, provided in an embodiment of this application.
[0018] Figure 1B This application provides a schematic diagram illustrating a data leakage scenario for TA1.
[0019] Figure 2 A schematic diagram of a system architecture provided for an embodiment of this application;
[0020] Figure 3 A schematic diagram of module interaction provided for an embodiment of this application;
[0021] Figure 4 A schematic diagram illustrating the specific process of a communication method based on a trusted execution environment provided in this application embodiment;
[0022] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0023] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to including one or more of the listed prominent features, any or all possible combinations. In the embodiments of this application, the terms “first” and “second” are used for descriptive purposes only and should not be construed as implying relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as “first” or “second” may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, “a plurality” means two or more.
[0024] To facilitate understanding of the embodiments of this application, some terms used in the embodiments of this application are explained below:
[0025] 1. Rich Execution Environment (REE): REE generally refers to a runtime environment that does not have specific security features, such as the Android or iOS operating system. It should be noted that, in addition to being called a "rich execution environment" or "complex execution environment," REE can also be called an "untrusted execution environment," "ordinary execution environment," "insecure execution environment," etc., and this application embodiment does not limit it in this way.
[0026] 2. Trusted Execution Environment (TEE): A TEE is an independent processing environment with computation and storage capabilities, providing security and integrity protection. Its basic idea is to allocate a separate, isolated block of memory within the hardware for sensitive data. All computations on sensitive data are performed within this memory block, and no other part of the hardware can access the information in this isolated memory block except through authorized interfaces. This achieves privacy-preserving computation of sensitive data.
[0027] In comparison, an REE (Remote Execution Environment) is an open environment vulnerable to attacks such as the theft of sensitive data and mobile payment fraud; while a TEE (Trusted Execution Environment) is a secure zone on the central processing unit that ensures sensitive data is processed in an isolated and trusted environment, thus protecting it from software attacks originating from the REE. Furthermore, compared to other secure execution environments, a TEE can protect the integrity and confidentiality of trusted applications end-to-end, providing greater processing power and larger memory space.
[0028] 3. The REE+TEE architecture is an architecture that combines TEE and REE to provide services to applications. In other words, the TEE and REE coexist within the electronic device. Through hardware support, the TEE and REE are isolated, providing security capabilities and resisting software attacks that are common to conventional REEs. The TEE has its own operating space with defined strict protection measures, therefore offering a higher level of security than the REE, protecting data and software within the TEE from software attacks and resisting specific types of security threats.
[0029] 4. Trusted Application (TA): This is an application running in the TEE that can provide security services to client applications running outside the TEE, such as password input, transaction signature generation, and facial recognition.
[0030] 5. Client Application (CA): A CA typically refers to an application running within the REE, but in certain cases where a TA calls another TA, the TA that initiates the call can also act as a CA. The CA can invoke the TA and instruct it to perform corresponding security operations through the TEE's application programming interface (API). This API can also be called the TEE communication interface (teeosapi).
[0031] 6. lib file: A file with the extension .so or .a, which in this embodiment can also be called a function linker file, serving to link programs and functions (or subroutines). The lib file stores information about function calls.
[0032] In other implementations, the function linker file may be other types of files besides the lib file, and this application does not impose any restrictions on this.
[0033] Figure 1A This is a schematic diagram illustrating a method for communication between a CA and a TA, as provided in an embodiment of this application.
[0034] like Figure 1AAs shown, this embodiment uses CA1 and TA1 for communication, with the function linking file being lib file 1 as an example. CA1 runs in the REE, and TA1 runs in the TEE. CA1 can be various payment applications, bank clients, mobile security token applications, electronic device ID cards, mobile POS terminals, or other applications involving sensitive information and important data such as account numbers and passwords. TA1 is the security application corresponding to CA1, used for inputting sensitive information related to CA1, encrypting / decrypting important data in CA1, storing CA1's private key / certificate, etc. For example, in scenarios such as mobile payment and online banking transfers, if the input and display of sensitive user information are involved, CA1 in the REE can use TA1 to call the trusted keyboard service to receive the user's sensitive input information, preventing malicious programs on the REE side from eavesdropping on and stealing the user's sensitive information.
[0035] For example, when CA1 needs to communicate with TA1, CA1 can call lib file 1, and lib file 1 can then call the TEE communication interface (teeosapi) provided by the TEE and running in the REE, thereby enabling CA1 to communicate with TA1 through the TEE communication interface. In some implementations, the TEE communication interface (teeosapi) can be provided by the TEE to the CA in the REE through a lib file (e.g., lib file 3). The electronic device can authenticate lib file 3 to ensure that the TEE communication interface cannot be tampered with by malicious third-party attackers.
[0036] In one possible implementation ( Figure 1A (Not shown) When CA1 needs to communicate with TA1, CA1 can directly call the TEE communication interface without going through lib file 1, thus enabling CA1 to communicate with TA1 through the TEE communication interface.
[0037] Not limited to the above examples, CA1 and TA1 can also communicate in other ways, and this application does not limit them.
[0038] Combination Figure 1A , Figure 1B This is a schematic diagram illustrating a data leakage scenario of TA1 provided in an embodiment of this application.
[0039] like Figure 1B As shown, when CA1 and TA1 pass through Figure 1AWhen communication is conducted in the manner shown, if a third-party attacker exists, they could replace lib file 1 or modify its references, causing CA1 to no longer call the TEE communication interface through lib file 1, but instead call lib file 2, which is associated with the attacker, and then call the TEE communication interface through lib file 2. In this scenario, when CA1 communicates with TA1 through the TEE communication interface, lib file 2 can also obtain TA1's data from the TEE communication interface and send it to the attacker. This would result in the leakage of TA1's data, allowing the attacker to illegally access it and thus reducing data security.
[0040] Therefore, this application provides a communication method based on a Trusted Execution Environment (TEE). When implementing this method, if CA1 needs to communicate with TA1 via the TEE communication interface, the electronic device can obtain the virtual address 1 of the function F that calls the TEE communication interface and the virtual address segment 2 (also known as CA1's code segment range) used to store CA1's program execution code. Then, the electronic device can determine whether virtual address segment 2 includes virtual address 1. If so, the electronic device can determine that CA1 is calling the TEE communication interface. During this process, the probability of a third-party attacker illegally obtaining TA1's data by replacing lib files or modifying lib file references is low. Therefore, the electronic device can allow CA1 to communicate with TA1 via the TEE communication interface. This prevents TA1's data from being leaked to third parties other than CA1, improving the security of important data.
[0041] Figure 2 This is a schematic diagram of a system architecture provided for an embodiment of this application.
[0042] like Figure 2 As shown, the system architecture may include: a Rich Execution Environment (REE), a Trusted Execution Environment (TEE), and a kernel. The REE may include: CA1 (the client application on the REE side) and the TEE communication interface (teeosapi); the TEE may include: TA1 (trusted application), the TEE operating system (TEE OS), and the TEE OS may include an authentication module; the kernel may include the TEE OS driver. Furthermore:
[0043] REE and TEE are two separate runtime environments with independent hardware resources and operating systems. Hardware isolation technologies, such as TrustZone mechanisms, ensure the isolation of hardware resources between REE and TEE. Furthermore, virtualization technology can isolate the corresponding operating systems and applications between REE and TEE. Thus, the hardware and software resources accessible to TEE are separate from those of REE. TEE imposes very strict restrictions on the data and functions accessible to applications, ensuring its security level meets specific security requirements. Therefore, TEE can be considered a secure execution environment. REE, on the other hand, is a runtime environment separate from TEE and can be considered a less secure execution environment compared to TEE.
[0044] CA1 can be used to call the TEE communication interface through function F.
[0045] The TEE communication interface can be used to obtain the virtual address 1 of the function F that calls the TEE communication interface, and then send the virtual address 1 to the TEE OS driver in the kernel.
[0046] The TEE OS driver can receive virtual address 1 sent by the TEE communication interface. The TEE OS driver can obtain virtual address segment 2 used to store the program execution code of CA1. Then, the TEE OS driver can send virtual address 1 and virtual address segment 2 to the authentication module in the TEE OS.
[0047] After receiving virtual address 1 and virtual address segment 2, the authentication module can determine whether virtual address segment 2 includes virtual address 1. If virtual address segment 2 includes virtual address 1, the TEE allows CA1 to communicate with TA1 through the TEE communication interface; if virtual address segment 2 does not include virtual address 1, the TEE does not allow CA1 to communicate with TA1 through the TEE communication interface. The specific implementation process can be found in subsequent embodiments and will not be elaborated here.
[0048] In the embodiments of this application, Figure 2 The system architecture shown is for illustrative purposes only and does not constitute any limitation.
[0049] Combination Figure 2 , Figure 3 This is a schematic diagram of module interaction provided in an embodiment of this application.
[0050] like Figure 3 As shown, the interaction diagram of this module may include:
[0051] S301: CA1 calls the TEE communication interface based on function F (which can be called the first function) and sends an access request for CA1 to the TEE communication interface.
[0052] The access request from CA1 (which can be referred to as the first CA) can carry the identifiers of CA1 and TA1. This access request from CA1 can be used to trigger TA1 to perform a corresponding first operation. This first operation can include, but is not limited to: performing encryption / decryption operations on important data in CA1, storing CA1's private key / certificate, etc.
[0053] S302: The TEE communication interface can obtain the virtual address 1 (which can be called the first virtual address) of function F.
[0054] For example, the TEE communication interface can obtain the virtual address 1 of function F through a built-in function. For instance, the TEE communication interface can obtain the virtual address 1 of function F through the built-in function __builtin_return_address(LEVEL).
[0055] In one possible implementation, the REE may also include an address acquisition toolkit (address acquisition SDK) provided by the TEE OS. This address acquisition SDK can be used to obtain the virtual address 1 of function F. That is, when CA1 calls the TEE communication interface based on function F, the TEE communication interface can send the identifier of function F to the address acquisition SDK. Then, the address acquisition SDK can use the built-in function __builtin_return_address(LEVEL) to obtain the virtual address 1 of function F based on the identifier of function F. The TEE communication interface can also obtain the virtual address 1 of function F in other ways, and this application does not limit this.
[0056] S303: The TEE communication interface sends virtual address 1 to the TEE OS driver.
[0057] S304: The TEE communication interface sends an access request for CA1 to the TEE OS driver.
[0058] S305: The TEE OS driver obtains the virtual address segment 2 used to store the program execution code of CA1.
[0059] Specifically, the kernel can store a mapping record table (map) to record the virtual address segments of the program execution code of one or more CAs. Each CA's identifier has a one-to-one mapping relationship with its virtual address segment. For example, the identifier of CA1 can correspond to virtual address segment 2 (which can be called the first virtual address segment), meaning virtual address segment 2 is used to store the program execution code of CA1; the identifier of CA2 can correspond to virtual address segment 3, meaning virtual address segment 3 is used to store the program execution code of CA2, and so on. When the TEE OS driver receives an access request for CA1 and reads the identifier of CA1 carried in the access request, the TEE OS can look up the virtual address segment 2 corresponding to the identifier of CA1 from the mapping record table (map) based on that identifier. In other implementations, the TEE OS driver can also obtain the virtual address segment 2 used to store the program execution code of CA1 using methods different from the above example; this application does not impose any restrictions on this.
[0060] S306: The TEE OS driver sends an access request for CA1 to the authentication module in the TEE OS.
[0061] S307: The TEE OS driver sends virtual address 1 to the authentication module in the TEE OS.
[0062] S308: The TEE OS driver sends virtual address segment 2 to the authentication module in the TEE OS.
[0063] S309: The authentication module determines whether virtual address range 2 includes virtual address 1.
[0064] For example, if virtual address range 2 is 0001 to 0100 and virtual address 1 is 0010 to 0011, the authentication module can determine that virtual address range 2 includes virtual address 1; if virtual address range 2 is 0001 to 0100 and virtual address 1 is 00101 to 0111, the authentication module can determine that virtual address range 2 does not include virtual address 1.
[0065] S310: If virtual address segment 2 includes virtual address 1, then TEE OS sends an access request for CA1 to TA1 (which can be called the first TA).
[0066] Specifically, virtual address segment 2 includes virtual address 1, which is part of the program execution code of function F. In other words, when function F calls the TEE communication interface, the authentication module can determine that the subject calling the TEE communication interface is CA1. CA1 directly calls the TEE communication interface instead of calling the TEE communication interface through the lib file. In this process, the risk of TA1 data leakage due to attacks by third-party attackers is relatively small. Therefore, TEE OS sends an access request for CA1 to TA1 based on the TA1 identifier carried in the access request of CA1.
[0067] S311:TA1 performs the first operation based on the access request from CA1.
[0068] The explanation of the first operation can be found in the foregoing description, and will not be repeated here.
[0069] S312: Optional, if virtual address segment 2 does not include virtual address 1, then TEE OS prohibits sending access requests for CA1 to TA1.
[0070] Specifically, virtual address segment 2 does not include virtual address 1. This means that the program execution code of function F is not included in the program execution code of CA1. In other words, when function F calls the TEE communication interface, the authentication module can determine that the entity calling the TEE communication interface is not CA1, but another program besides CA1 (such as the aforementioned lib file). In this process, there is a risk of being attacked by malicious third-party attackers, leading to the leakage of TA1 data (e.g.,...). Figure 1B As shown in the embodiment, TEE OS therefore prohibits sending access requests for CA1 to TA1.
[0071] In the embodiments of this application, Figure 3 This is for illustrative purposes only and does not constitute any limitation on this application.
[0072] Figure 4 This is a schematic diagram illustrating the specific process of a communication method based on a trusted execution environment, as provided in an embodiment of this application.
[0073] like Figure 4 As shown, the specific process of this communication method based on a trusted execution environment may include:
[0074] S401: When an electronic device calls the TEE communication interface via CA1 based on function F and sends an access request for CA1 to the TEE communication interface, the electronic device obtains the virtual address 1 of function F. The TEE communication interface can be used for communication between CA1 and TA1.
[0075] For an explanation of this step, please refer to the aforementioned S301 to S304.
[0076] S402: The electronic device obtains the virtual address segment 2 used to store the program execution code of CA1.
[0077] For an explanation of this step, please refer to the aforementioned S305.
[0078] S403: The electronic device determines whether virtual address segment 2 includes virtual address 1.
[0079] For an explanation of this step, please refer to the aforementioned S306 to S309.
[0080] S404A: If virtual address segment 2 includes virtual address 1, the electronic device will send the access request CA1 sent through the TEE communication interface to TA1, triggering TA1 to perform the first operation based on the access request CA1.
[0081] For an explanation of this step, please refer to the aforementioned S310 to S311.
[0082] S404B: If virtual address segment 2 does not include virtual address 1, the electronic device will not send the access request CA1 sent through the TEE communication interface to TA1.
[0083] For an explanation of this step, please refer to the aforementioned S312.
[0084] It should be noted that, Figure 4 This is used only as an example to explain this application and does not constitute any limitation.
[0085] This embodiment also provides a chip coupled to a memory, which is used to read and execute computer programs or instructions stored in the memory to perform the methods in the above embodiments.
[0086] This embodiment also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the touch screen data processing method based on a trusted execution environment as described in the above embodiment.
[0087] This embodiment also provides a computer program product. The computer-readable storage medium stores program code. When the computer program product is run on a computer, it causes the computer to perform the above-mentioned related steps to realize the touch screen data processing method based on a trusted execution environment in the above embodiment.
[0088] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor can execute the computer execution instructions stored in the memory to cause the chip to execute the touch screen data processing method based on a trusted execution environment in the above method embodiments.
[0089] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.
[0090] This application does not specifically limit the structure of the execution subject of the method provided in this application embodiment. As long as a program containing the code of the method provided in this application embodiment can be run to perform touch screen data processing according to the method provided in this application embodiment, it is acceptable. For example, the execution subject of the method provided in this application embodiment can be an electronic device, or a functional module in an electronic device that can call and execute a program.
[0091] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.
[0092] In this application embodiment, electronic device 100 is the same as the electronic device in the foregoing embodiments. Electronic device 100 can be a mobile phone, tablet computer, PC, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), or other electronic devices. This application does not impose any restrictions on the specific type of electronic device 100.
[0093] like Figure 5 As shown, the electronic device 100 may include a processor 501, a memory 502, a wireless communication module 503 (optional), a display screen 504, a camera 505, an audio module 506 (optional), and a microphone 507 (optional). The processor 501, memory 502, wireless communication module 503, display screen 504, camera 505, audio module 506, and microphone 507 can be connected via a bus.
[0094] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may further include... Figure 5This may involve more or fewer components, or combining certain components, or splitting certain components, or different component arrangements. Figure 5 The components shown can be implemented in hardware, software, or a combination of both.
[0095] Processor 501 may include one or more processor units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.
[0096] The processor 501 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 501 is a cache memory. This memory can store instructions or data that the processor 501 has just used or that are used repeatedly. If the processor 501 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 501, and thus improves the efficiency of the system.
[0097] In some embodiments, the processor 501 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a USB interface, etc.
[0098] The memory 502 is coupled to the processor 501 and is used to store various software programs and / or multiple sets of instructions. In specific implementations, the memory 502 may include volatile memory, such as random access memory (RAM); it may also include non-volatile memory, such as ROM, flash memory, hard disk drive (HDD), or solid-state drive (SSD); the memory 502 may also include combinations of the above types of memory. The memory 502 may also store some program code so that the processor 501 can call the program code stored in the memory 502 to implement the implementation method of the present application embodiment in the electronic device 100. The memory 502 may store an operating system, such as uCOS, VxWorks, RTLinux, or other embedded operating systems.
[0099] The wireless communication module 503 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 503 can be one or more devices integrating at least one communication processing module. The wireless communication module 503 receives electromagnetic waves via an antenna, modulates and filters the electromagnetic wave signals, and sends the processed signal to the processor 501. The wireless communication module 503 can also receive signals to be transmitted from the processor 501, modulate and amplify them, and convert them into electromagnetic waves for radiation via the antenna. In some embodiments, the electronic device 100 can also communicate via the Bluetooth module in the wireless communication module 503 (… Figure 5 (not shown), WLAN module ( Figure 5(Not shown) The device transmits signals to detect or scan devices near electronic device 100 and establishes wireless communication connections with those devices to transmit data. The Bluetooth module can provide solutions for one or more Bluetooth communication methods, including basic rate / enhanced data rate (BR / EDR) or Bluetooth Low Energy (BLE), and the WLAN module can provide solutions for one or more WLAN communication methods, including Wi-Fi direct, Wi-Fi LAN, or Wi-Fi softAP.
[0100] The display screen 504 can be used to display images, videos, etc. The display screen 504 may include a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include one or N display screens 504, where N is a positive integer greater than 1.
[0101] Camera 505 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 505, where N is a positive integer greater than 1.
[0102] The audio module 506 can be used to convert digital audio information into analog audio signal output, and can also be used to convert analog audio input into digital audio signal. The audio module 506 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 506 can also be located in the processor 501, or some functional modules of the audio module 506 can be located in the processor 501.
[0103] Microphone 507, also known as a "microphone" or "voice transducer," is used to collect sound signals from the environment surrounding the electronic device. This sound signal is then converted into an electrical signal, which undergoes a series of processing steps, such as analog-to-digital conversion, to obtain a digital audio signal that can be processed by the processor 501 of the electronic device. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to the microphone 507, inputting the sound signal into the microphone 507. The electronic device 100 may have at least one microphone 507. In some embodiments, the electronic device 100 may have two microphones 507, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, the electronic device 100 may have three, four, or more microphones 507, enabling sound signal collection, noise reduction, sound source identification, and directional recording, among other functions.
[0104] It should be noted that, Figure 5 The electronic device 100 shown is merely an illustrative explanation of the hardware structure of the electronic device provided in this application and does not constitute a specific limitation on this application.
[0105] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".
[0106] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially 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, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.
[0107] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.
Claims
1. A communication method based on a trusted execution environment, characterized in that, Applied to electronic devices including Rich Execution Environments (REEs) and Trusted Execution Environments (TEEs), the method includes: When the first client application CA in the REE sends a first access request to the TEE communication interface through a first function, it obtains the first virtual address of the first function; wherein, the first access request is used to trigger the first TA to perform a first operation, and the first access request includes the identifier of the first CA; Based on the identifier of the first CA, the first virtual address segment corresponding to the identifier of the first CA is obtained from the mapping record table in the electronic device; wherein, the mapping record table is used to record the identifiers of one or more CAs and the virtual address segments corresponding to the identifiers of the one or more CAs, and the first virtual address segment is used to store the program execution code of the first CA; Determine whether the first virtual address range includes the first virtual address; If the first virtual address range includes the first virtual address, the first operation is performed in response to the first access request sent by the TEE communication interface through the first TA.
2. The method according to claim 1, characterized in that, The method further includes: If the first virtual address range does not include the first virtual address, the first access request shall not be sent to the first TA.
3. The method according to claim 1, characterized in that, The electronic device also includes a TEE OS driver; Obtaining the first virtual address of the first function specifically includes: The first virtual address of the first function is obtained through the TEE communication interface; After obtaining the first virtual address of the first function, the method further includes: The first virtual address is sent to the TEE OS driver through the TEE communication interface.
4. The method according to claim 3, characterized in that, Obtaining the first virtual address range corresponding to the identifier of the first CA specifically includes: The first virtual address segment corresponding to the identifier of the first CA is obtained through the TEE OS driver.
5. The method according to claim 4, characterized in that, The TEE in the electronic device includes an authentication module; Before determining whether the first virtual address range includes the first virtual address, the method further includes: The first virtual address and the first virtual address range are sent to the authentication module via the TEE OS driver. The step of determining whether the first virtual address range includes the first virtual address specifically includes: The authentication module determines whether the first virtual address range includes the first virtual address.
6. The method according to claim 1, characterized in that, The first operation includes one or more of the following: encrypting important data in CA1, decrypting important data in CA1, storing the private key of CA1, and storing the private key certificate of CA1.
7. An electronic device, characterized in that, The electronic device includes: one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories are used to store computer program code, the computer program code including computer instructions, and the one or more processors are used to execute the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-6.
8. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1-6.
9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-6.
10. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-6.