Payment method and electronic device

Abstract

The application provides a payment method and an electronic device. The payment service is divided into an identity authentication process and a payment process. The identity authentication process is executed by a second TEE to obtain an identity authentication result. The payment operation is performed by a first TEE according to the identity authentication result. Since the first TEE and the second TEE are isolated from each other, the risk of the payment process and the identity authentication process being cracked at the same time is reduced, and the security of the payment service is improved. The method comprises the following steps: a first TA receives a TUI display request, calls a TUI module to draw and display a first interface, acquires transaction information in response to a first operation of a user on the first interface, sends a first request to a second TA in response to an operation of the user confirming that the transaction information is correct, receives the first request, performs identity authentication, obtains an identity authentication result, sends the identity authentication result to the first TA, and performs payment operation according to the transaction information if the identity authentication result is successful.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a payment method and electronic device. Background Technology

[0002] With the rapid development of the mobile internet, the types and number of mobile applications are increasing. The security of business processes and stored data on mobile terminals is facing growing threats, especially in industries with high security requirements such as payment, office work, and copyright protection. However, the design of smart terminal operating systems prioritizes functionality while also being open and complex, resulting in numerous system vulnerabilities that allow malicious applications to emerge and threaten user data security.

[0003] Currently, in order to improve the security of payment services, application vendors complete the relevant processes of payment services in a trusted execution environment (TEE). However, this also has security vulnerabilities, and payment services are subject to security risks. Summary of the Invention

[0004] This application provides a payment method and electronic device that runs the payment process and identity authentication process of a payment business in two different TEEs, physically isolating the payment process and identity authentication process, thereby improving the security of the payment business.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, a payment method is provided, applied to an electronic device including a Rich Execution Environment (REE), a first Trusted Execution Environment (TEE), and a second TEE. The REE includes a Client Application (CA), the first TEE includes a First Trusted Application (TA) and a Trusted User Interface (TUI) module, and the second TEE includes a second TA. The method includes:

[0007] In response to detecting a user's payment operation, the CA sends a TUI display request to the first TA, the TUI display request carrying a TUI identifier; the first TA receives the TUI display request, calls the TUI module to draw and display a first interface, the first interface being the interface corresponding to the TUI identifier; in response to the user's first operation on the first interface, the first TA obtains transaction information; in response to the user's operation confirming that the transaction information is correct, the first TA sends a first request to the second TA; the second TA receives the first request, performs identity authentication, and obtains the identity authentication result; the second TA sends the identity authentication result to the first TA; if the identity authentication result is successful, the first TA performs the payment operation according to the transaction information.

[0008] As can be seen, this application divides the payment process into an identity authentication process and a payment process. First, the second TEE executes the identity authentication process to obtain the authentication result, and then the first TEE performs the payment operation based on this result. Furthermore, because the first and second TEEs are isolated from each other, the risk of both the payment process and the identity authentication process being maliciously compromised simultaneously is reduced, thus improving the security of the payment process.

[0009] In one possible design, the second TA receives the first request, performs identity authentication, and obtains the identity authentication result, including: in response to receiving the first request, the second TA acquires biometric data, which includes facial data or fingerprint data; the second TA compares the biometric data with a preset data template to obtain the identity authentication result.

[0010] In other words, the second TA can obtain a face or fingerprint and verify the user's identity based on the face or fingerprint.

[0011] In one possible design, the electronic device also includes a camera, and the second TEE also includes a first driver. The second TA acquires biometric data by: the second TA calling the camera through the first driver to collect facial data.

[0012] As can be seen, the second TA can collect facial data based on the first driver integrated into the second TEE. In other words, the process of collecting facial data is also isolated from the REE, which can avoid malicious attacks within the REE and effectively protect the user's privacy.

[0013] In one possible design, the electronic device also includes a fingerprint sensor, and the second TEE also includes a second driver. The second TA acquires biometric data by: the second TA calling the fingerprint sensor through the second driver to collect fingerprint data.

[0014] As can be seen, the second TA can collect fingerprint data according to the second driver integrated in the second TEE. That is, the process of collecting fingerprint data is also isolated from the REE, which can avoid malicious attacks in the REE and effectively protect the user's privacy.

[0015] In one possible design, the method further includes: in response to the user's confirmation that the transaction information is correct, the first TA calls the TUI module to draw and display a first identifier or a second identifier, wherein the first identifier is used to indicate that the electronic device is collecting fingerprint data, and the second identifier is used to indicate that the electronic device is collecting facial data. That is, the electronic device can display the first identifier when collecting the user's facial data, or display the second identifier when collecting the user's fingerprint data. By promptly informing the user of the electronic device's collection action, data collection efficiency can be improved.

[0016] In one possible design, the first interface includes a first option. In response to the user's confirmation that the transaction information is correct, the first TA sends a first request to the second TA, including: in response to the user's operation on the first option, the first TA displays a first pop-up window on the first interface, the first pop-up window including transaction information and a second option; in response to the user's operation on the second option, the first TA sends a first request to the second TA.

[0017] In one possible design, the first TA (Transaction Agent) performs a payment operation based on transaction information, including: the first TA generating a payment request based on the authentication result and transaction information; the first TA sending the payment request to the server; the server receiving the payment request and verifying the authentication result; if the authentication result is valid, the server performing the payment operation based on the transaction information. That is, after receiving the payment request, the server can verify the validity of the authentication result. For example, the server can determine whether the time difference between the time the authentication result was generated and the current time is greater than or equal to a preset time. If the time difference is greater than the preset time, the authentication result is valid, and the server performs the payment operation based on the transaction information. By limiting the validity period of the authentication result, malicious use of the leaked authentication result can be prevented to some extent.

[0018] In one possible design, the method further includes: the first TA (User Agent) calling the TUI (User Interface) module to draw and display the authentication result. By displaying the authentication result, the user can be promptly informed whether the authentication was successful, thus improving the efficiency of human-computer interaction.

[0019] Secondly, this application provides an electronic device that integrates an REE, a first TEE, and a second TEE. The REE includes a CA, the first TEE includes a first TA and a TUI module, and the second TEE includes a second TA. The electronic device includes: a wireless communication module, a memory, and one or more processors; the wireless communication module, the memory, and the processors are coupled.

[0020] The memory is used to store computer program code, which includes computer instructions; when the computer instructions are executed by the processor, the electronic device performs the payment method as described in any of the first aspects.

[0021] Thirdly, this application provides a computer-readable storage medium, including computer instructions;

[0022] When computer instructions are executed on an electronic device, the electronic device causes the electronic device to perform a payment method as described in any of the first aspects.

[0023] Fourthly, this application provides a chip system including one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The chip system can be applied to electronic devices including communication modules and memory. The interface circuits can read instructions stored in the memory of the electronic device and send the instructions to the processor. When the instructions are executed by the processor, the electronic device can perform a payment method as described in any of the first aspects.

[0024] Fifthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the payment method as described in any one of the first aspects.

[0025] It is understood that the electronic device described in the second aspect, the computer-readable storage medium described in the third aspect, the chip system described in the fourth aspect, and the computer program product described in the fifth aspect are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here. Attached Figure Description

[0026] Figure 1 A schematic diagram of the architecture of an electronic device provided in an embodiment of this application;

[0027] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0028] Figure 3 A flowchart of the payment method provided in the embodiments of this application;

[0029] Figure 4 Interface diagrams provided for embodiments of this application;

[0030] Figure 5 Interface diagrams provided for embodiments of this application;

[0031] Figure 6 Interface diagrams provided for embodiments of this application;

[0032] Figures 7A-7B Interface diagrams provided for embodiments of this application;

[0033] Figures 8A-8B Interface diagrams provided for embodiments of this application;

[0034] Figure 9 This is a schematic diagram of the chip system provided in an embodiment of this application. Detailed Implementation

[0035] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0036] The implementation of this embodiment will now be described in detail with reference to the accompanying drawings.

[0037] REE, or Rich Execution Environment, can also be called a Normal Execution Environment. REE generally refers to a runtime environment that lacks specific security features, such as the Android and iOS operating systems. REEs offer good openness and scalability but have relatively low security. It should be noted that, besides being called a "Rich Execution Environment," REEs can also be called "Untrusted Execution Environment," "Normal Execution Environment," "Insecure Execution Environment," etc., and this application's embodiments do not limit the specific terminology used.

[0038] TEE, or Trusted Execution Environment, also known as a secure side or secure zone, is an area that requires authorization to access. TEE and REE coexist in an electronic device. TEE, through hardware support, achieves isolation from the REE, possesses security capabilities, and can resist software attacks vulnerable to conventional REEs. TEE has its own operating space with defined strict protection measures; therefore, it has a higher level of security than the REE, protecting assets within the TEE, such as data and software, from software attacks and resisting specific types of security threats.

[0039] The TEE can be implemented in at least the following two ways:

[0040] 1. Implementing a TEE based on TrustZone technology. TrustZone technology isolates all system-on-chip (SoC) hardware and software resources, placing them in two separate zones (the normal world and the secure world). Components in the normal world (e.g., REE) cannot access resources in the secure world (e.g., the TEE), thus achieving isolation between the two worlds. In this scenario, the secure world can function as a TEE.

[0041] 2. Implementing a TEE based on virtualization technology. Virtualization technology refers to creating multiple isolated, complete computer systems (i.e., virtual machines (VMs)) on the same terminal device through a hypervisor (also known as a virtual machine monitor, VMM). Each VM has its own independent operating system and hardware resources. In this scenario, a virtual machine can serve as a TEE.

[0042] A hypervisor is an intermediate software layer that runs between the underlying physical server and the operating system, allowing multiple operating systems and applications to share hardware. Also known as a VMM, a hypervisor has access to all physical devices on an electronic device, including disks and memory. The hypervisor not only coordinates access to these hardware resources but also provides protection between virtual machines. When an electronic device starts and executes the hypervisor, it loads the operating systems of all virtual machine clients and allocates appropriate amounts of memory, network, and disk space to each virtual machine.

[0043] A trusted application (TA) is an application that runs within a TEE (Trusted Application Environment) and provides security services to other applications (such as client applications running outside the TEE), such as password input, transaction signature generation, and facial recognition.

[0044] A client application (CA) can refer to an application running within an REE, but in cases where a TA calls another TA, the TA that initiates the call can also act as a CA. A CA can invoke a TA through a client application programming interface (API) and instruct the TA to perform corresponding security operations.

[0045] Trusted User Interface (TUI) is a security feature provided by the TEE operating system (OS). It provides a trusted interface for each TA running in the TEE to interact securely with the user, ensuring that sensitive data exchanged between the TA and the user is protected from attacks by other applications or malware (e.g., malicious screenshots), thereby improving business security.

[0046] This application provides a payment method applicable to electronic devices deployed with multiple TEEs (e.g., a first TEE1 and a second TEE). In this method, the payment process includes a payment procedure and an authentication procedure. The first TEE executes the payment procedure, and the second TEE executes the authentication procedure. Therefore, this application achieves physical isolation between the payment procedure and the authentication procedure by constructing a first TEE1 and a second TEE, reducing the risk of both procedures being maliciously compromised simultaneously and thus improving the security of the payment service.

[0047] Please see Figure 1 This is a schematic diagram of the architecture of an electronic device provided in this application.

[0048] like Figure 1 As shown, the electronic device 100 includes hardware devices and three isolated operating environments running on the hardware devices: REE, TEE1, and TEE2. Each of the three operating environments has independent hardware resources and an operating system. In some implementations, REE and TEE2 can be isolated using hardware isolation techniques, such as... The Trust Zone mechanism can isolate the hardware resources of REE and TEE2. REE and TEE1 can also be isolated using virtualization technology, such as a hypervisor mechanism. This ensures that the hardware and software resources accessible to TEE1, TEE2, and REE are separate. Of course, in other implementations, REE and TEE2 can also be isolated using virtualization technology. Optionally, REE and TEE2 can also be isolated using hardware isolation technology. In other words, this application does not limit the isolation technology used between REE and TEE2, or between REE and TEE1.

[0049] The operating systems in REE, TEE1, and TEE2 are capable of controlling and accessing the hardware devices of electronic device 100, and may include, for example, [other components]. Trust Zone Firmware, camera, fingerprint sensor, etc. In the above architecture, the REE can interact with TEE1 through the hypervisor, and the REE can... Trust Zone Firmware interacts with TEE2; TEE1 and TEE2 can communicate via the hypervisor and... Interact with Trust Zone Firmware.

[0050] In TEE1 and TEE2, there can be one or more TAs. Figure 1(This example uses TEE1, which includes the payment TA, and TEE2, which includes the identity authentication TA.) TEE1 also includes a TUI module, which the payment TA can call to draw its TUI. Within an REE, there can be one or more CAs (Certificates of Account). Figure 2 (This example only uses payment CAs as an example.) The interface of a CA can be called a User Interface (UI). For example, a payment CA can be an application such as Honor Pay, a bank client, a mobile security token application, an electronic ID card, a mobile POS, or other applications that involve the input of sensitive information such as account numbers and passwords; the TA is the security application corresponding to the CA, used for inputting and verifying the sensitive information involved in the CA.

[0051] In the REE (Reliable Internet Service Provider), the Payment CA (Certified Administrative User) can send a TUI (Trusted User Interface) access request to the Payment TA (Transaction TA). Upon receiving a TUI access request, the Payment TA can invoke the TUI module to draw and display the Trusted User Interface, and receive sensitive information or actions input by the user on that Trusted User Interface through the TUI module. The Payment TA can also send an authentication request to the Authentication TA (Transaction Authenticator) in response to user actions on the Trusted User Interface. Alternatively, the CA can directly send this authentication request to the Authentication TA. Upon receiving this authentication request, the Authentication TA can execute the authentication process.

[0052] The payment CA can call the payment TA through the hypervisor, enabling the payment CA to access, sign, and confirm the payment TA, as well as display the payment TA's TUI on the screen. The payment TA can switch the hardware device's operating mode through the driver (e.g., exiting non-secure mode and entering secure mode), and call the corresponding authentication TA to access, sign, and confirm the authentication TA.

[0053] It should be noted that TEE1 can also be called the first TEE, TEE2 can also be called the second TEE, the payment TA can also be called the first TA, and the identity authentication TA can also be called the second TA.

[0054] It should be noted that the electronic device involved in the embodiments of this application can be any electronic device that deploys multiple TEEs, such as portable computers (e.g., mobile phones), tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) / virtual reality (VR) devices, media players, smart locks, and other devices. The embodiments of this application do not impose any special limitations on the specific form of this electronic device.

[0055] In this embodiment of the application, a mobile phone is used as an example to illustrate the structure of the electronic device provided in this embodiment. Please refer to... Figure 2 This is a circuit diagram of a mobile phone provided in an embodiment of this application.

[0056] like Figure 2 As shown, the mobile phone 200 may include: a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, a sensor module 280, buttons 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a subscriber identification module (SIM) card interface 295, etc.

[0057] The aforementioned sensor module 280 may include sensors such as pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, and bone conduction sensors.

[0058] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the mobile phone 200. In other embodiments, the mobile phone 200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0059] Processor 210 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0060] The controller can serve as the nerve center and command center of the mobile phone 200. Based on the instruction operation code and timing signals, the controller can generate operation control signals to control the fetching and execution of instructions.

[0061] The processor 210 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. This memory can store instructions or data that the processor 210 has just used or that are used repeatedly. If the processor 210 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 210, and thus improves the efficiency of the system.

[0062] In some embodiments, the processor 210 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0063] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the mobile phone 200. In other embodiments, the mobile phone 200 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0064] The charging management module 240 receives charging input from the charger. The charger can be a wireless charger or a wired charger. While charging the battery 242, the charging management module 240 can also supply power to the terminal device via the power management module 241.

[0065] The power management module 241 connects the battery 242, the charging management module 240, and the processor 210. The power management module 241 receives input from the battery 242 and / or the charging management module 240, and supplies power to the processor 210, internal memory 221, external memory, display 294, camera 293, and wireless communication module 260, etc. In some embodiments, the power management module 241 and the charging management module 240 may also be housed in the same device.

[0066] The wireless communication function of mobile phone 200 can be implemented through antenna 1, antenna 2, mobile communication module 250, wireless communication module 260, modem processor, and baseband processor. In some embodiments, antenna 1 of mobile phone 200 is coupled to mobile communication module 250, and antenna 2 is coupled to wireless communication module 260, enabling mobile phone 200 to communicate with networks and other devices through wireless communication technology.

[0067] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in mobile phone 200 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0068] The mobile communication module 250 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G for mobile phones 200. The mobile communication module 250 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 250 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation.

[0069] The mobile communication module 250 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via the antenna 1. In some embodiments, at least some functional modules of the mobile communication module 250 can be housed in the processor 210. In some embodiments, at least some functional modules of the mobile communication module 250 and at least some modules of the processor 210 can be housed in the same device.

[0070] The wireless communication module 260 can provide solutions for wireless communication applications on the mobile phone 200, including WLAN (such as wireless fidelity, Wi-Fi), Bluetooth, Global Navigation Satellite System (GNSS), frequency modulation (FM), near-field communication (NFC), and infrared (IR) technologies.

[0071] The wireless communication module 260 can be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 210. The wireless communication module 260 can also receive signals to be transmitted from processor 210, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0072] The mobile phone 200 implements its display function through a GPU, a display screen 294, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 210 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0073] The display screen 294 is used to display images, videos, etc. The display screen 294 includes a display panel.

[0074] The mobile phone 200 can perform shooting functions through an ISP, camera 293, video codec, GPU, display 294, and application processor. The ISP is used to process data fed back by the camera 293. The camera 293 is used to capture still images or videos. In some embodiments, the mobile phone 200 may include one or N cameras 293, where N is a positive integer greater than 1.

[0075] The external storage interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the mobile phone 200. The external memory card communicates with the processor 210 through the external storage interface 220 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0076] Internal memory 221 can be used to store computer executable program code, which includes instructions. Processor 210 executes various functional applications and data processing of mobile phone 200 by running the instructions stored in internal memory 221. For example, in this embodiment, processor 210 can execute instructions stored in internal memory 221, which may include a program storage area and a data storage area.

[0077] The program storage area can store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.). The data storage area can store data created during the use of the mobile phone 200 (such as audio data, phonebook, etc.). In addition, the internal memory 221 can include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0078] The mobile phone 200 can perform audio functions, such as music playback and recording, through an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, and an application processor.

[0079] Buttons 290 include a power button, volume buttons, etc. Buttons 290 can be mechanical buttons or touch buttons. Motor 291 can generate vibration alerts. Motor 291 can be used for incoming call vibration alerts or for touch vibration feedback. Indicator 292 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 295 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 295 to achieve contact and separation with the mobile phone 200. The mobile phone 200 can support one or N SIM card interfaces, where N is a positive integer greater than 1. SIM card interface 295 can support Nano SIM cards, Micro SIM cards, SIM cards, etc.

[0080] Next, we will combine Figure 1 The system architecture shown provides a detailed description of the payment method provided in this application's embodiments. Please refer to... Figure 3This is a flowchart of a payment method provided in an embodiment of this application. The payment method may include the following steps.

[0081] S301, Payment CA sends a TUI display request to Payment TA.

[0082] The payment CA can be an application within the REE that has payment functionality, such as... Applications such as wallets and bank clients. This payment TA is a secure application within TEE1 that provides payment services to payment CAs.

[0083] When a user's payment action is detected, the payment CA can send a TUI display request to the payment TA. The user's payment action may include clicking on a specific control on the application interface provided by the payment CA. For example, taking a bank client as an example, the process of the payment CA sending a TUI display request to the payment TA is explained. Figure 4 As shown, the mobile phone can display the bank's client interface 401, which includes a transfer option 402. When the user clicks on the transfer option 402, the payment CA can send a TUI display request to the payment TA.

[0084] A TUI display request can carry the identifier of the desired TUI (also known as a TUI identifier), which indicates the specific interface requested by the payment TA. There is a correspondence between the TUI identifier and the TUI; upon receiving the TUI display request, the payment TA can locate the corresponding TUI interface based on the TUI identifier carried in the request.

[0085] It should be noted that before the payment CA sends a TUI display request to the payment TA, the payment CA can first send a session request to the payment TA via the hypervisor. This session request includes the payment TA's universally unique identifier (UUID), which can be used to create a session with the payment TA. In response to receiving this session request, the payment TA creates a session based on the payment CA's UUID and sends a session creation result to the payment CA. This result indicates whether the session was successfully created. For example, the session creation result may include a session identifier. If the session identifier is the first parameter (e.g., 1), it indicates that the session was successfully created; if the session identifier is the second parameter (e.g., 0), it indicates that the session was not created. In an optional implementation, the payment CA can use the TEEC_OpenSession function to create a session, and the payment TA can use the TA_CreateEntryPoint function to create a session.

[0086] Once a session is successfully created, the payment CA can send TUI display requests and other requests to the payment TA through that session.

[0087] S302, in response to receiving the TUI display request, the payment TA calls the TUI module to draw and display the payment interface.

[0088] The payment TA can read the TUI identifier carried in the TUI display request, find the corresponding TUI interface based on the TUI identifier, and call the TUI module to draw the TUI (i.e., the payment interface) corresponding to that TUI identifier. For example, the payment interface could be like this: Figure 5 The interface 403 shown may include page content such as payee name, payee account, bank, and amount. This payment interface allows users to input transaction information, which may include specific details of options such as bank name, payee name, payee account, and amount.

[0089] That is, after the electronic device opens the payment CA, the electronic device can display the user interface of the payment CA (e.g., Figure 4 As shown in interface 401, when a user's payment operation is detected (e.g., the user clicking the transfer option 402), the payment CA sends a TUI display request to the payment TA, causing the payment TA to call the TUI module to draw the payment interface (e.g., ... Figure 5 The interface shown is 403, and it is displayed on the screen of the electronic device. In this way, the user can enter transaction information within TEE1 (i.e., the secure environment), and non-secure applications on the REE side (such as software capable of malicious screenshots) cannot steal the sensitive information entered by the user in the payment interface, thus preventing the leakage of sensitive information and improving the security of user input operations. It should be noted that the above payment interface can also be referred to as the first interface.

[0090] S303, in response to the user's input on the payment interface, the payment TA obtains the transaction information.

[0091] Understandably, the payment interface may include a virtual keyboard (also known as a secure keyboard). Upon detecting user interaction with the virtual keyboard (also known as the first interaction), the payment TA can obtain transaction information. Specifically, during the user's input process using the virtual keyboard, the TEE1 can record the order in which the user touches the virtual keys and the position of each virtual key. Then, it finds the corresponding virtual key at each key position, sorts the virtual keys according to the order in which the user touched them, and combines this information with input method rules to obtain transaction information. Because the virtual keyboard is deployed within the TEE1, the entire input process is executed within the TEE1, preventing the leakage of sensitive user input information and improving the security of user input operations.

[0092] It should be noted that the virtual keyboard may include a virtual Pinyin keyboard, a virtual numeric keyboard, etc., and the virtual Pinyin keyboard and the virtual numeric keyboard can be switched between each other.

[0093] The specific details of the transaction information can be found in the description in S302, and will not be repeated here. For example, such as... Figure 5 As shown, the transaction information can be: "Payee: Xiaoyi, Account Number: 6214********1005, Bank: XX Bank, Transfer Amount: ¥100,000.00, Payment Card: XX Bank (0023)".

[0094] S304, in response to the user's confirmation operation on the payment interface, the payment TA calls the TUI module to draw and display the payment pop-up window.

[0095] Understandably, the user's confirmation action on the payment interface can also be interpreted as the user confirming that the transaction information is correct. For example, such as... Figure 5 As shown, the payment interface 403 may also include a "Next" option 404. When the user's click on the "Next" option 404 (also referred to as the first option) is detected, as follows: Figure 6 As shown, the electronic device can display a payment pop-up window 405 on the payment interface 403, allowing the user to confirm whether the transaction information is correct. The payment pop-up window 405 may include transaction information 405a, a confirmation option 405b (also referred to as a second option), and a cancellation option. If the user confirms that the transaction information 405a is correct, they can click the confirmation option 405b; if the user finds that the transaction information 405a is incorrect, they can click the cancellation option.

[0096] Understandably, this payment pop-up 405 is also drawn and displayed by the payment TA calling the TUI module, which has high security and can prevent the leakage of transaction information.

[0097] S305, in response to the user's confirmation action on the payment pop-up, the payment TA sends an identity authentication request to the identity authentication TA.

[0098] The user's confirmation action on the payment pop-up can be achieved by clicking or touching the confirmation option 405b (also known as the second option) on the payment pop-up 405. In one possible design, before sending an authentication request to the authentication TA, the payment TA can send a session request to the authentication TA via the hypervisor and hardware device. This session request includes the authentication TA's UUID, used to create a session with the authentication TA. The process of creating a session between the authentication TA and the payment TA is detailed in S301, and will not be repeated here. After successfully creating the session, the payment TA can send an authentication request to the authentication TA through this session. The authentication TA runs within TEE2.

[0099] It should be noted that the aforementioned identity authentication request can also be referred to as the first request.

[0100] S306, In response to receiving an authentication request, the Authenticator (TA) obtains biometric data.

[0101] Biometric data refers to biometric information that can be used to identify a user, such as fingerprint or facial data. Specifically, the payment CA supports fingerprint payment and facial payment. Fingerprint payment verifies a user's identity via fingerprint and makes payment after successful authentication. Facial payment verifies a user's identity via facial recognition and makes payment after successful authentication. In response to user actions, the payment CA can enable fingerprint payment, facial payment, or both simultaneously. If the payment CA only enables fingerprint payment, the biometric data includes fingerprint data (i.e., fingerprint data can be obtained by the identity authentication TA); if the payment CA only enables facial payment, the biometric data includes facial data (i.e., facial data can be obtained by the identity authentication TA); if the payment CA enables both fingerprint and facial payment, the payment CA can determine the payment method according to a preset payment method priority and obtain the corresponding biometric data. For example, when both facial and fingerprint payments are enabled, facial payment has higher priority, and in this case, the biometric data includes facial data (i.e., facial data can be obtained by the identity authentication TA).

[0102] The TEE2 may include a driver for the front-facing camera (also referred to as the first driver) and a driver for the fingerprint sensor (also referred to as the second driver). If the payment CA enables facial recognition payment, or if the payment CA enables both fingerprint and facial recognition payment (with facial recognition payment having higher priority than fingerprint payment), the authentication TA, upon receiving the authentication request, can send a request to the front-facing camera driver to invoke the front-facing camera, thereby driving the front-facing camera to collect facial data. If the payment CA enables fingerprint payment, or if the payment CA enables both fingerprint and facial recognition payment (with fingerprint payment having higher priority than facial recognition payment), the authentication TA, upon receiving the authentication request, can send a request to the fingerprint sensor driver to invoke the fingerprint sensor, thereby driving the fingerprint sensor to collect fingerprint data.

[0103] It should be noted that while the identity verification process (TA) is acquiring biometric data, the electronic device can display the data on its screen. Figure 7A The icon shown is 406a (also known as the first identifier) ​​or Figure 7B The icon 406b (also known as the second identifier) ​​is shown. Icon 406a indicates that the electronic device is performing facial recognition; the user can adjust their face position to facilitate the acquisition of facial data. Icon 406b indicates that the electronic device is performing fingerprint recognition; the user can adjust their hand position to facilitate the acquisition of fingerprint data. Specifically, during the identity authentication process (TA) acquiring facial data, the display can show... Figure 7A The icon 406a shown indicates that the display can show the fingerprint data obtained during identity authentication (TA). Figure 7B The icon shown is 406b.

[0104] The TEE1 may also include a display driver. The payment TA can send a request to the display driver to invoke the display, so as to drive the display to show icon 406a or icon 406b.

[0105] After obtaining biometric data, the identity authentication TA can process the data to facilitate subsequent comparison. For example, the identity authentication TA can perform a series of processing operations on the acquired face / fingerprint images, such as light processing, cropping, rotation, noise reduction, filtering, and enlarging or reducing, to make the face / fingerprint images meet the standard requirements for face / fingerprint image feature extraction.

[0106] S307, the identity authentication TA compares the biometric data with the preset data template to obtain the identity authentication result.

[0107] The preset data template can be pre-stored in a secure storage chip. Upon receiving an authentication request, the authentication TA can read the data template from the secure storage chip. The authentication TA can compare the biometric data with the data template. If the biometric data matches the data template, the authentication result is successful; if the biometric data does not match the data template, the authentication result is unsuccessful.

[0108] Specifically, the data template may include multiple face templates and multiple fingerprint templates. The multiple face templates represent the faces of multiple users, and the multiple fingerprint templates can be fingerprints from different users or fingerprints from different fingers of the same user. If the biometric data is face data, the identity authentication TA can query among the multiple face templates to see if there is a face template that is the same as or similar to the face data. If it exists, the biometric data is considered to match the data template; otherwise, it is considered not to match the data template. If the biometric data is fingerprint data, the identity authentication TA can query among the multiple fingerprint templates to see if there is a fingerprint template that is the same as or similar to the fingerprint data. If it exists, the biometric data is considered to match the data template; otherwise, it is considered not to match the data template. For example, if the preset data template includes fingerprint data 1 for user A, fingerprint data 2 for user B, and fingerprint data 3 for user C, then if the biometric data is any one of fingerprint data 1, fingerprint data 2, or fingerprint data 3, the authentication result will be successful; otherwise, the authentication result will be unsuccessful.

[0109] S308, the identity verification TA sends the identity verification result to the payment TA.

[0110] After receiving the authentication result, the identity verification TA can send the result back to the payment TA to confirm whether the user has payment authorization. Similarly, the identity verification TA can send the authentication result to the payment TA via a hypervisor and hardware device.

[0111] S309, the payment TA calls the TUI module to draw and display the identity authentication result.

[0112] Understandably, if the biometric data obtained by the payment platform is facial data, and the authentication result indicates that the facial data matches the facial template (i.e., a successful authentication result is obtained), then the payment platform can call the TUI module to draw and display, as shown below. Figure 8A The icon 406a and the prompt message 407a shown in (a) indicate that the face recognition was successful. If the authentication result is that the face data does not match the face template (i.e., the authentication failed), the payment TA can call the TUI module to draw and display the following: Figure 8AThe icon 406a and the prompt message 407b shown in (b) indicate that the face was not successfully recognized.

[0113] If the biometric data obtained by the payment platform is fingerprint data, and the authentication result shows that the fingerprint data matches the fingerprint template, the payment platform can call the TUI module to display the following: Figure 8B The icon 406b and the prompt message 407c shown in (a) indicate successful fingerprint recognition. If the authentication result is that the fingerprint data does not match the fingerprint template, the payment TA can call the TUI module to display the following: Figure 8B The icon 406b and the prompt message 407d shown in (b) indicate that the fingerprint could not be successfully recognized.

[0114] S310, the payment TA generates a payment request based on the identity authentication result (if authentication is successful) and transaction information.

[0115] When the identity verification result is successful, PaymentTA can generate a payment request. This payment request may include the identity verification result, the timestamp of the identity verification result generation, and transaction information. To reduce the risk of leakage of transaction information and identity verification results, PaymentTA can encrypt both the identity verification result and transaction information.

[0116] S311, the payment TA sends a payment request to the server.

[0117] S312, in response to receiving a payment request, the server performs a payment operation and obtains the payment result.

[0118] The server can parse the authentication result and transaction information from the payment request. The server can also verify the validity of the authentication result. If the authentication result is valid, payment is made according to the transaction information; if the authentication result is invalid, the server will not execute the payment operation. Understandably, the server can determine whether the time difference between the time the authentication result was generated and the current time is greater than or equal to a preset time. If the time difference is greater than the preset time, the authentication result is valid; if the time difference is less than the preset time, the authentication result is invalid. In this way, each authentication result has a time limit, preventing malicious use after the authentication result is leaked.

[0119] S313, the server sends the payment result to the payment CA.

[0120] The server can send the payment result to the payment CA to inform the user whether the payment was successful.

[0121] S314, The payment CA displays information corresponding to the payment result on the payment interface.

[0122] In other words, depending on the payment result, the payment CA can display different information on the payment interface. For example, if the payment result is successful, the electronic device can display a payment success message to inform the user that the payment has been successful. If the payment result is unsuccessful, the electronic device can display a payment failure message to inform the user that identity authentication failed and the payment was not successful.

[0123] In summary, the payment method provided in this application embodiment can delegate the payment process of the payment business to TEE1 and the identity authentication process to TEE2, thereby achieving physical isolation between the payment process and the identity authentication process, reducing the risk of both the payment process and the identity authentication process being maliciously cracked at the same time, and improving the security of the payment business.

[0124] This application also provides a chip system 900, such as Figure 9 As shown, the chip system 900 includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 are interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 902 can be used to send signals to other devices (e.g., the processor 901).

[0125] For example, interface circuit 902 can read instructions stored in the memory of the electronic device and send the instructions to processor 901. When the instructions are executed by processor 901, the electronic device can perform the steps in the above embodiments.

[0126] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0127] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0128] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0129] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.

Claims

1. A payment method, characterized in that, The method is applied to an electronic device including a rich execution environment (REE), a first trusted execution environment (TEE), and a second TEE, the REE including a client application (CA), the first TEE including a first trusted application (TA) and a trusted user interface (TUI) module, and the second TEE including a second TA, the electronic device further including a camera and a fingerprint sensor, the second TEE further including a first driver and a second driver, the REE and the first TEE being isolated based on a virtual machine monitor, and the REE and the second TEE being isolated based on a trust zone, the method comprising: In response to detecting a payment operation of a user, the CA sends a first session request to the first TA through the virtual machine monitor, the first session request including a universally unique identifier of the CA; The first TA creates a first session based on the universally unique identifier of the CA; The CA sends a TUI display request to the first TA through the first session, the TUI display request carrying a TUI identifier; The first TA receives the TUI display request, calls the TUI module to draw and display a first interface, and the first interface is an interface corresponding to the TUI identifier; In response to a first operation of the user on the first interface, the first TA acquires transaction information; In response to an operation of the user confirming that the transaction information is correct, the first TA sends a second session request to the second TA through the virtual machine monitor and a trust zone firmware, the second session request including a universally unique identifier of the first TA; The second TA creates a second session based on the universally unique identifier of the first TA; The first TA sends a first request to the second TA through the second session; In response to the first request, the second TA calls the camera to collect face data through the first driver or calls the fingerprint sensor to collect fingerprint data through the second driver; The second TA compares the face data or the fingerprint data with a preset data template to obtain an identity authentication result; The second TA sends the identity authentication result to the first TA; If the identity authentication result is successful, the first TA performs a payment operation according to the transaction information.

2. The method of claim 1, wherein, The method further comprises: In response to an operation of the user confirming that the transaction information is correct, the first TA calls the TUI module to draw and display a first identifier or a second identifier, wherein the first identifier is used to indicate that the electronic device is collecting fingerprint data, and the second identifier is used to indicate that the electronic device is collecting face data.

3. The method of claim 1, wherein, The first interface includes a first option, and in response to an operation of the user confirming that the transaction information is correct, the first TA sends a first request to the second TA, comprising: In response to an operation of the user on the first option, the first TA displays a first pop-up window on the first interface, and the first pop-up window includes the transaction information and a second option; In response to an operation of the user on the second option, the first TA sends the first request to the second TA.

4. The method of claim 1, wherein, The first TA performs a payment operation according to the transaction information, including: The first TA generates a payment request according to the identity authentication result and the transaction information; The first TA sends the payment request to a server; The server receives the payment request, and verifies the identity authentication result; If the identity authentication result is valid, the server performs a payment operation according to the transaction information.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The first TA calls the TUI module to draw and display the identity authentication result.

6. An electronic device, comprising: The electronic device is integrated with a REE, a first TEE, and a second TEE, the REE includes a CA, the first TEE includes a first TA and a TUI module, and the second TEE includes a second TA, and the electronic device includes a wireless communication module, a memory, and one or more processors; the wireless communication module, the memory, and the processor are coupled; The memory is configured to store computer program code, and the computer program code includes computer instructions; when the computer instructions are executed by the processor, the electronic device performs the payment method in any one of claims 1-5.

7. A computer-readable storage medium, characterized in that, The computer program product includes computer instructions; When the computer instructions run on the electronic device, the electronic device performs the payment method in any one of claims 1-5.

Images