A remote control method based on a trusted execution environment and an electronic device

Abstract

The application discloses a remote control method based on a trusted execution environment and electronic equipment. The method is applied to the electronic equipment, and the method comprises the following steps: receiving a control instruction from a remote server through a rich execution environment; forwarding the control instruction from the rich execution environment to a trusted execution environment through a security monitoring calling mechanism; the security monitoring calling mechanism is an environment switching and data transmission mechanism realized between the rich execution environment and the trusted execution environment based on a security monitoring calling instruction; checking and analyzing the control instruction in the trusted execution environment to obtain an analysis result, and calling a security driver in the trusted execution environment according to the analysis result, so that the security driver directly performs a control operation on a target external device to obtain an execution result. The application realizes deep binding of remote instructions and the trusted execution environment, the instruction plaintext only circulates in the trusted execution environment, malicious software attacks are isolated, the instructions are prevented from being tampered with or forged, and sensitive information is protected from being exposed.

Description

Technical Field

[0001] This invention relates to the field of payment terminal security control technology, and in particular to a remote control method and electronic device based on a trusted execution environment. Background Technology

[0002] In related technologies, remote control commands for payment terminals are typically received, parsed, and executed in a rich execution environment, which results in poor security. Commands are easily intercepted, tampered with, or forged, and sensitive data is at risk of leakage. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a remote control method and electronic device based on a trusted execution environment, thereby addressing the technical problems of poor security and easy leakage of sensitive data in remote control commands within a rich execution environment.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A remote control method based on a trusted execution environment, characterized in that it is applied to electronic devices, the method comprising: Receive control commands from a remote server through a rich execution environment; The control commands are forwarded from the rich execution environment to the trusted execution environment through a security monitoring call mechanism; the security monitoring call mechanism is an environment switching and data transmission mechanism between the rich execution environment and the trusted execution environment based on security monitoring call commands. The control instructions are verified and parsed in the trusted execution environment to obtain the parsing result. Based on the parsing result, the security driver in the trusted execution environment is called, and the security driver directly performs control operations on the target peripheral device to obtain the execution result.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the aforementioned remote control method based on a trusted execution environment.

[0006] The beneficial effects of this invention are as follows: By receiving control commands from a remote server through a rich execution environment (REE), remote acquisition of control commands is achieved; a secure monitoring and invocation mechanism forwards control commands from the REE to a trusted execution environment (TEX), enabling secure transmission of commands between isolated environments and preventing tampering or eavesdropping during transmission; the TEX verifies and parses the control commands to obtain the parsing result, and based on the parsing result, calls the corresponding secure driver in the TEX to perform control operations on the target peripheral device, obtaining the execution result. This ensures that plaintext commands are processed only within the TEX, and peripheral devices are accessed only by the secure driver in the TEX, avoiding the risk of sensitive information being exposed in the REE and the risk of peripheral driver hijacking. Thus, it solves the technical problems in related technologies such as the ease of command interception and tampering, the easy leakage of sensitive information, the untrustworthy execution link, and the risks of peripheral device control, achieving a unified approach to security, trustworthiness, and isolation in remote control. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a remote control method based on a trusted execution environment provided in this embodiment of the invention; Figure 2 An architecture diagram of a remote control system based on a trusted execution environment is provided for an embodiment of the present invention; Figure 3 An interactive flowchart of a remote control method based on a trusted execution environment provided in an embodiment of the present invention; Figure 4 A schematic diagram of a remote control device based on a trusted execution environment is provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0008] Definitions: Table 1

[0009] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0012] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0013] In related technologies, remote control commands for payment terminals are typically received, parsed, and executed in a rich execution environment (REE), which results in poor security.

[0014] For example, REE environments are vulnerable to malware attacks. Attackers can intercept, tamper with, or forge remote control commands through methods such as implanting malicious programs, memory scanning, and system hooking. Once a system is infected with malware, legitimate commands issued by the remote server may be maliciously modified and executed, or attackers may directly forge and inject false commands into the system, leading to the execution of illegal commands or the malicious modification of normal commands. This can result in serious consequences such as terminal configuration errors, sensitive data leaks, or abnormal peripheral device operation. When performing operations involving PIN input, key operations, or access to secure peripherals, sensitive data in these technologies must be processed and forwarded through the REE. Attackers can illegally obtain users' PIN codes, keys, and other sensitive information by listening to the communication interface between the REE and TEE, scanning system memory, or hijacking system services, posing a serious risk of information leakage. Furthermore, hardware devices such as printers and keyboards are usually controlled by REE drivers. After compromising the REE, attackers can hijack the drivers to steal or forge data, such as forging transaction vouchers or stealing user input, further expanding the attack surface.

[0015] Furthermore, in related technologies, instruction execution relies entirely on the REE. The entire remote control process, from instruction reception, parsing, execution to result return, is completed in the REE. Lacking a trusted execution root, it is impossible to verify the authenticity and integrity of the execution process. When the REE is compromised, the backend server cannot know whether the instruction has been maliciously tampered with or whether the execution result has been forged. The trustworthiness of the entire remote control chain cannot be guaranteed.

[0016] Furthermore, the relevant technologies lack effective signature verification of command sources, relying solely on REE layer authentication or simple password verification, and lack a command-level permission verification mechanism. Once an attacker gains access to the REE, they can issue arbitrary commands at will. The system cannot distinguish between legitimate administrator commands and commands forged by malicious programs, resulting in lax permission management and a significant security vulnerability of unauthorized execution. For example, an attacker can use a compromised REE to issue high-risk commands to the terminal, such as formatting the file system, modifying system configurations, or exporting sensitive data. The system lacks independent verification capabilities for each command and cannot effectively intercept such unauthorized operations.

[0017] To address the aforementioned problems, this application provides a remote control method and electronic device based on a trusted execution environment. This method achieves end-to-end trusted execution of remote control commands by constructing a secure forwarding mechanism between a rich execution environment and a trusted execution environment, and by performing instruction verification, parsing, and secure driver invocation within the trusted execution environment.

[0018] The following describes in detail a remote control method based on a trusted execution environment according to the present invention, with reference to the appendix. Figure 1 The method 100 includes steps 110 to 130.

[0019] Step 110: Receive control commands from the remote server through the rich execution environment. For example, in a POS terminal maintenance scenario, the backend server sends a log collection command to the POS terminal, and the rich execution environment of the POS terminal receives and encapsulates the command.

[0020] Step 120: Control commands are forwarded from the rich execution environment to the trusted execution environment via a secure monitoring call mechanism. This secure monitoring call mechanism is a mechanism for environment switching and data transmission between the rich and trusted execution environments based on secure monitoring call commands. For example, the rich execution environment triggers an environment switch via a secure monitoring call command, transmitting the encapsulated control commands to the trusted execution environment.

[0021] Step 130: In the Trusted Execution Environment (TEE), the control commands are verified and parsed to obtain the parsing results. Based on the parsing results, a secure driver in the TEE is invoked, which directly performs control operations on the target peripheral device to obtain the execution results. For example, the remote control trusted application in the TEE first verifies and parses the received control commands to determine that the command source is trustworthy and qualified for execution. Based on the parsing results, it selects the corresponding secure driver from multiple secure drivers in the TEE, which then directly performs control operations on the target peripheral device to obtain the execution results.

[0022] In this way, by constructing a secure forwarding mechanism between the rich execution environment and the trusted execution environment, and completing instruction verification, parsing, and secure driver invocation within the trusted execution environment, end-to-end trusted execution of remote control instructions is achieved. Unlike traditional methods that directly process instructions within the rich execution environment, this invention ensures that plaintext instructions circulate only within the trusted execution environment, effectively isolating malicious software attacks on the rich execution environment side and preventing instructions from being intercepted, tampered with, or forged. Simultaneously, it enables trusted access to secure peripherals; even if the rich execution environment is compromised, core control capabilities remain protected by the trusted execution environment. This makes this method suitable for remote operation and maintenance scenarios of payment terminals with stringent security and trustworthiness requirements, providing a solid technical foundation for achieving reliable, secure, and isolated remote control.

[0023] In one embodiment of this application, steps 140 and 150 are included after step 130.

[0024] Step 140: Encrypt the execution result to obtain the encrypted execution result, and then digitally sign the encrypted execution result. For example, in a trusted execution environment, a remote control trusted application calls an encryption engine to convert the execution result obtained after the security driver performs control operations from plaintext to ciphertext, and then uses a private key pre-agreed with the remote server to digitally sign the ciphertext result and append the current timestamp information.

[0025] Step 150: Return the execution result to the rich execution environment, and then forward the execution result to the remote server through the rich execution environment. For example, the encrypted and signed execution result is returned from the trusted execution environment to the rich execution environment through a secure monitoring call mechanism. After receiving the ciphertext result, the secure monitoring client in the rich execution environment does not decrypt or parse it, but directly forwards the ciphertext result to the remote server through the communication module.

[0026] In this way, the execution result is encrypted and signed in the trusted execution environment before being returned to the rich execution environment. The rich execution environment is only responsible for transmitting the ciphertext data and does not participate in the result generation or parsing process. The trusted execution environment encrypts the execution result and attaches a digital signature, so that the execution result is already in a ciphertext state and carries an authenticity identifier before leaving the trusted execution environment. The encrypted execution result is returned to the rich execution environment through a secure monitoring call mechanism. The rich execution environment cannot obtain the plaintext content of the execution result; it only acts as a pass-through channel to forward the ciphertext data to the remote server. Throughout the entire process, the rich execution environment neither participates in the generation of the execution result nor decrypts or parses it. Even if the rich execution environment is compromised by malware, attackers cannot steal the plaintext of the execution result from it.

[0027] In one embodiment of this application, step 110 includes steps 310 and 320.

[0028] Step 310: Deploy the security monitoring client in the rich execution environment. For example, install and run the security monitoring client program on the rich execution environment side of the POS terminal. This client is specifically designed to handle the reception and forwarding of remote control commands.

[0029] Step 320: The security monitoring client receives control commands and encapsulates them, maintaining the commands in encrypted form throughout the encapsulation process. For example, after receiving a control command from a remote server, the security monitoring client encapsulates it. During this process, the client only receives and encapsulates the command; it does not decrypt or parse it, ensuring the command remains encrypted. Since the security monitoring client lacks decryption capabilities, the plaintext command never appears during the rich execution environment processing. Even if the rich execution environment is attacked by malware, attackers cannot obtain the plaintext content of the control commands from it.

[0030] Specifically, the encapsulation process includes the following steps: The security monitoring client receives raw instruction data from a remote server. This data is an encrypted data packet containing ciphertext of the business instruction and its signature information; it obtains the corresponding session identifier for the current instruction to identify the processing context of the instruction and prevent replay attacks; without parsing the instruction content, it constructs metadata related to the instruction, including instruction length, timestamp, device identifier, etc.; it calculates an integrity check value for the "metadata + raw instruction ciphertext" as a whole to verify that the data has not been tampered with during transmission on the TEE side; it organizes the above information into a unified data packet format according to a predefined structure and writes it into a shared memory area for the TEE to read through SMC; and it sets a security flag field in the encapsulated data to indicate that the data is a protected instruction to be processed by the TEE, preventing misuse or illegal invocation.

[0031] Before encapsulation, the raw instruction data structure issued by the server contains ciphertext fields, signature fields, algorithm identifiers, and version information, which the REE cannot parse to understand the business instruction content. After encapsulation, the data structure generated by the REE includes header information (such as session identifier, device identifier, timestamp, payload length, and security flag), payload information (such as the original ciphertext and signature), and integrity check value. Through the above encapsulation process, the security monitoring client completes session binding, metadata construction, integrity protection, and security flag setting without touching the plaintext instruction, ensuring that the instruction has traceability, tamper-proof, and replay protection capabilities during transmission from the REE to the TEE.

[0032] In this way, control commands always exist in encrypted form within the rich execution environment. The security monitoring client is only responsible for receiving and encapsulating the commands and does not have the ability to decrypt them. Plaintext commands never appear during the entire rich execution environment processing. Even if the rich execution environment is attacked by malware, attackers cannot obtain the plaintext content of the control commands from the rich execution environment, thus effectively preventing the commands from being stolen or tampered with during the receiving and encapsulation stages, providing a prerequisite guarantee for subsequent secure processing in the trusted execution environment.

[0033] During the process of sending the encapsulated instructions to the TEE environment via SMC or equivalent driver interface, a session-based secure communication mechanism is preferably established, combined with shared memory to achieve data transmission. Specifically, this includes: During the initial communication, the REE-side security monitoring client initiates a session establishment request to the TEE side via the SMC interface. The TEE returns a unique session identifier and maintains the corresponding session context information internally. The REE side requests a shared memory region for data transmission and registers this memory with the TEE via the TEE client interface. The TEE side maps the shared memory to the secure world address space and sets access control. The REE side writes the encapsulated instruction data into the shared memory, along with the session identifier, timestamp, and sequence number information. The REE side triggers the TEE-side TA to read the data in the shared memory via an SMC call. The TA obtains the corresponding context based on the session identifier. Before processing the instruction, the TEE side verifies the session identifier, timestamp, and sequence number to prevent unauthorized calls or replay attacks. After instruction processing is complete, the TEE or REE side triggers a session release operation to release the corresponding session resources and shared memory mapping relationship. Through the aforementioned session establishment, shared memory mapping, session binding, verification, and resource reclamation mechanisms, it is ensured that control instructions are not eavesdropped on or tampered with during transmission from the rich execution environment to the trusted execution environment, effectively preventing replay attacks and illegal calls, and further guaranteeing the security of the instruction transmission process.

[0034] In one embodiment of this application, step 130 verifies and parses the control instructions in a trusted execution environment, including steps 410 and 420.

[0035] Step 410: The control command is digitally signed and verified by a trusted remote control application deployed in the Trusted Execution Environment (TEE). For example, after receiving a control command forwarded from the REE, the TA extracts the digital signature attached to the command and verifies the signature using the server's public key pre-stored in the TEE to confirm that the command indeed comes from a legitimate remote server and has not been tampered with during transmission. If the signature verification fails, it indicates that the source of the command is untrusted or the content has been modified. The TA immediately terminates the subsequent processing flow and generates a corresponding exception status code.

[0036] Step 420: If the verification passes, the remote control trusted application performs permission verification on the control command. If the verification passes, the control command is parsed to obtain the parsing result. For example, the TA verifies whether the command is qualified to execute based on the operation type in the command (such as log collection, parameter configuration, peripheral control, etc.) and the current terminal status. Specifically, this includes determining whether the operation type is within the authorized scope, whether the target peripheral is allowed to be accessed, and whether the command initiator has the corresponding permissions. If the permission verification fails, the TA also terminates the subsequent processing flow; if the verification passes, the TA continues to decrypt and parse the control command, extracting the operation type, parameter information, and target device identifier to obtain the parsing result.

[0037] In this way, the verification process performs dual checks on the legitimacy of the control commands' origin and their execution permissions. Digital signature verification ensures that the commands indeed originate from a trusted remote server and that their content has not been tampered with, effectively preventing man-in-the-middle attacks and command forgery. Permission verification ensures that the commands are qualified to be executed on the current terminal, preventing unauthorized operations and illegal command execution. The entire verification process is completed within a trusted execution environment (TEE), which cannot interfere with the verification results. Sensitive data such as public keys and permission configurations involved in the verification process are protected by a TEE memory isolation mechanism. If signature verification or permission verification fails, the TA immediately terminates processing and generates an exception status code. This exception status code is then encrypted and returned to the remote server through a secure channel, blocking illegal commands from entering the parsing and execution stages at the source, effectively ensuring the security of the remote control system.

[0038] In one embodiment of this application, step 130 verifies and parses the control instructions in a trusted execution environment to obtain the parsing result, including steps 430 to 450.

[0039] Step 430: Decrypt the verified control command in a trusted execution environment to obtain the plaintext command. For example, a trusted remote control application in the trusted execution environment decrypts the received ciphertext control command and restores it to its plaintext form.

[0040] Step 440 involves performing structural parsing on the plaintext command to extract the operation type, parameter information, and target device identifier. For example, a trusted remote control application performs structured parsing on the decrypted plaintext command to extract the operation type to be performed, the corresponding parameter information, and the target device identifier.

[0041] Step 450: All intermediate data generated during the parsing process is stored in the secure memory of the Trusted Execution Environment (TEE). For example, the remote control trusted application stores all intermediate data generated during the parsing process in a secure memory area within the TEE. This secure memory area is protected by the TEE's memory isolation mechanism and can only be accessed by the remote control trusted application within the TEE. No program in the REE can read or modify the data within it.

[0042] In this way, the entire process of decrypting and parsing control commands is completed within the Trusted Execution Environment (TEE). The plaintext commands appear only within the TEE and are never returned to the Rich Execution Environment (REE) through any channel. The operation type, parameter information, target device identifier, and all intermediate data generated during parsing are stored in the secure memory of the TEE, protected by its memory isolation mechanism. No program in the REE can access these resources. Therefore, even if the REE is compromised by malware, attackers cannot obtain the plaintext commands or the parsed sensitive data, effectively ensuring the security of control commands during the parsing phase.

[0043] In one embodiment of this application, step 130 calls the security driver corresponding to the parsing result in the trusted execution environment to perform control operations on the target peripheral device to obtain the execution result, including steps 510 to 550.

[0044] Step 510: Based on the operation type, parameter information, and target device identifier obtained from the parsing results, an internal execution context is generated. For example, the trusted remote control application packages the operation type (such as printing, input, encryption, etc.), corresponding parameter information (such as print content, input prompts, etc.), and target device identifier (such as printer, keyboard, encryption module, etc.) obtained in step 450 into a structured internal execution context, which serves as the unified data carrier for subsequent peripheral control operations.

[0045] Step 520: Configure the device access proxy module within the Trusted Execution Environment (TEE). For example, pre-configure a device access proxy module within the TEE. This module serves as the unified entry point for peripheral access, responsible for receiving control requests from trusted remote control applications and managing all security drivers within the TEE.

[0046] Step 530: The internal execution context is sent to the device access agent module. For example, the remote control trusted application sends the internal execution context generated in step 510 to the device access agent module through the communication mechanism within the trusted execution environment, and the agent module takes over the subsequent peripheral control process.

[0047] Step 540: The device access proxy module selects the target security driver corresponding to the target device identifier from multiple security drivers. For example, after receiving the internal execution context, the device access proxy module parses the target device identifier and then matches and selects the corresponding target security driver from multiple security drivers pre-registered in the trusted execution environment based on the identifier. For example, if the target device identifier is a printer, the printer security driver is selected.

[0048] Step 550: Invoke the security driver to perform control operations on the target peripheral. For example, the device access agent module invokes the target security driver selected in step 540. The security driver then performs specific control operations on the target peripheral based on the operation type and parameter information in the internal execution context, such as controlling the printer to print specified content, controlling the keyboard to obtain input data, or controlling the encryption module to perform encryption and decryption operations.

[0049] In this way, multiple secure drivers within the trusted execution environment are centrally managed and scheduled through the device access proxy module, enabling centralized control of peripheral access. Remote control trusted applications only need to send their internal execution context to the device access proxy module, without needing to know which secure driver to invoke or how. The device access proxy module automatically selects, matches, and invokes the driver based on the target device identifier. The entire control operation is executed within the trusted execution environment. The target peripheral is only controlled by the secure drivers within the trusted execution environment; the rich execution environment cannot directly access or manipulate the target peripheral. This avoids the risk of malware on the rich execution environment side hijacking drivers to steal data or forge operations, thus achieving trusted control of peripheral access.

[0050] In one embodiment of this application, step 550 includes step 560.

[0051] Step 560: Based on the operation type, the security driver controls the target peripheral to perform control operations matching the operation type. For example, after the security driver is invoked, it performs corresponding control actions on the target peripheral according to the operation type in the internal execution context, such as printing, input, display, or encryption. If the operation type is printing, the security driver controls the printer to output the specified content; if the operation type is input, the security driver controls the keyboard to obtain user input data; if the operation type is display, the security driver controls the display module to display the specified information; if the operation type is encryption, the security driver controls the encryption module to perform data encryption and decryption operations.

[0052] In this way, the secure driver performs differentiated control operations on the peripheral based on the operation type. A single secure driver can support multiple operation types without requiring separate driver configuration for each operation. A flexible mapping relationship is established between operation types and the secure driver. Remote control trusted applications only need to specify the operation type in the internal execution context, and the secure driver can automatically execute the corresponding control action. The entire control operation is completed within the trusted execution environment. The target peripheral is completely controlled by the secure driver within the trusted execution environment. The trusted execution environment cannot interfere with or intercept the peripheral's control process, thus ensuring the security and reliability of the peripheral control operation.

[0053] In one embodiment of this application, the method further includes steps 610 to 640.

[0054] Step 610: Detect any abnormal situations. For example, during the verification, parsing, or peripheral control operations of control instructions in a trusted execution environment, monitor in real time whether any abnormal situations such as verification failure, parsing failure, or device execution failure occur.

[0055] Step 620: When an abnormal situation is detected, obtain the abnormal type and corresponding abnormal information, and generate an abnormal status code and an abnormal log. For example, when a digital signature verification failure, instruction parsing format error, or target peripheral unavailability is detected, obtain the specific type and related information of the abnormality, and generate the corresponding abnormal status code and abnormal log record.

[0056] Step 630: Encrypt and encapsulate the exception status code, and return it to the remote server through a secure channel. For example, the generated exception status code is encrypted and encapsulated, and then returned to the remote server through a secure channel between the trusted execution environment and the remote server, enabling the server to know the occurrence and type of the exception.

[0057] Step 640: Record the exception log in the internal storage of the Trusted Execution Environment (TEE). For example, store the generated exception log in a secure storage area within the TEE, which can only be accessed by remotely controlled trusted applications within the TEE, and no program in the TEE can read or modify the log content therein.

[0058] In this way, a unified exception handling process is established to address various abnormal situations that may occur during the execution of control commands. Exception status codes are encrypted and encapsulated before being returned to the remote server in real time, enabling the server to promptly detect anomalies and take appropriate measures. Exception logs are persistently stored within the trusted execution environment, unaffected by the rich execution environment. Utilizing the memory isolation and access control mechanisms of the trusted execution environment, the confidentiality and integrity of the log data are ensured; even if the rich execution environment is compromised, the exception logs cannot be tampered with or deleted. This achieves reliable feedback of abnormal states and traceability of abnormal behaviors, providing comprehensive exception recording and auditing capabilities for the secure operation and maintenance of remote control systems.

[0059] In one embodiment of this application, step 120 forwards control instructions from the rich execution environment to the trusted execution environment through a security monitoring call mechanism, including steps 710 to 730.

[0060] Step 710: Establish a second secure channel between the rich execution environment and the trusted execution environment. For example, trigger an environment switch by calling a security monitoring command to establish a dedicated second secure channel (secure transmission channel) between the rich execution environment and the trusted execution environment for transmitting control commands and related data.

[0061] Step 720: Transmit control commands through the second secure channel and assign a session identifier to the control commands. For example, the encapsulated control commands are transmitted from the rich execution environment to the trusted execution environment through the established second secure channel, and a unique session identifier is assigned to the control commands, which are then associated and bound to the control commands.

[0062] Step 730: Verify the session identifier in the Trusted Execution Environment (TEE) and process the control command based on the verification result. For example, after receiving a control command, the TEE verifies the validity of the attached session identifier to determine whether the session identifier is legally allocated and has been used. If the verification passes, the subsequent processing flow continues; if the verification fails, the control command is rejected.

[0063] In this way, by establishing a dedicated secure transmission channel, it is ensured that control commands are not eavesdropped on or tampered with during transmission from the rich execution environment to the trusted execution environment. By assigning a unique session identifier to each control command and verifying it at the receiving end, replay attacks can be effectively identified and defended against; that is, attackers cannot achieve illegal purposes by repeatedly sending intercepted legitimate commands. Even if an attacker intercepts historically transmitted control commands, the trusted execution environment will recognize and reject the replay command because the session identifier has been used or expired. Thus, the security and replay prevention capabilities of control commands during the forwarding process are guaranteed.

[0064] Please refer to Figure 2 The following details the application embodiments of this application. This application can apply the above solution to scenarios requiring remote security control of POS terminals, especially in remote management fields with security risks, such as payment terminal maintenance, batch parameter configuration, and log collection. Taking a remote log collection scenario of a payment terminal as an example, the steps include: S201. The remote server sends a log collection command to the POS terminal. For example, when back-end maintenance personnel need to collect the operation logs of a POS terminal, they send a log collection command to the POS terminal through the remote server. This command is transmitted in encrypted form, containing the encrypted business command and its signature information. This is equivalent to step 110 above.

[0065] The S202 POS terminal's rich execution environment (REE) deploys a security monitoring client to receive and encapsulate the command, maintaining its encrypted state throughout the encapsulation process. Specifically, after receiving the control command from the remote server, the security monitoring client encapsulates it. During this process, the client only receives and encapsulates the command, without decrypting or parsing it, ensuring the command remains encrypted. The security monitoring client lacks command decryption capabilities, therefore the plaintext command never appears during the REE processing. The encapsulation process includes: obtaining the corresponding session identifier for the current command to identify its processing context and prevent replay attacks; constructing metadata related to the command, including command length, timestamp, and device identifier, without parsing the command content; calculating the integrity check value for the "metadata + original command ciphertext" as a whole; organizing the above information into a unified data packet format according to a predefined structure and writing it to a shared memory area; and setting a security flag field in the encapsulated data to indicate that the data is a protected command to be processed by the TEE.

[0066] The Rich Execution Environment (REE) establishes a secure transmission channel between itself and the Trusted Execution Environment (TEE) through a secure monitoring and invocation mechanism. This channel transmits control commands and assigns session identifiers to them. Upon receiving a command, the TEE verifies the validity of the session identifier. Specifically, during the initial communication, the REE-side security monitoring client initiates a session establishment request to the TEE via the SMC interface. The TEE returns a unique session identifier and maintains the corresponding session context information internally. The REE requests a shared memory region for data transmission and registers this memory with the TEE through the TEE client interface. The TEE maps the shared memory to the secure world address space and sets access control. The REE writes the encapsulated command data into the shared memory, along with the session identifier, timestamp, and sequence number. The REE triggers the TEE's TA to read the data from the shared memory via an SMC call. Before processing the command, the TEE verifies the session identifier, timestamp, and sequence number to prevent unauthorized invocation or replay attacks. This is equivalent to steps 310 to 330 above.

[0067] In the S203 and TEE trusted execution environments, after receiving control commands, the remote control trusted application performs digital signature verification and authorization checks on the commands. Upon receiving a control command forwarded from the REE, the TA extracts the digital signature attached to the command and verifies it using a pre-stored server public key to confirm that the command indeed originates from a legitimate remote server and has not been tampered with during transmission. If signature verification fails, it indicates that the command source is untrusted or its content has been modified, and the TA immediately terminates the subsequent processing flow. Based on the operation type in the command (such as log collection) and the current terminal status, the TA verifies whether the command is qualified to execute, such as determining whether the operation type is within the authorized scope and whether the target peripheral is allowed access. If authorization verification fails, the TA also terminates the subsequent processing flow.

[0068] If the verification passes, the encrypted control command is decrypted to obtain the plaintext command. The plaintext command is then parsed to extract the operation type, parameter information, and target device identifier. The plaintext command and parameter information are stored in the secure memory of the trusted execution environment. If the verification fails, an exception status code is generated, terminating the subsequent processing flow. The exception status code is then returned to the remote server as an exception result through a secure channel. This is equivalent to steps 410 to 450 above.

[0069] S204. The security driver in the TEE security driver layer directly performs control operations on the target peripheral (such as a printer, security keyboard, display, etc.) and obtains the execution result. Specifically, the TA generates an internal execution context based on the parsing result and sends it to the device access proxy module set in the TEE trusted execution environment. The device access proxy module selects the corresponding target security driver from multiple security drivers in the TEE security driver layer based on the target device identifier (e.g., if the target device identifier is a printer, the printer security driver is selected). The security driver is invoked, and the security driver performs specific control operations on the target peripheral according to the operation type, such as controlling the printer to output specified log content, controlling the security keyboard to obtain input data, or controlling the display to display specified information. The entire peripheral control process is completed within the TEE, and the REE cannot directly access or interfere with the target peripheral.

[0070] After execution, the Trusted Application (TA) in the TEE encrypts the execution result and adds a digital signature. The encrypted result is then returned to the REE rich execution environment, which forwards it to the remote server. Specifically, the TA calls the encryption engine to convert the plaintext execution result obtained after the security driver's execution control operation into ciphertext. It then uses a pre-agreed private key with the remote server to digitally sign the ciphertext result and adds a current timestamp. The encrypted and signed execution result is returned from the TEE environment to the REE environment via a security monitoring call mechanism. Upon receiving the ciphertext result, the security monitoring client in the REE environment does not decrypt or parse it, maintaining the ciphertext state, and directly forwards the ciphertext result to the remote server via the communication module. This is equivalent to steps 560, 140, and 150 above.

[0071] Through the above application examples, this invention realizes a remote control method based on a trusted execution environment, completing a closed-loop process from control command reception, secure forwarding, trusted verification and parsing, secure driver invocation to encrypted return of execution results. This solution effectively solves the problems of direct command processing in a rich execution environment in traditional solutions, such as easy interception and tampering of commands, easy leakage of sensitive information, untrustworthy execution links, and risks associated with peripheral device control. It provides secure, reliable, and isolated remote control assurance for the remote operation and maintenance of payment terminals.

[0072] Please refer to Figure 3 The following details the application examples of this application. This application's solution is applicable to scenarios involving remote security control of POS terminals, particularly in remote management areas with security risks, such as payment terminal maintenance, batch parameter configuration, and log collection. Taking remote log collection from a payment terminal as an example, the system executes the following complete process: S301. The remote server sends a remote command to the REE environment. For example, when backend maintenance personnel need to collect the operation logs of a POS terminal, they send a log collection command to the POS terminal through a remote server. After receiving the command, the REE environment encapsulates it without parsing it, keeping the command in encrypted form at all times. Specifically, a security monitoring client is deployed in the REE environment. This client is responsible for receiving the remote command and encapsulating it, but the client itself does not have the ability to decrypt the command. Therefore, the command always exists in encrypted form throughout the encapsulation process, and no plaintext command will appear in the REE environment. This is equivalent to steps 110, 310, and 320 above.

[0073] S302. The REE environment forwards the encapsulated ciphertext commands to the TEE environment via the SMC call mechanism. Specifically, the security monitoring client in the REE triggers an environment switch via a security monitoring call command, transmitting the encapsulated ciphertext commands to the TEE environment through shared memory and a secure channel. During transmission, a unique session identifier is assigned to each control command, and the session identifier is associated with the command to prevent subsequent replay attacks or unauthorized calls. This is equivalent to steps 710 to 730 above.

[0074] After receiving the instruction, the S303 and TEE environments perform signature verification and permission verification. If the verification passes, the instruction is parsed. Specifically, a remote control trusted application is deployed in the TEE environment. This trusted application first verifies the digital signature of the received control instruction to confirm whether the source of the instruction is trustworthy and whether the content has been tampered with. Then, it performs permission verification to determine whether the instruction has the conditions for execution. If the signature verification or permission verification fails, an exception status code is generated and the subsequent processing flow is terminated. The exception result is returned to the remote server through a secure channel. If the verification passes, the trusted application decrypts the encrypted instruction to obtain the plaintext instruction, performs structural parsing on the plaintext instruction, extracts the operation type (such as printing operation), parameter information (such as the log content to be printed), and target device identifier (such as printer), and stores the plaintext instruction and parameter information in the secure memory inside the TEE without returning it to the REE environment. This is equivalent to steps 410 to 450 above.

[0075] S304. The TEE environment calls the security driver based on the parsing result, and the security driver performs control operations on the hardware peripherals. After execution, the execution result is returned to the TEE environment. Specifically, the trusted application generates an internal execution context based on the parsed operation type, parameter information, and target device identifier. A device access proxy module is set up in the TEE environment, and the trusted application sends the internal execution context to this proxy module. The device access proxy module selects the corresponding target security driver from multiple security drivers in the TEE environment based on the target device identifier in the internal execution context, and then calls the security driver. The security driver performs specific control operations on the target peripherals according to the operation type, such as controlling the printer to output specified log content. After execution, the execution result is returned to the trusted application in the TEE environment. This is equivalent to steps 510 to 560 above.

[0076] S305 and the TEE environment encrypt and sign the execution results. Specifically, the trusted application encrypts the result data after execution, converting the plaintext result into ciphertext, and digitally signs the encrypted result and adds a timestamp to ensure the confidentiality and integrity of the execution result during subsequent transmission. This is equivalent to step 140 above.

[0077] S306. The TEE environment returns the encrypted and signed execution result to the REE environment. Upon receiving the encrypted execution result, the REE environment reports it to the remote server. Specifically, the encrypted and signed execution result is returned from the TEE environment to the REE environment via a security monitoring call mechanism. The security monitoring client in the REE environment receives the ciphertext result, does not decrypt or parse it, maintains the ciphertext state, and directly forwards the result data to the remote server via the communication module. The remote server, upon receiving the result, can verify its authenticity and integrity through the signature. This is equivalent to step 150 above.

[0078] Through the above application examples, this application achieves a complete remote control closed loop, from instruction issuance, REE secure encapsulation, SMC secure forwarding, TEE trusted verification and parsing, secure driver call execution, to encrypted result return. Throughout the entire process, plaintext instructions only appear within the TEE, with the REE serving merely as a transparent transmission channel for ciphertext instructions. Instruction transmission is protected against replay attacks through the SMC secure channel and session identifier; signature verification and authorization checks ensure the trustworthiness of the instruction source before execution; peripherals are directly controlled by the TEE secure driver, and the REE cannot interfere; execution results are encrypted and signed within the TEE before being returned, ensuring they are not stolen or tampered with. This solution fundamentally changes the traditional mode of REE directly processing instructions, effectively solving the problems of easily intercepted and tampered instructions, easily leaked sensitive information, untrusted execution links, and risks associated with peripheral control.

[0079] In one embodiment of this application, a remote control device 800 based on a trusted execution environment is also provided. This device is applied to electronic devices. Please refer to [reference needed]. Figure 4 ,include: The receiving module 801, set in a rich execution environment, is used to receive control commands from a remote server.

[0080] The forwarding module 802 is used to forward control commands from the rich execution environment to the trusted execution environment through a security monitoring call mechanism. The security monitoring call mechanism is an environment switching and data transmission mechanism between the rich execution environment and the trusted execution environment based on security monitoring call commands.

[0081] The execution module 803 is set up in the trusted execution environment. It is used to verify and parse the control commands to obtain the parsing results, and call the security driver in the trusted execution environment according to the parsing results. The security driver directly performs control operations on the target peripheral device and obtains the execution results.

[0082] Furthermore, the device 800 also includes: The result processing module 804 is set in a trusted execution environment to encrypt the execution result, obtain the encrypted execution result, and digitally sign the encrypted execution result.

[0083] Return module 805 is used to return the encrypted and signed execution result to the rich execution environment, and then forward the execution result to the remote server through the rich execution environment.

[0084] In this manner, the receiving module 801 securely receives encrypted instructions on the REE side, the forwarding module 802 transmits the session-bound encrypted instructions to the TEE through the SMC secure channel, the execution module 803 completes the instruction signature verification, permission verification, decryption and parsing, and secure driver invocation within the TEE, and the secure driver directly performs control operations on the target peripheral device. The result processing module 804 encrypts and signs the execution result within the TEE, and the return module 805 transmits the encrypted result to the remote server through the REE, realizing a complete closed loop from instruction reception, secure forwarding, trusted execution to encrypted result return. Throughout the process, the plaintext instruction only appears within the TEE, and the REE only serves as a transparent channel for encrypted instructions and encrypted results. The peripheral device is directly controlled by the TEE secure driver, and the REE cannot interfere. This effectively solves the problems of easy interception and tampering of instructions, easy leakage of sensitive information, untrustworthy execution links, and risks in peripheral device control in existing technologies, achieving a unified system of security, trustworthiness, and isolation in remote control.

[0085] Please refer to Figure 5The present invention also provides an electronic device 900, including a memory 901 and a processor 902, and a computer program stored on the memory 901 and running on the processor 902. When the processor 902 executes the computer program, it implements the various steps of the remote control method based on a trusted execution environment as described above.

[0086] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0087] In summary, this invention constructs a remote control method and electronic device based on a trusted execution environment. By deploying a security monitoring client in a rich execution environment, and deploying a trusted remote control application, a device access proxy module, and a security driver layer in the trusted execution environment, a full-link trusted execution system is constructed, encompassing reception and encapsulation, secure forwarding, trusted verification, parsing and execution, and encrypted return transmission.

[0088] During remote control, the system establishes a secure transmission channel through a secure monitoring and invocation mechanism, and assigns a session identifier to each control command to prevent replay attacks. Control commands undergo signature verification, permission verification, decryption, and structure parsing sequentially within the trusted execution environment. Plaintext commands and intermediate data are stored in secure memory and are not returned to the rich execution environment. During execution, the device access agent module selects the corresponding security driver based on the target device identifier and invokes the security driver to perform control operations on the target peripheral. This method differs from the traditional rich execution environment's direct command processing; through the isolation mechanism and multiple security checks of the trusted execution environment, it effectively prevents commands from being intercepted, tampered with, or forged. Furthermore, the system establishes a unified exception handling mechanism. Exception status codes are encrypted and encapsulated before being returned to the server, and exception logs are stored within the trusted execution environment as audit traceability. This method is suitable for remote operation and maintenance scenarios of payment terminals, solving the problems of easily intercepted and tampered commands, easily leaked sensitive information, untrusted execution links, and risks associated with peripheral control. The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A remote control method based on a trusted execution environment, characterized in that, Applied to electronic devices, the method includes: Receive control commands from a remote server through a rich execution environment; The control commands are forwarded from the rich execution environment to the trusted execution environment through a security monitoring call mechanism; the security monitoring call mechanism is an environment switching and data transmission mechanism between the rich execution environment and the trusted execution environment based on security monitoring call commands. The control instructions are verified and parsed in the trusted execution environment to obtain the parsing result. Based on the parsing result, the security driver in the trusted execution environment is called, and the security driver directly performs control operations on the target peripheral device to obtain the execution result.

2. The remote control method based on a trusted execution environment according to claim 1, characterized in that, The step of invoking the security driver in the trusted execution environment based on the parsing result, and having the security driver directly perform control operations on the target peripheral, includes: The execution result is encrypted to obtain the encrypted execution result, and the encrypted execution result is digitally signed. The execution result is returned to the rich execution environment, and then forwarded to the remote server through the rich execution environment.

3. The remote control method based on a trusted execution environment according to claim 1, characterized in that, The process of receiving control commands from a remote server through a rich execution environment includes: Deploy a security monitoring client in the rich execution environment; The security monitoring client receives the control command and encapsulates it, keeping the control command in encrypted form during the encapsulation process.

4. The remote control method based on a trusted execution environment according to claim 1, characterized in that, The process of verifying and parsing the control instructions in the trusted execution environment includes: The control commands are digitally signed and verified by a remote control trusted application deployed in the trusted execution environment. If the verification passes, the remote control trusted application performs permission verification on the control command. If the verification passes, the control command is parsed to obtain the parsing result.

5. The remote control method based on a trusted execution environment according to claim 1, characterized in that, The process of verifying and parsing the control instructions in the trusted execution environment to obtain the parsing result includes: In the trusted execution environment, the control command that has passed verification is decrypted to obtain the plaintext command. The plaintext instruction is parsed to extract the operation type, parameter information, and target device identifier; All intermediate data generated during the parsing process is stored in the secure memory of the trusted execution environment.

6. The remote control method based on a trusted execution environment according to claim 5, characterized in that, The step of invoking the security driver in the trusted execution environment based on the parsing result, and having the security driver directly perform control operations on the target peripheral to obtain the execution result, includes: Based on the operation type, parameter information, and target device identifier obtained from the parsing results, an internal execution context is generated; Configure the device access proxy module in the trusted execution environment; The internal execution context is sent to the device access proxy module; The device access proxy module selects the target security driver corresponding to the target device identifier from multiple security drivers. The security driver is invoked to perform control operations on the target peripheral device.

7. The remote control method based on a trusted execution environment according to claim 6, characterized in that, The step of invoking the security driver to perform control operations on the target peripheral device includes: According to the operation type, the target peripheral device is controlled by the security driver to perform the control operation that matches the operation type.

8. The remote control method based on a trusted execution environment according to claim 1, characterized in that, Also includes: Detect whether any abnormalities have occurred; When the above-mentioned abnormal situation is detected, the abnormal type and corresponding abnormal information are obtained, and an abnormal status code and an abnormal log are generated. The abnormal status code is encrypted and encapsulated, and then returned to the remote server through a secure channel; The exception logs are recorded in the internal storage of the trusted execution environment.

9. The remote control method based on a trusted execution environment according to claim 1, characterized in that, The step of forwarding the control instructions from the rich execution environment to the trusted execution environment through a security monitoring and invocation mechanism includes: Establish a second secure channel between the rich execution environment and the trusted execution environment; The control commands are transmitted through the second secure channel, and a session identifier is assigned to the control commands. The session identifier is verified in the trusted execution environment, and the control commands are processed based on the verification result.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the various steps of the remote control method based on a trusted execution environment as described in any one of claims 1 to 9.

Images