TEE-based secure payment method and electronic equipment

Abstract

The invention discloses a safety payment method based on TEE and electronic equipment. The method is applied to the electronic device, the electronic device comprises an REE, a secure element and a TEE, and the method comprises the steps that the REE receives a payment related request of an upper-layer application through an expansion interface transfer module; the TEE receives the payment-related request through the connection between the interface access control module and the expansion interface transfer module, and forwards the payment-related request to the trusted application program for execution after verifying the payment-related request; and when the trusted application calls the hardware permission, the TEE performs authentication through the secure element. The safe payment method is convenient, high in safety degree and high in transmission efficiency.

Description

Technical Field

[0001] This invention relates to the field of Android smart payment devices, and more particularly to a secure payment method and electronic device based on TEE. Background Technology

[0002] With the rapid expansion of smart POS terminals in overseas markets, devices need to simultaneously meet the universality requirements of GMS (Google Mobile Services Test Certification) certification and the security requirements of PCI PTS (Payment Card Industry PIN Transaction Security) certification. However, there is a conflict between the two certifications at the system modification level: the modifications made to the Android system, such as trimming and permission mechanisms, to meet the high security standards of PCI PTS often result in devices failing GMS certification.

[0003] While dual-CPU (Central Processing Unit) solutions or AVF (Android Virtualization Framework)-based virtualization solutions exist for dual authentication, the former is costly, and the latter is limited by system version and suffers from efficiency bottlenecks. Furthermore, traditional TEE solutions are limited by resource scale and are mostly used for auxiliary security operations, making it difficult to support complete payment transactions. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a secure payment method and electronic device based on TEE, which can simultaneously meet GMS certification and PCI PTS certification on a single hardware platform, taking into account system universality, payment security and cost efficiency.

[0005] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A secure payment method based on a TEE (Transfer Element) is applied to an electronic device, the electronic device including a REE (Receipt Element), a secure element, and a TEE, the method comprising: The REE receives payment-related requests from upper-layer applications through an extended interface relay module; The TEE receives the payment-related request through the connection between the interface access control module and the extended interface relay module, and after verifying the payment-related request, forwards the payment-related request to a trusted application for execution; The TEE authenticates the trusted application through the security element when the application invokes hardware permissions.

[0006] 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 various steps of the aforementioned secure payment method based on a TEE.

[0007] The beneficial effects of this invention are as follows: Based on the hardware isolation architecture of TEE and REE, the core payment function is deployed in a trusted application on the TEE side, effectively isolating the Android general system from the payment security environment. Through the coordinated scheduling of the extended interface relay module and the interface access control module, while maintaining the native characteristics of the Android system and meeting GMS certification requirements, the secure execution of payment transactions within the TEE is achieved, conforming to the PCI PTS certification standard. This system architecture does not rely on high-cost dual CPUs or high-version AVF frameworks. By directly driving the security chip security element within the TEE to complete the encryption process, it ensures the security of payment data and improves processing efficiency. Attached Figure Description

[0008] Figure 1 A flowchart illustrating the steps of a secure payment method based on TEE provided in this embodiment of the invention; Figure 2 This is a schematic diagram of the system architecture provided in an embodiment of the present invention; Figure 3 A flowchart illustrating how a trusted application for financial transactions reads data from a trusted application on a secure link, as provided in an embodiment of the present invention. Figure 4 A flowchart illustrating the process of a trusted application for financial transactions writing data to a trusted application for a secure link, as 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

[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] Table 1 Explanation of Professional Names

[0014] With the rapid expansion of smart POS terminals in overseas markets and the increasing diversification of business models, a single payment function can no longer meet market demands. Devices need to function simultaneously as smart terminals with general computing capabilities running a wide range of Android applications, and as highly secure payment devices processing financial transactions. This requires devices to simultaneously meet the universality and compatibility standards of GMS (Google Mobile Services Test Certification) certification, as well as the mandatory requirements of PCI PTS certification for payment transaction security.

[0015] In related technologies, most smart POS terminals require PCI PTS certification. However, PCI PTS certification places high security requirements on POS terminals. To meet these security requirements, many device manufacturers modify some native Android functions, such as cutting system components, modifying application authorization mechanisms, and adding custom application signature verification mechanisms. These modifications can lead to failure to pass GMS certification. Therefore, very few smart POS terminals pass both GMS and PCI PTS certifications simultaneously. Because smart POS functions were relatively simple in the past and they were widely used in the domestic market, there was little need for smart POS machines to pass both GMS and PCI PTS certifications simultaneously. However, as Android-based smart POS systems continue to expand overseas and their business models become more diverse, moving beyond being limited to just payment collection devices, the need for simultaneous GMS and PCI PTS certification has gradually emerged.

[0016] Currently, several technical methods exist to achieve simultaneous PCI PTS and GMS certification. One approach is a dual-CPU solution: using two general-purpose CPUs to run the general system and the payment system respectively. However, this significantly increases terminal costs. Another approach is based on AVF, which achieves simultaneous PCI PTS and GMS certification by separating Android's general capabilities and PCI PTS payment requirements in the REE and pVM regions respectively. However, AVF was introduced in Android 13 and is not compatible with many devices on the market that are earlier versions. Furthermore, the AVF approach involves multiple data interactions from REE to pVM to TEE, which also impacts efficiency.

[0017] Furthermore, while traditional TEE (Trusted Execution Environment)-based solutions can provide a high level of security through hardware isolation (such as ARMTrustZone), the limited resources of the TEE itself (memory, processing power) typically limit its use to auxiliary security operations (such as key storage and biometric verification), leaving the core payment business processes to be implemented on the REE side. This model struggles to support complete financial payment and device management operations, making it impossible to independently build a terminal system that simultaneously meets the PCI PTS financial security requirements and the GMS system's universality requirements. Therefore, few related technologies offer smart terminal solutions that can efficiently and cost-effectively achieve dual certification of GMS and PCI PTS.

[0018] Therefore, a security capability based on TEE hardware and system isolation is needed to extend the capabilities of Trusty OS, enabling it to support core financial payment and financial device management businesses. In addition, a TEE-based financial terminal system can be built by improving the interaction efficiency of the existing financial-related services in the REE layer, while the REE layer serves as a general application system, maintaining the general characteristics of the Android system, thereby building a solution that simultaneously supports PCI PTS+GMS authentication.

[0019] To address the aforementioned issues, this application provides a secure payment method based on a TEE, applicable to electronic devices, which include a REE, a security element, and a TEE.

[0020] The following details the secure payment method based on TEE in this invention, with reference to the appendix. Figure 1 This includes steps 110 to 130.

[0021] Step 110: The REE receives payment-related requests from upper-layer applications through the extended interface relay module. For example, when a user enters a transaction amount and selects card payment on the acquiring application interface, the application sends a request to the system to "open the magnetic card module". The extended interface relay module on the REE side, acting as a unified entry point, receives this request.

[0022] Step 120: The TEE receives payment-related requests through the connection between the interface access control module and the extended interface relay module, and forwards the payment-related requests to a trusted application for execution after verification. For example, the REE and TEE establish a connection through the system's native secure communication mechanism (such as the TEE Client API in Android). The interface access control module (API Hodor) receives payment-related requests from the extended interface relay module through this connection, verifies the payment-related requests, and forwards them to the trusted application for further operation after verification.

[0023] Step 130: When a trusted application invokes hardware permissions, the TEE performs authentication through a secure element. For example, after a trusted application receives an instruction to open the magnetic card module, it needs to drive the underlying security hardware to complete the operation, and the driver authentication is controlled by the secure element in the TEE kernel.

[0024] In this way, through the hardware isolation architecture between the TEE and REE, the core payment process runs in a hardware-isolated trusted environment, meeting the stringent requirements of PCI PTS certification for payment transaction security. Simultaneously, through the coordinated scheduling of the extended interface relay module and the interface access control module, the Android system can pass GMS certification smoothly without requiring deep customization that compromises its native integrity. This avoids performance losses caused by dependencies on higher-version systems and multiple interactions. Furthermore, through optimization of key technologies such as trusted application communication mechanisms within the TEE, direct driving of secure elements, and resource preloading, the complete payment business is efficiently supported with limited TEE resources.

[0025] In one embodiment of this application, step 110 includes step 111.

[0026] Step 111: The REE receives payment-related requests from the upper-layer application. These requests include the target interface identifier and call parameters. For example, after the user enters an amount and selects card payment, the acquiring application calls the extended interface relay module on the REE side to initiate a payment request. This request includes the target interface identifier and call parameters.

[0027] Step 120 includes step 121.

[0028] Step 121: The TEE receives payment-related requests and forwards them to a trusted application based on the target interface identifier. This instructs the trusted application to execute the payment-related request according to the call parameters. For example, after receiving a request containing the target interface identifier, the access control module determines that the interface is handled by a trusted application based on the mapping relationship. It then forwards the request and parameters to that trusted application. The trusted application, based on the received parameters (such as the transaction amount), executes subsequent business processes such as opening the magnetic card module, waiting for card retrieval, and reading the magnetic stripe data.

[0029] In this way, by placing the receipt and parsing of payment requests on the REE side, and the routing and execution of interfaces on the TEE side, a clear separation of business logic and secure execution environment is achieved. The interface access control module, as the scheduling hub on the TEE side, ensures that payment-related requests are accurately and securely routed to the corresponding trusted applications for execution based on their interface identifiers. This maintains the universality of the REE while guaranteeing the trusted and isolated execution of the payment business process within the TEE.

[0030] In one embodiment of this application, steps 140 and 141 are also included.

[0031] Step 140: The REE establishes a secure communication channel with the TEE. For example, during system startup or the first establishment of communication, a native secure communication link based on hardware isolation is established between the REE and the TEE for transmitting subsequent API request and response data.

[0032] Step 141: The REE encapsulates the payment-related request and call parameters through the extended interface relay module and transmits them to the TEE's interface access control module via a secure channel. For example, when the extended interface relay module receives a "open magnetic card module" request, it encapsulates the target interface identifier and call parameters (such as transaction information) into a data format recognizable by the TEE and sends it to the interface access control module through the aforementioned secure channel, ensuring that the request is not tampered with or stolen during transmission.

[0033] In this way, by establishing and using a native secure communication channel based on hardware isolation between the REE and TEE, the confidentiality and integrity of payment-related requests and parameters transmitted between the REE and TEE are ensured. This not only provides a reliable data source for the authentication and scheduling of subsequent interface access control modules, but also constitutes the basic communication guarantee for the entire system's security architecture, enabling sensitive business logic to be accurately triggered and executed in a secure execution environment.

[0034] In one embodiment of this application, steps 150 to 152 are also included.

[0035] Step 150: The TEE obtains the application permission list pre-stored in the TA-REE shared file area through the interface access control module. For example, when the interface access control module receives a payment request, the TEE reads the list of currently installed applications and their corresponding API permissions from the shared file area pre-stored in the TA-REE.

[0036] Step 151: The TEE checks the application permission list to see if the upper-layer application initiating the payment-related request has the permission to call trusted applications. For example, if the acquiring application initiates a request to call an interface, the interface access control module searches for the application's identifier in the application permission list and verifies whether its permission list contains the relevant request or corresponding device operation permissions.

[0037] Step 152: If yes, forward the payment-related request to the corresponding trusted application. For example, when the acquiring application is confirmed to have the authority to make the relevant request, the interface access control module determines that the interface should be handled by a trusted application based on the mapping table, then establishes an IPC communication channel with the trusted application and forwards the request data to the trusted application for execution.

[0038] In this way, by placing the storage and verification of application permissions under the unified management framework of the TEE and performing real-time authentication when business requests arrive, fine-grained and dynamic permission control for upper-layer applications calling extended interfaces is achieved. This mechanism not only ensures that only authorized applications can trigger payment transactions in the Trusted Execution Environment, but also avoids the security risks that may arise from permission management in the REE, further strengthening the overall security and compliance of the system.

[0039] In one embodiment of this application, steps 153 and 154 are included before step 150.

[0040] Step 153: After application installation, the TEE parses the signature information of all applications in the REE through the signature management application, and obtains access permissions for all application programming interfaces declared in the signature information. For example, when an acquiring application is installed on an electronic device, the signature management trusted application obtains the application's signature file through a secure REE-TEE communication mechanism and extracts predefined permission fields from it.

[0041] Step 154: The TEE associates the access permissions of all declared application programming interfaces with the corresponding applications as permission information and writes them into the application permission list, indicating that the application permission list belongs to the interface access control module. For example, signature management associates the application package name of the acquiring application with its declared permissions to form a permission record, and adds this record to the application permission list. This list is then written to the trusted application resource module, and its belonging trusted application is marked as "interface access control module," so that it can be preloaded into the TA-REE shared file area when the interface access control module starts.

[0042] In this way, a trusted application on the TEE side proactively parses and solidifies the application's interface permission declarations during the application installation phase, constructing a permission list generated and maintained in a secure environment. This not only ensures the authenticity and immutability of permission information but also provides an accurate data source for subsequent real-time and reliable permission verification by the interface access control module. This mechanism achieves end-to-end permission security management from application installation to interface calls, effectively preventing permission forgery or abuse, and is a key component in building an access control system that meets financial-grade security requirements.

[0043] In one embodiment of this application, step 130 includes steps 131 and 132.

[0044] Step 131: The TEE establishes a direct communication channel with the security element through the security element control driver implemented in the kernel. For example, when a trusted application needs to open the magnetic card module, it calls the security element driver adapted in the TEE kernel to directly establish a physical communication link with the security element, without needing to go through the REE side for data relay or channel creation.

[0045] Step 132: The TEE drives the secure element to complete encryption operations, key management, or transaction processing operations through a direct communication channel. For example, a trusted application encapsulates the "read magnetic stripe data" instruction into a data packet according to a predefined communication protocol and sends it to the secure element through this direct channel. After receiving the instruction, the secure element executes the corresponding hardware driver operations and security algorithm processing, and returns the read magnetic stripe ciphertext or processing result through the same channel.

[0046] In this way, by integrating the control driver of the secure element into the TEE kernel and establishing a direct communication channel between trusted applications and the secure element, secure and efficient driving of the secure hardware is achieved. This method not only eliminates the performance loss and security risks caused by the REE acting as a communication proxy in traditional solutions, but also ensures that core security operations such as key management and encryption are executed in a fully controlled and trusted link, further enhancing the overall security of payment transactions.

[0047] In one embodiment of this application, steps 160 and 161 are also included.

[0048] Step 160: When data is transmitted between different trusted applications within the TEE, if the size of the data to be transmitted exceeds the single transmission threshold, the sending trusted application will segment and encapsulate the data, and mark the data format, number of data segments, data segment number, and data application timing in the data header. For example, when a trusted application of a financial device needs to transmit an encrypted transaction log file exceeding 3600 bytes to a trusted application of a secure link, the financial device trusted application will divide the file into 3600-byte segments and add annotation information to each segment.

[0049] Step 161: The trusted application acting as the recipient processes the received data segments according to the timing of data application. For example, after receiving segmented data from the trusted application of the financial device, the secure link trusted application parses the annotation information and finds that it is "to be combined and applied after all segments are received", so it stores it in the cache queue; after receiving the last segment and having collected all segments, it reassembles them into a complete transaction log file in numerical order, and then performs the upload or decryption operation.

[0050] In this way, by designing and implementing a segmented encapsulation and dynamic parsing mechanism for large-scale data transmission between trusted applications within a TEE, the inherent limitation of single-transmission data volume in the TEE communication interface is effectively overcome. This method not only ensures the secure and reliable flow of large-volume business data (such as files, certificates, and batch transaction records) within the trusted environment, but also balances transmission efficiency and business logic integrity through intelligent data application timing control. This supports the closed-loop execution of complex financial payment transactions within the TEE and is a key communication optimization method for improving the overall system performance and functional completeness.

[0051] In one embodiment of this application, steps 170 and 173 are also included.

[0052] Step 170: The TEE receives a security status change request initiated by a privileged application through the interface access control module. The security status change request is verified and decrypted by the secure element. For example, after startup, the acquiring application initiates a request to set the device security status to "Secure". This request is first encrypted by the application backend using the working key and signed with the specified private key before being sent to the interface access control module.

[0053] Step 171: After successful verification, the TEE routes the security state change request to the trusted security management application via the interface access control module. For example, the TEE forwards the request to the secure element via the interface access control module; the secure element first decrypts the working key using the master key, then decrypts the request content using the working key and verifies the signature validity; after successful verification, the interface access control module sends the request to the trusted security management application according to the preset routing table.

[0054] Step 172: The TEE updates the security status identifier in the security management module based on the security status change request through the trusted security management application. For example, the trusted security management application parses the request content, confirms that the instruction is "Enter security control mode", and then updates the security status identifier stored internally from "Normal" to "Secure".

[0055] Step 173: REE's system modules query the current value of the security status identifier and execute corresponding security control operations according to preset policies. For example, REE's settings application or package management service periodically or in real time queries the security status identifier. If it finds that the value is "Secure", it automatically enables password verification for accessing the settings menu or prevents the launch of non-custom signed applications.

[0056] In this way, by constructing a complete security state management chain—initiated by a privileged application, rigorously verified by the security element, with state updates executed by trusted applications managed by the TEE side, and finally implemented and controlled in the REE's system modules—dynamic and reliable control of device security levels is achieved. This mechanism not only ensures that only strictly authenticated privileged applications can trigger changes in device security state, but also enables the system to adjust its system behavior and security policies in real time based on the TEE's security state identifier.

[0057] In one embodiment of this application, step 173 includes steps 174 to 176.

[0058] Step 174: When the security status indicator indicates a secure control state, the package management service in the REE prevents applications that have not passed custom signature verification from launching. For example, if the security status indicator is set to "Secure", when the package management service receives an application launch request, it will first query the list of custom signature verification results maintained by the signature management trusted application, and only allow applications that have passed verification in the list to launch.

[0059] Step 175: The Settings app in REE imposes access control on access to the Settings menu. For example, when the security status is "Secure," the Settings app will force users to enter a preset security password when they attempt to access the Settings app or a specific system settings page; otherwise, access will be denied.

[0060] Step 176: System services in REE disable the status bar pull-down or hide preset shortcut icons. For example, when a system service detects that the security status is "Secure", it sets the system status bar to be non-pull-down and hides or disables specific shortcut switches to prevent users from accidentally operating or being interfered with by unauthorized operations during secure payment.

[0061] In this way, by linking the security status identifiers uniformly managed by the TEE with the security behaviors of multiple core system components of the REE, a systematic and consistent security enhancement is achieved for the system under security control. These control strategies are precisely applied to key stages such as application startup, system settings access, and user interface interaction, effectively building a defense-in-depth system from the application layer to the system layer. While ensuring that the device meets the high-intensity security requirements of payment scenarios, it still maintains the original framework and compatibility of the system.

[0062] In summary, this application constructs a secure payment system based on a TEE (Technical Equipment Environment). This system reconstructs and migrates the entire financial payment process (including device drivers, transaction processing, key management, etc.) to a series of trusted applications within the TEE for execution, thereby meeting the stringent security requirements of PCI PTS certification. Through the collaboration of the extended interface relay module and the interface access control module, the system achieves unified reception, authentication, and scheduling of upper-layer payment requests, constructing a trusted call chain from application to hardware.

[0063] Specifically, the system extends capabilities based on Trusty OS, integrating a secure element control driver into the TEE kernel to enable direct communication between the TEE and the secure element, avoiding the performance loss and security risks associated with REE relay in traditional solutions. By designing a segmented transmission and dynamic resolution mechanism between trusted applications, the system overcomes the data size limitations of communication within the TEE, ensuring efficient flow of large-volume data services in a trusted environment. Simultaneously, the system introduces a security management module and a status identification mechanism, enabling the system to dynamically adjust system behaviors such as application startup, settings access, and interface interaction based on the unified security status on the TEE side, achieving system-level security enhancement without modifying the Android framework.

[0064] This method effectively resolves the conflict between security and universal authentication faced by smart terminals, providing an efficient, low-cost, and scalable system architecture solution for Android-based smart payment devices that simultaneously meets the requirements of GMS and PCI PTS authentication. This solution is not only applicable to various smart POS terminals but can also be extended to other smart IoT devices that require a balance between an open ecosystem and financial security, demonstrating broad application prospects and industrial value.

[0065] The following describes specific application examples of this application, taking the card payment scenario of an overseas smart POS terminal as an example, in conjunction with the attached... Figure 2 The system architecture shown includes the following steps: 1. When a cashier launches the acquiring application, the application initiates a security status change request, demanding that the device be switched to security control mode. This request is received by the REE-side extended interface relay module and transmitted to the TEE's interface access control module (API Hodor) via the REE-TEE secure communication channel. The interface access control module forwards the request to the secure element for signature verification and decryption. After successful verification, it routes the request to the trusted application for security management, updating the status flag in the security management module from "Normal" to "Secure". The REE-side system module then executes control policies based on this flag, such as hiding non-financial application icons and enabling password verification for settings access. This is equivalent to steps 170 to 173.

[0066] 2. The user enters the amount on the terminal and selects card payment. The acquiring application calls the "Open Magnetic Card Module" interface. The extended interface relay module on the REE side receives this request (including the interface identifier and transaction amount parameters), encapsulates it, and sends it to the interface access control module on the TEE side through a secure channel. The interface access control module first verifies whether the application has the calling permission from the application permission list pre-loaded in the TA-REE shared file area. After the verification is successful, it forwards the request to the trusted application of the financial device according to the mapping table. This is equivalent to steps 110, 111, 120, and 121.

[0067] 3. Upon receiving the request, the trusted application for the financial device establishes an SPI communication channel directly with the secure element through the secure element driver in the TEE kernel and sends a "start magnetic stripe card reader" command. The secure element driver hardware module prepares to read the card and waits for the card to be swiped. After the user swipes the card, the magnetic stripe data is encrypted by the secure element and directly returned to the trusted application for the financial device. This is equivalent to steps 131 and 132.

[0068] 4. If the trusted application for the financial device needs to synchronize transaction logs to the backend, and the log size exceeds the single transmission limit, the trusted application for the financial device will segment and encapsulate the data before sending it to the trusted application for the secure link, following a segmented transmission mechanism. Each data segment header contains information such as data format, segment number, segment ID, and application timing. The trusted application for the secure link receives and reassembles these segments sequentially, then uploads them to the backend server via a TLS secure channel. This is equivalent to steps 160 and 161.

[0069] 5. After the transaction is completed, the acquiring application can call the security status change interface again to restore the device to normal control mode. The security management TA updates the status identifier to "Normal", and the REE system module then removes all security restrictions, restoring the device to a general Android operating experience. This is equivalent to steps 172 to 176.

[0070] Through the above application examples, the present invention realizes a secure payment method based on TEE, and completes the entire secure payment process from secure environment preparation, payment request scheduling, business execution within TEE, direct driving of secure elements to system state management.

[0071] Please refer to Figure 3 The following describes in detail the process by which a trusted application for financial services reads data from a trusted application for a secure link in an application embodiment of this application.

[0072] When a trusted application for financial transactions needs to retrieve data from a trusted application on a secure link, the system first determines the relationship between the total size N of the data to be received and the amount of data that can be received in a single transaction, M (M = 3600 bytes). If N is greater than M, the segmented reading process is initiated. 1. The trusted application in the secure link segments the complete data into segments of a payload size of (3600 - HEADER_LEN), where HEADER_LEN is the length of the data header. The header contains control information such as data format, data transmission code (trading_code, including data identifier, total number of segments and segment number), data application timing, total data length (data_len_total=N), and the length of the current segment (buf_len). 2. The trusted application for financial services initiates the first read and receives the first piece of data, where buf_len = 3600 - HEADER_LEN; 3. The trusted application for financial business continues to initiate read requests and receive subsequent data segments, each with a buf_len of 3600 - HEADER_LEN; 4. When the last segment is read, the remaining data volume M1 is less than (3600-HEADER_LEN). At this time, buf_len=M1, and the transmission ends.

[0073] The receiver determines the processing method based on the "Data Application Timing" field in the data header: if it is for immediate application, it processes the data in segments; if complete data is required, it reassembles the data into complete data according to the segment numbers after all segments have been received before executing subsequent business logic. This process effectively solves the problem of single-transmission capacity limitations for large data transfers between trusted applications within a TEE.

[0074] Please refer to Figure 4 The following describes in detail the process of a trusted application for financial services writing data to a trusted application for a secure link in an application embodiment of this application.

[0075] When a trusted application for financial transactions needs to transmit data to a trusted application for a secure link, the system first determines the relationship between the total size N of the data to be sent and the amount of data that can be sent in a single transmission, M (M = 3600 bytes). If N is greater than (3600 - HEADER_LEN), where HEADER_LEN is the header length, then the segmented writing process is initiated. 1. The trusted application for financial business segments and encapsulates the data to be transmitted into segments according to the payload (3600-HEADER_LEN). The header of each data segment contains control information such as data format (data_format), data transmission code (trading_code, including data identifier, total number of segments and segment number), data application timing, total data length (data_len_total=N), and effective data length of this segment (buf_len); 2. The trusted application for financial business initiates the first write and sends the first piece of data, where buf_len=3600-HEADER_LEN. After receiving the data, the trusted application for the secure link returns an acknowledgment code of 0. 3. The trusted application for financial business continues to initiate write requests and send subsequent data segments. Each segment has a buf_len of 3600-HEADER_LEN. The trusted application for the secure link receives each segment and returns an acknowledgment. 4. When the last segment is written, the remaining data volume M1 is less than 3600 bytes. At this time, the effective data length buf_len = M1 - HEADER_LEN. After the trusted application in the secure link receives the last segment of data, it returns an acknowledgment code 0 to indicate the end of the transmission.

[0076] This segmented writing mechanism ensures reliable transmission of big data between trusted applications within the TEE, guarantees data integrity through header control information, and achieves transmission reliability through a segment-by-segment confirmation mechanism.

[0077] Please refer to Figure 5 The present invention also provides an electronic device 300, including a memory 301 and a processor 302, and a computer program stored on the memory 301 and running on the processor 302. When the processor 302 executes the computer program, it implements the various steps in the above-described secure payment method based on TEE.

[0078] 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.

[0079] 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 secure payment method based on TEE, characterized in that, Applied to an electronic device, the electronic device including a REE, a safety element, and a TEE, the method includes: The REE receives payment-related requests from upper-layer applications through an extended interface relay module; The TEE receives the payment-related request through the connection between the interface access control module and the extended interface relay module, and after verifying the payment-related request, forwards the payment-related request to a trusted application for execution; The TEE authenticates the trusted application through the security element when the application invokes hardware permissions.

2. The secure payment method based on TEE according to claim 1, characterized in that, The REE receives payment-related requests from upper-layer applications through an extended interface relay module, including: The REE receives payment-related requests from the upper-layer application, and the payment-related requests include the target interface identifier to be called and the calling parameters; The TEE receives the payment-related request through the interface access control module and the extended interface relay module, and after verifying the payment-related request, forwards the payment-related request to a trusted application for execution, including: The TEE receives the payment-related request and forwards it to a trusted application based on the target interface identifier, instructing the trusted application to execute the payment-related request according to the calling parameters.

3. The secure payment method based on TEE according to claim 1, characterized in that, Also includes: The REE establishes a secure communication channel with the TEE; The REE encapsulates the payment-related request and the calling parameters through the extended interface relay module, and then transmits them to the interface access control module of the TEE via the secure communication channel.

4. A secure payment method based on TEE according to claim 1, characterized in that, Also includes: The TEE obtains the application permission list pre-placed in the TA-REE shared file area through the interface access control module; The TEE queries the application permission list to see if the upper-layer application that initiated the payment-related request has the permission to call the trusted application. If so, the payment-related request will be forwarded to the corresponding trusted application.

5. A secure payment method based on TEE according to claim 4, characterized in that, Before obtaining the application permission list, the following is also included: After the application is installed, the TEE parses the signature information of all applications in the REE through the signature management application and obtains access permissions for all application programming interfaces declared in the signature information; The TEE associates the access permissions of all declared application programming interfaces with the corresponding applications as permission information and writes them into the application permission list, and identifies that the application permission list belongs to the interface access control module.

6. A secure payment method based on TEE according to claim 1, characterized in that, When the trusted application invokes hardware permissions, the TEE performs authentication through the security element, including: The TEE establishes a direct communication channel with the security element through a security element control driver implemented in the kernel. The TEE drives the security element to perform encryption operations, key management, or transaction processing operations through the direct communication channel.

7. A secure payment method based on TEE according to claim 1, characterized in that, Also includes: When different trusted applications transmit data in the TEE, if the size of the data to be transmitted exceeds the threshold for a single transmission, the trusted application that is the sender will encapsulate the data into segments and mark the data format, number of data segments, data segment number and data application timing in the data header. The trusted application, acting as the receiver, processes the received data segments according to the timing of the data application.

8. A secure payment method based on TEE according to claim 1, characterized in that, Also includes: The TEE receives a security status change request initiated by a privileged application through the interface access control module, wherein the security status change request is verified and decrypted by the security element. After successful verification, the TEE routes the security status change request to the trusted security management application through the interface access control module. The TEE updates the security status identifier in the security management module according to the security status change request through the trusted security management application. The REE system module queries the current value of the security status identifier and performs corresponding security control operations according to the preset strategy.

9. A secure payment method based on TEE according to claim 8, characterized in that, The step of performing corresponding security control operations according to the preset strategy includes: When the security status indicator indicates a security control status, the package management service in the REE prevents applications that have not passed custom signature verification from starting. The settings application in the REE applies access control to the settings menu; The system services in the REE prohibit the status bar from being pulled down or the preset shortcut icons from being hidden.

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 each step of the secure payment method based on TEE as described in any one of claims 1 to 9.

Images