Message processing method and apparatus

Abstract

The embodiments of the present application relate to the field of terminals. Provided are a message processing method and apparatus, which can prevent the problem of lock screen unlock delay or unresponsiveness caused by a lock screen unlock request conflicting with a key pair request. The method is applied to an electronic device comprising an SE chip, a first TA and a second TA, the first TA and the second TA being located in a TEE. The method comprises: at a first moment, an SE chip first receiving a first request message (a key pair request) from a first TA; at a second moment, the SE chip then receiving a second request message (a lock screen unlock request) from a second TA, wherein the second moment is later than the first moment; in response to the second request message, the SE chip first sending to the second TA, at a third moment, a first response message that indicates a lock screen verification parameter; and in response to the first request message, the SE chip then sending to the first TA, at a fourth moment, a second response message that indicates a first key pair, wherein the fourth moment is later than the third moment.

Description

Message processing method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on February 29, 2024, with application number 202410232282.1 and invention name “A Message Processing Method and Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of terminals, and in particular to a message processing method and device. Background Art

[0003] To improve the security of electronic devices, a secure element (SE) can be built into them. An SE is also called a security chip. An SE protects the integrity of user data, keys, and other information. An SE can support multiple applets, such as weaver applets and strongbox applets. Weaver applets can support lock screen unlocking services, while strongbox applets can support key management services.

[0004] Currently, the business request of the weaver applet and the business request of the strongbox applet may conflict. For example, when the SE first receives the business request of the strongbox applet, it will calculate the key pair based on the business request of the strongbox applet. However, it usually takes a long time for the SE to calculate the key pair. If the weaver applet applies for a lock screen unlock business request while the SE is calculating the key pair, the weaver applet's request will not be processed in a timely manner, and the feedback to the user side will be delayed or unresponsive to the lock screen unlock (for example, frozen screen or crash), which seriously affects the user experience. Summary of the Invention

[0005] The embodiments of the present application provide a message processing method and device, which can avoid the problem of lock screen unlocking delay or unresponsiveness caused by conflicts between lock screen unlocking requests (for example, business requests of weaver applet) and key pair requests (for example, business requests of strongbox applet), thereby improving user experience.

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

[0007] In a first aspect, a message processing method is provided, which is applied to an electronic device. The electronic device includes a SE chip, a first trusted application TA and a second TA, and the first TA and the second TA are located in a trusted execution environment TEE. The method includes: at a first moment, the SE chip receives a first request message from the first TA; at a second moment, the SE chip receives a second request message from the second TA; wherein the second moment is later than the first moment; in response to the second request message, the SE chip sends a first response message to the second TA at a third moment, and the first response message indicates a lock screen verification parameter; in response to the first request message, the SE chip sends a second response message to the first TA at a fourth moment, and the second response message indicates a first key pair; wherein the fourth moment is later than the third moment.

[0008] Based on the method provided in the embodiments of the present application, although the SE chip first receives the first request message and then the second request message, the SE chip can first respond to the second request message and send a first response message indicating the lock screen verification parameters to the second TA; then respond to the first request message and send a second response message indicating the first key pair to the first TA. In this way, the SE chip can respond to the lock screen unlock request (the second request message) in a timely manner, avoiding the problem of lock screen unlock delay or unresponsiveness, and improving the user experience.

[0009] In one possible implementation, the first request message, the second request message, the first response message, and the second response message are integrated circuit bus (I2C) instructions; the first request message includes a first parameter, a second parameter, and a third parameter, and the first, second, and third parameters are related to the first key pair; the second request message includes a fourth parameter and a fifth parameter, and the fourth and fifth parameters are related to the lock screen verification parameters. That is, the parameters (first parameter - third parameter) included in the first request message correspond to the information (first key pair) included in the second response message. Exemplarily, the first parameter may be the key type (e.g., RSA key pair type), the second parameter may be the key length, and the third parameter may be the key usage. The first key pair may be an RSA key pair. The parameters (fourth parameter - fifth parameter) included in the second request message correspond to the information (lock screen verification parameters) included in the first response message. Exemplarily, the fourth parameter may be slotId, which is a card slot identifier. SlotId may be determined based on the lock screen credentials entered by the user (e.g., lock screen password). The fifth parameter may be a parameter calculated based on the lock screen credentials using an encryption algorithm (e.g., scrypt algorithm). The lock screen verification parameters are used to verify the lock screen credentials.

[0010] In one possible implementation, the second request message and the first response message are transmitted over a first logical channel; the first request message and the second response message are transmitted over a second logical channel, where the second logical channel is different from the first logical channel. Transmitting different types of request and response messages over different logical channels can avoid confusion between different types of request and response messages.

[0011] In one possible implementation, the method further includes: after the SE chip receives the first request message, calculating the first key pair; and in response to the second request message, the SE chip sending a first response message to the second TA, including: after the SE chip receives the second request message, interrupting the calculation of the first key pair, obtaining the lock screen verification parameters, and sending the first response message to the second TA. In this way, the SE chip can promptly respond to the lock screen unlock request (the second request message) and send the first response message indicating the lock screen verification parameters to the second TA, thereby avoiding lock screen unlock delays or unresponsiveness and improving the user experience.

[0012] In one possible implementation, the method further includes: after the SE chip interrupts the calculation of the first key pair, discarding the calculation result of the first key pair; and after the SE chip sends the first response message to the second TA, recalculating the first key pair. In this way, the SE chip does not need to store the calculation result of the first key pair, which can save storage space.

[0013] In one possible implementation, the method further includes: after the SE chip interrupts the calculation of the first key pair, saving the calculation result of the first key pair; and after the SE chip sends the first response message to the second TA, continuing to calculate the first key pair based on the saved calculation result. In this way, the SE chip can continue to calculate the first key pair based on the saved calculation result, thereby reducing the time spent on calculating the first key pair.

[0014] In one possible implementation, the SE chip pre-stores multiple key pairs, and the multiple key pairs include a first key pair. The method further includes: after the SE chip receives the first request message, it reads the first key pair; in response to the second request message, the SE chip sends a first response message to the second TA, including: after the SE chip receives the second request message, it interrupts reading the first key pair, obtains the lock screen verification parameters, and sends the first response message to the second TA; after the SE chip sends the first response message to the second TA, it re-reads the first key pair. In this way, the SE chip can respond to the lock screen unlock request (second request message) in a timely manner, avoid the problem of lock screen unlock delay or no response, and improve the user experience. Then, the SE chip can re-read the first key pair from the pre-stored multiple key pairs, without consuming a long time to calculate the first key pair, which can improve the efficiency of obtaining the first key pair.

[0015] In one possible implementation, multiple key pairs are generated by the first TA and sent to the SE; alternatively, multiple key pairs are generated by the SE. Generating multiple key pairs by the first TA and sending them to the SE eliminates the time-consuming generation of multiple key pairs by the SE, which is more efficient. Generating multiple RSA key pairs by the SE ensures that the RSA key pairs are generated entirely within the SE, guaranteeing hardware-level confidentiality.

[0016] In one possible implementation, the method further includes: after the first TA sends the first request message to the SE chip, polling the SE chip for the first key pair. For example, the first TA may request the SE chip to obtain a calculation result of the first key pair once every fixed time interval (e.g., 1 second).

[0017] In a possible implementation, the electronic device further includes a first service and an I2C driver, and the SE chip receives a first request message from the first TA, including: the first TA generates a first application protocol data unit APDU instruction, the first APDU instruction includes a first parameter, a second parameter, and a third parameter; the first TA sends the first APDU instruction to the first service; in response to the first APDU instruction, the first service adds a first I2C message header to the first APDU instruction to obtain a first I2C instruction; the first service sends the first I2C instruction to the I2C driver; in response to the first I2C instruction, the I2C driver sends the first I2C instruction to the SE chip. The SE chip receives a first I2C instruction from the I2C driver; the SE chip receives a second request message from the second TA, including: the second TA generates a second APDU instruction, the second APDU instruction including a fourth parameter and a fifth parameter; the second TA sends the second APDU instruction to the first service; in response to the second APDU instruction, the first service adds a second I2C message header to the second APDU instruction to obtain a second I2C instruction; the first service sends the second I2C instruction to the I2C driver; in response to the second I2C instruction, the I2C driver sends the second I2C instruction to the SE chip; and the SE chip receives the second I2C instruction from the I2C driver. That is, the first TA can send a first request message to the SE chip via the first service and the I2C driver, the first request message being a first I2C instruction including a first APDU instruction and a first I2C message header. The second TA can send a second request message to the SE chip via the first service and the I2C driver, the second request message being a second I2C instruction including a second APDU instruction and a second I2C message header. The APDU instruction (the first APDU instruction or the second APDU instruction) may include a CLA field, an INS field, a P1 field, a P2 field, an Lc field, and a Data field. The Data field of the first APDU instruction may include a first parameter, a second parameter, and a third parameter. The Data field of the second APDU instruction may include a fourth parameter and a fifth parameter.

[0018] In one possible implementation, the SE includes a core module, a first applet and a second applet, and the SE chip receives a first I2C instruction from the I2C driver, including: the first applet receives the first I2C instruction from the I2C driver; in response to the first I2C instruction, the first applet parses the first I2C instruction to obtain a first parameter, a second parameter and a third parameter; the first applet sends the first parameter, the second parameter and the third parameter to the core module; the core module calculates or reads the first key pair based on the first parameter, the second parameter and the third parameter; the SE chip receives a second I2C instruction from the I2C driver, including: the second applet receives a second I2C instruction from the second TA; in response to the second I2C instruction, the second applet parses the second I2C instruction to obtain a fourth parameter and a fifth parameter; the second applet sends the fourth parameter and the fifth parameter to the core module; the core module reads the lock screen verification parameter based on the fourth parameter and the fifth parameter. Based on the method provided in the embodiment of the present application, the core module can first respond to the second request message (second I2C instruction), read the lock screen verification parameters according to the fourth parameter and the fifth parameter, and send a first response message indicating the lock screen verification parameters to the second TA; then respond to the first request message (first I2C instruction), calculate or read the first key pair according to the first parameter, the second parameter, and the third parameter, and send a second response message indicating the first key pair to the first TA. In this way, the core module can respond to the lock screen unlock request (second request message) in a timely manner, avoid the problem of lock screen unlock delay or no response, and improve the user experience.

[0019] In a possible implementation, the SE chip sends a first response message to the second TA at the third moment, including: the first applet receives the first key pair from the core module, encapsulates the first key pair into a third APDU instruction, and then adds a third I2C message header to the third APDU instruction to obtain a third I2C instruction; the first applet sends the third I2C instruction to the I2C driver at the third moment; the I2C driver sends the third I2C instruction to the first service; in response to the third I2C instruction, the first service decapsulates the third I2C instruction to obtain a third APDU instruction, and sends the third APDU instruction to the second TA. DU instruction; the SE chip sends a second response message to the first TA at the fourth moment, including: the second applet receives the lock screen verification parameters from the core module, encapsulates the lock screen verification parameters into a fourth APDU instruction, and then adds a fourth I2C message header to the fourth APDU instruction to obtain a fourth I2C instruction; the second applet sends a fourth I2C instruction to the I2C driver at the fourth moment; the I2C driver sends a fourth I2C instruction to the first service; in response to the fourth I2C instruction, the first service decapsulates the fourth I2C instruction to obtain a fourth APDU instruction, and sends the fourth APDU instruction to the first TA. Based on the method provided in the embodiment of the present application, the core module can first respond to the second request message (the second I2C instruction), send a first response message indicating the lock screen verification parameters to the second TA (i.e., the third I2C instruction, the third I2C instruction includes a third APDU instruction and a third I2C message header), and then respond to the first request message (the first I2C instruction), and send a second response message indicating the first key pair to the first TA (i.e., the fourth I2C instruction, the fourth I2C instruction includes a fourth APDU instruction and a fourth I2C message header). In this way, the core module can respond to the lock screen unlock request (second request message) in a timely manner, avoid the problem of lock screen unlock delay or no response, and improve user experience.

[0020] In the second aspect, a message processing method is provided, which is applied to an electronic device. The electronic device includes a security unit SE chip and a first trusted application TA. The SE chip pre-stores multiple key pairs, the multiple key pairs include a first key pair, and the first TA is located in a trusted execution environment TEE. The method includes: the SE chip receives a first request message from the first TA; in response to the first request message, the SE chip sends a first response message to the first TA, and the first response message indicates the first key pair.

[0021] Based on the method provided in the embodiments of the present application, the SE chip can send a second response message indicating a first key pair to the first TA in response to the first request message, where the first key pair is one of multiple pre-stored key pairs. In this way, the SE chip does not need to spend a long time calculating the first key pair, and the problem of the SE chip being unable to respond to the lock screen unlock request during the calculation of the first key pair, resulting in a delayed or unresponsive lock screen unlock, can be avoided.

[0022] In one possible implementation, multiple key pairs are generated by the first TA and sent to the SE; alternatively, multiple key pairs are generated by the SE. This allows the first TA to generate multiple key pairs and send them to the SE, eliminating the SE's time-consuming generation and increasing efficiency. Generating multiple RSA key pairs by the SE ensures that the RSA key pairs are generated entirely within the SE, guaranteeing hardware-level confidentiality.

[0023] In one possible implementation, the first request message and the first response message are integrated circuit bus I2C instructions; the first request message includes a first parameter, a second parameter, and a third parameter, and the first parameter, the second parameter, and the third parameter are related to the first key pair.

[0024] In one possible implementation, the electronic device also includes a first service and an I2C driver, and the SE chip receives a first request message from the first TA, including: the first TA generates a first application protocol data unit APDU instruction, the first APDU instruction includes a first parameter, a second parameter and a third parameter; the first TA sends the first APDU instruction to the first service; in response to the first APDU instruction, the first service adds a first I2C message header to the first APDU instruction to obtain a first I2C instruction; the first service sends the first I2C instruction to the I2C driver; in response to the first I2C instruction, the I2C driver sends the first I2C instruction to the SE chip; the SE chip receives the first I2C instruction from the I2C driver.

[0025] In one possible implementation, the SE includes a core module, a first applet, and a second applet. The SE chip receives a first I2C instruction from an I2C driver, including: the first applet receives the first I2C instruction from the I2C driver; in response to the first I2C instruction, the first applet parses the first I2C instruction to obtain a first parameter, a second parameter, and a third parameter; the first applet sends the first parameter, the second parameter, and the third parameter to the core module; and the core module reads a first key pair based on the first parameter, the second parameter, and the third parameter.

[0026] In one possible implementation, the SE chip sends a first response message to the first TA, including: the first applet receives the first key pair from the core module, encapsulates the first key pair into a third APDU instruction, and then adds a third I2C message header to the third APDU instruction to obtain a third I2C instruction; the first applet sends the third I2C instruction to the I2C driver at a third moment; the I2C driver sends the third I2C instruction to the first service; in response to the third I2C instruction, the first service decapsulates the third I2C instruction to obtain a third APDU instruction, and sends the third APDU instruction to the first TA.

[0027] In one possible implementation, before the core module reads the first key pair based on the first parameter, the second parameter, and the third parameter, the method further includes: the SE chip saving the correspondence between the first parameter, the second parameter, and the third parameter and the first key pair; or the SE chip saving the correspondence between the first parameter, the second parameter, and the third parameter and a first index, where the first index is used to index the first key pair. In this way, the next time the SE chip receives the same key pair request parameters (first parameter, second parameter, and third parameter), it can assign the same key pair (first key pair) to the RSA key pair request parameters. This ensures that the same RSA key pair is read during multiple verifications of the same service, thereby ensuring the normal operation of the service.

[0028] According to a third aspect, a security element is provided, including an acquisition module and a core module, wherein the acquisition module acquires a first request message from a first TA at a first moment, and the acquisition module acquires a second request message from a second TA at a second moment, and the second moment is later than the first moment; the core module responds to the second request message and sends a first response message at a third moment, and the first response message indicates a lock screen verification parameter to the second TA; the core module responds to the first request message and sends a second response message at a fourth moment, and the second response message indicates a first key pair to the first TA; wherein the fourth moment is later than the third moment.

[0029] Based on the method provided in the embodiment of the present application, although the acquisition module of the security element first receives the first request message and then receives the second request message, the core module of the security element can first respond to the second request message and send a first response message indicating the lock screen verification parameters to the second TA, and then respond to the first request message and send a second response message indicating the first key pair to the first TA. In this way, the security element can respond to the lock screen unlock request (second request message) in a timely manner, which can avoid the problem of lock screen unlock delay or no response, and can improve the user experience.

[0030] In one possible implementation, the acquisition module includes a first applet and a second applet, and the acquisition module acquires a first request message from the first TA at a first moment, including: the first applet acquires the first request message from the first TA at the first moment, and the first request message is a first integrated circuit bus I2C instruction; the acquisition module acquires a second request message from the second TA at a second moment, including: the second applet acquires the second request message from the second TA at the second moment, and the second request message is a second I2C instruction; the core module responds to the second request message, and before sending the first response message at a third moment, the second applet parses the second I2C instruction to obtain a fourth parameter and a fifth parameter, sends the fourth parameter and the fifth parameter to the core module, and the core module receives the fourth parameter and the fifth parameter; wherein the fourth parameter and the fifth parameter are related to the lock screen verification parameter; the core module responds to the first request message, and before sending the second response message at the fourth moment, the first applet parses the first I2C instruction to obtain a first parameter, a second parameter, and a third parameter, sends the first parameter, the second parameter, and the third parameter to the core module, and the core module receives the first parameter, the second parameter, and the third parameter; wherein the first parameter, the second parameter, and the third parameter are related to the first key pair.

[0031] The beneficial effects that can be achieved by the method described in any implementation of the third aspect can refer to the beneficial effects of any possible implementation of the first aspect or the second aspect mentioned above, and will not be repeated here.

[0032] In one possible implementation, after the core module receives the first parameter, the second parameter, and the third parameter, it calculates the first key pair based on the first parameter, the second parameter, and the third parameter; the core module responds to the second request message and sends a first response message at a third time, including: after the core module receives the fourth parameter and the fifth parameter, it interrupts the calculation of the first key pair, obtains the lock screen verification parameter based on the fourth parameter and the fifth parameter, and sends the first response message to the second TA.

[0033] In a possible implementation, after the core module interrupts the calculation of the first key pair, the calculation result of the first key pair is discarded; after the core module sends the first response message to the second TA, the core module recalculates the first key pair.

[0034] In a possible implementation, after the core module interrupts the calculation of the first key pair, it saves the calculation result of the first key pair; after the core module sends the first response message to the second TA, it continues to calculate the first key pair according to the saved calculation result.

[0035] In one possible implementation, the security element pre-stores multiple key pairs, the multiple key pairs include a first key pair, and after the core module receives the first parameter, the second parameter, and the third parameter, it reads the first key pair according to the first parameter, the second parameter, and the third parameter; the core module responds to the second request message and sends a first response message at a third moment, including: after the core module receives the fourth parameter and the fifth parameter, it interrupts reading the first key pair, obtains the lock screen verification parameter, and sends the first response message to the second TA; after the core module sends the first response message to the second TA, it re-reads the first key pair.

[0036] In a fourth aspect, an electronic device is provided, comprising: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the electronic device performs the method described in any possible implementation of the first aspect or the second aspect.

[0037] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described in any possible implementation of the first aspect or the second aspect.

[0038] In a sixth aspect, an embodiment of the present application provides a computer program product, which includes a computer program. When the computer program is run, it enables the computer to execute the method described in any possible implementation of the first aspect or the second aspect.

[0039] It is understood that the electronic device provided in the fourth aspect, the computer storage medium provided in the fifth aspect, and the computer program product provided in the sixth aspect can all execute the method described in any one of the implementations of the first or second aspects. Therefore, the beneficial effects that can be achieved can be referenced to the beneficial effects of any possible implementation of the first or second aspects, and will not be further elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] FIG1 is a schematic diagram of a conflict between a service request of a weaver applet and a service request of a strongbox applet in the related art;

[0041] FIG2 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

[0042] FIG3 is a schematic diagram of a software architecture of an electronic device provided in an embodiment of the present application;

[0043] FIG4A is a schematic diagram of a display provided in an embodiment of the present application;

[0044] FIG4B is another display diagram provided in an embodiment of the present application;

[0045] FIG5 is a schematic diagram of information interaction of a message processing method provided in an embodiment of the present application;

[0046] FIG6 is a schematic diagram of information interaction of another message processing method provided in an embodiment of the present application;

[0047] FIG7 is a schematic diagram of information interaction of another message processing method provided in an embodiment of the present application;

[0048] FIG8 is a schematic diagram of information interaction of another message processing method provided in an embodiment of the present application;

[0049] FIG9 is a schematic diagram of signal interaction of another message processing method provided in an embodiment of the present application;

[0050] FIG10 is another display schematic diagram provided in an embodiment of the present application;

[0051] FIG11A is a schematic diagram of information interaction between modules provided in an embodiment of the present application;

[0052] FIG11B is a schematic diagram of information interaction between modules according to another embodiment of the present application;

[0053] FIG12A is a schematic diagram of information interaction between modules according to another embodiment of the present application;

[0054] FIG12B is a schematic diagram of information interaction between modules according to another embodiment of the present application;

[0055] FIG13 is a schematic structural diagram of a security element provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. In the description of the present application, unless otherwise specified, "at least one" means one or more, and "a plurality of" means two or more than two. In addition, in order to facilitate the clear description of the technical solutions in the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

[0057] To make the description of the following embodiments clear and concise, a brief introduction to the relevant concepts or technologies is first given:

[0058] A rich execution environment (REE), also known as a rich execution environment, common execution environment, or untrusted execution environment, is a mobile system runtime environment that can run operating systems such as Android, iOS, and Linux. REEs are open and scalable, but lack high security.

[0059] A trusted execution environment (TEE), also known as a secure side or secure zone, is an area requiring authorization for access. The TEE coexists with the REE in the operating environment of electronic devices. The TEE, through hardware support, is isolated from the REE, providing security and resistance to software attacks that are common to the REE. The TEE has its own operating space and defines strict protections. Therefore, the TEE offers a higher level of security than the REE, protecting assets within the TEE, such as data and software, from software attacks and specific security threats.

[0060] The REE+TEE architecture combines a TEE and REE to provide services for applications. In other words, the TEE and REE coexist within the electronic device. For example, the TEE, supported by hardware, operates in isolation from the REE. The TEE maintains its own runtime space, allowing only authorized security software to execute within it. This TEE also protects the confidentiality of the security software's resources and data. Compared to the REE, the TEE offers better protection for data and resource security due to its isolation and permission control mechanisms.

[0061] TA, or trusted application, is an application running in TEE that can provide security services to CA running outside TEE, such as password input, transaction signature generation, face recognition, etc.

[0062] CA, or client application, is typically an application running in the REE. The CA can call the TA through the client application programming interface (API) and instruct the TA to perform corresponding security operations.

[0063] SE Ready Alliance: To improve the security of Android devices, Google established the SE Ready Alliance, which is dedicated to the research and development and promotion of Secure Element (SE), which will enable the Android system to support devices with built-in SE.

[0064] Services supported by the SE Ready Alliance may include weaver applet, strongbox applet, keymaster / keymint for Java Card, mobile driving license (MDL), electronic identity credentials (IC), and original equipment manufacturers (OEM) can expand other services (such as electronic keys, electronic wallets, digital currencies, etc.).

[0065] Below, we take SE's support for weaver applet and strongbox applet as an example. The weaver applet supports lock screen unlock services. The strongbox applet supports key management services. However, the business request of the weaver applet and the business request of the strongbox applet may conflict. For example, as shown in Figure 1, when the strongbox applet receives a business request (for example, an RSA key pair generation request), the strongbox applet can send the business request to the core module (chip core) of the SE, and the core module of the SE can continuously calculate the key pair based on the business request. Because the SE is limited by cost, power consumption, security and other restrictions, it can currently only support single-threaded business processing. If the weaver applet applies for a lock screen unlock business request to the core module of the SE while the SE is calculating the key pair, the core module of the SE cannot respond to the request of the weaver applet. Therefore, the request of the weaver applet cannot be processed in a timely manner, and the feedback to the user side is a delay in lock screen unlocking or no response (for example, frozen screen or crash), which seriously affects the user experience.

[0066] The embodiments of the present application provide a message processing method and device, which can avoid the problem of lock screen unlocking delay or no response caused by conflicts between lock screen unlocking requests (business requests of weaver applet) and key pair requests (business requests of strongbox applet), thereby improving user experience.

[0067] The message processing method provided in the embodiment of the present application can be applied to electronic devices. FIG2 is a schematic diagram of the structure of an electronic device 100 provided in the embodiment of the present application.

[0068] As shown in Figure 2, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a subscriber identification module (SIM) card interface 195, and an SE 196, etc.

[0069] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0070] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors. For example, one or more processing units may be integrated into the same system on a chip (SoC).

[0071] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0072] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0073] In some embodiments, the processor 110 may include one or more interfaces. The 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.

[0074] It is understood that the interface connection relationship between the modules illustrated in this embodiment is merely an illustrative illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments, the electronic device 100 may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0075] In this embodiment, SE 196 is a standalone hardware system with an independent CPU and secure storage that complies with Google's commercial due diligence (CDD) requirements. The SE generates true random numbers, provides additional mechanisms to protect against software package tampering and unauthorized flashing, and protects against side-channel attacks.

[0076] The methods in the following embodiments can all be implemented in the electronic device 100 having the above hardware structure.

[0077] The electronic device 100 may be, for example, a mobile phone, a tablet computer, a personal computer (PC), a television, a wearable device (such as a smart watch, a smart bracelet, etc.), a vehicle-mounted device, an embedded device, etc., and this application does not limit this.

[0078] The software system of the electronic device 100 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the present invention, the Android system with a layered architecture is used as an example to illustrate the software structure of the electronic device 100.

[0079] The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through interfaces. In some embodiments, the Android system may include an application layer, an application framework layer, an Android runtime (Android runtime) and a system library, a hardware abstraction layer (HAL) and a kernel layer. It should be noted that the embodiments of the present application are illustrated by taking the Android system as an example. In other operating systems (such as Hongmeng system, IOS system, etc.), as long as the functions implemented by each functional module are similar to those of the embodiments of the present application, the solutions of the present application can also be implemented.

[0080] Among them, the application layer can include a series of application packages.

[0081] As shown in Figure 3, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, GMS, lock screen application, setting application, etc. Of course, the application layer may also include other application packages, such as payment application, life service application, shopping application, banking application, chat application or financial application, etc., which are not limited in this application.

[0082] Among them, the lock screen application can perform unlocking processes such as face unlocking, fingerprint unlocking, and password unlocking. The embodiments of this application mainly use password unlocking as an example. Password unlocking refers to the scenario where the electronic device receives the lock screen credentials entered by the user in the lock screen state and verifies the lock screen credentials to determine whether to unlock the electronic device.

[0083] Payment applications or life service applications can support services such as electronic keys, electronic wallets, digital currencies, electronic driver's licenses, and electronic certificates.

[0084] GMS is the abbreviation of "Google Mobile Services". GMS can include API interfaces such as Google Services Framework, Store (PlayStore), Search (Search), and Voice (Voice).

[0085] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0086] In an embodiment of the present application, the application framework layer may include a keystore interface (Android keystore API) and a lock screen service (LockSetting service).

[0087] Among them, the keystore interface can be used by upper-layer applications (for example, GMS) to call the keystore. Keystore is the core of Android key management and can provide key services to upper-layer applications. The version of keystore can be keystore (equivalent to the previous version of keystore2) or keystore2 (equivalent to the new version of keystore). This application uses the keystore version keystore2 as an example for explanation.

[0088] The lock screen service can be used by upper-layer applications (eg, lock screen applications) to call the weaver service.

[0089] The application framework layer may also include other services, such as an activity manager, a window manager, a content provider, a view system, a resource manager, a notification manager, a camera service, etc. The embodiments of the present application do not impose any restrictions on this.

[0090] In an embodiment of the present application, the system library may include a keystore and a weaver service.

[0091] The keystore can store encryption keys, making it more difficult to extract the keys from the device.

[0092] The weaver service can determine the weaver key.

[0093] The system library can also include other functional modules. For example: surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc. The surface manager can manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. OpenGL ES can implement 3D graphics drawing, image rendering, synthesis, and layer processing. SGL is a drawing engine for 2D drawing.

[0094] The Android runtime consists of core libraries and a virtual machine (VM). The Android runtime is responsible for scheduling and management of the Android system. The core library consists of two parts: one for Java-based functions and the other for the Android core library. The application layer and application framework layer run in the VM. The VM executes the Java files in the application layer and application framework layer as binary files. The VM performs functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0095] The HAL layer is an encapsulation of the Linux kernel driver, providing an interface to the upper layer and shielding the implementation details of the low-level hardware.

[0096] In the embodiment of the present application, the HAL layer may include a strongbox HAL and a weaver HAL, wherein the strongbox HAL may include a strongbox CA, and the weaver HAL may include a weaver CA.

[0097] Strongbox CA can communicate with strongbox TA in TEE. Weaver CA can communicate with weaver TA in TEE.

[0098] The TEE may further include a secflash service (first service), which may encapsulate I2C instructions to communicate with an I2C driver.

[0099] The HAL layer may also include a keymint HAL (not shown in the figure). The keymint HAL is a key management framework that supports keystores.

[0100] The HAL layer may also include audio HAL, camera HAL, etc., which is not limited in this application.

[0101] The kernel layer is the layer between hardware and software. The kernel layer includes at least display driver, camera driver, audio driver, and sensor driver.

[0102] In the embodiment of the present application, the kernel layer may further include an I2C driver. The I2C driver may support communication between the secflash service and the SE.

[0103] The hardware layer includes displays, cameras, SE, etc.

[0104] Among them, SE includes multiple different small application programs (applets). Applets can be developed by SE manufacturers based on specialized development tools and written into SE. For example, SE can include weaver applets and strongbox applets. Weaver applets can perform lock screen password-related processing, and strongbox applets can support keymaster functions. Keymaster is a key management service API supported by hardware. SE can also include a core module (chip core) that can perform password query or key calculation and other processing.

[0105] It should be noted that the strongbox TA, weaver TA, secflash service and I2C driver involved in the embodiments of the present application can be located in TEE, and the remaining modules (for example, strongbox CA, weaver CA, strongbox HAL, weaver HAL, etc.) can be located in REE.

[0106] In some embodiments, the Android system's TEE may include an application layer, a system library, and a kernel layer. For example, the strongbox TA and weaver TA are located in the TEE's application layer, the secflash service is located in the TEE's system library, and the I2C driver is located in the TEE's kernel layer. The TEE may also include more or fewer layers, and this application does not specifically limit the layers included in the TEE.

[0107] As shown in Figure 3, the lock screen application in the application layer can interact with the lock screen service in the framework layer, the lock screen service can interact with the weaver service in the system library, the weaver service can interact with the weaver HAL in the HAL layer, the weaver HAL can interact with the weaver CA, the weaver CA can interact with the weaver TA, and the weaver TA can interact with the weaver applet in the SE through the secflash service and the I2C driver. The weaver applet in the SE can interact with the core module in the SE to process the weaver applet's business requests (for example, lock screen unlock requests).

[0108] The GMS or payment application in the application layer can interact with the keystore interface in the framework layer, the keystore interface can interact with the keystore in the system library, the keystore can interact with the strongbox HAL in the HAL layer, the strongbox HAL can interact with the strongbox CA, the strongbox CA can interact with the strongbox TA, and the strongbox TA can interact with the strongbox applet in the SE through the secflash service and the I2C driver. The strongbox applet in the SE can interact with the core module in the SE to process the strongbox applet's business requests (for example, RSA key pair generation request).

[0109] For example, taking the electronic device as a mobile phone, as shown in (a) of FIG4A , in response to the user's operation (e.g., a click operation) on the installation control 402 corresponding to "GMS" in the application installation interface 401 of the application market, the mobile phone can download and install the GMS installation package. As shown in (b) of FIG4A , when the download progress of the GMS installation package reaches 100%, that is, after the download of the GMS installation package is complete, GMS can call the strongbox TA to request the SE chip to generate an RSA key pair. The RSA key pair can include a public key and a private key. The RSA key pair can sign and verify applications that use GMS services (e.g., applications installed via GMS). While the SE chip is calculating the RSA key pair, the user may perform an unlock operation. For example, as shown in (a) of FIG4B , the lock screen application of the mobile phone can display the lock screen interface 408. The lock screen interface 408 can include an unlock icon 409 (closed) and the prompt text "Swipe up to unlock" 410. In response to the user's upward swipe, as shown in Figure 4B (b), the phone's lock screen application may display interface 411, which may include prompt text "Enter Password" 413 and soft keyboard 416. The user can enter the lock screen password through soft keyboard 416 to unlock the phone. At this point, the lock screen application may call the weaver TA to request lock screen verification parameters from the SE chip.

[0110] Alternatively, in another possible scenario, the user may switch the privacy space while the SE chip is calculating the RSA key pair. In this case, in response to the user entering the lock screen password of the privacy space, the lock screen application can call the weaver TA to request the lock screen verification parameters from the SE.

[0111] However, while the SE chip is calculating the key pair, the SE chip cannot respond to the lock screen application's request in a timely manner, that is, it cannot send the lock screen verification parameters to the lock screen application in a timely manner, which will cause the lock screen unlocking to be delayed or unresponsive (for example, the screen is frozen or crashed), seriously affecting the user experience.

[0112] The present application provides a message processing method that can avoid the problem of lock screen unlocking delay or no response caused by conflicts between lock screen unlocking requests and RSA key pair generation requests. The method provided in the present application can be applied to an electronic device, which includes an SE chip, a first TA and a second TA. The following example uses the first TA as a strongbox TA and the second TA as a weaver TA as an example. As shown in Figure 5, the method includes the following steps:

[0113] 501. At a first moment, the SE chip receives a first request message from the strongbox TA.

[0114] In one possible implementation, the first request message is an RSA key pair request message. In one possible implementation, the first request message is an I2C instruction (first I2C instruction).

[0115] In one possible implementation, the first request message may include a first parameter. Exemplarily, the first parameter is a key type (e.g., an RSA key pair type). The first request message may also include a second parameter and a third parameter, where the second parameter and the third parameter are related to the first key pair. The second parameter is a key length, and the third parameter is a key usage. The first key pair is an RSA key pair. Please refer to the embodiments below and will not be repeated here.

[0116] 502. At a second moment, the SE chip receives a second request message from the weaver TA.

[0117] The second time is later than the first time, that is, the SE chip receives the first request message first and then receives the second request message.

[0118] In one possible implementation, the second request message is a lock screen verification parameter request. In one possible implementation, the second request message is an I2C instruction (a second I2C instruction).

[0119] In one possible implementation, the second request message includes a fourth parameter. Exemplarily, the fourth parameter is a lock screen credential, for example, the fourth parameter is slotId. slotId is a card slot identifier, and slotId can be determined based on the user's userId, and the user's userId can be determined based on the lock screen credential entered by the user (for example, a lock screen password). The first request message may also include a fifth parameter, which is related to a lock screen verification parameter, for example, it may be a parameter calculated based on an encryption algorithm (for example, a scrypt algorithm) for the lock screen credential. Please refer to the embodiments below and will not go into details here.

[0120] 503. In response to the second request message, the SE chip sends a first response message to the weaver TA at a third time.

[0121] Among them, the first response message indicates the lock screen verification parameters.

[0122] In a possible implementation, the first response message is an I2C command (third I2C command).

[0123] In a possible implementation, the second request message and the first response message are transmitted on the first logical channel.

[0124] 504. In response to the first request message, the SE chip sends a second response message to the strongbox TA at a fourth time.

[0125] The second response message indicates the first key pair. The fourth time is later than the third time.

[0126] In a possible implementation, the second response message is an I2C command (a fourth I2C command).

[0127] In one possible implementation, the first request message and the second response message are transmitted over a second logical channel, which is different from the first logical channel. Different types of key-related information, including request and response messages, are transmitted over different logical channels, thereby avoiding confusion between different types of key-related information.

[0128] Based on the method provided in the embodiment of the present application, although the SE chip first receives the first request message and then receives the second request message, the SE chip can first respond to the second request message and send a first response message indicating the lock screen verification parameters to the second TA, and then respond to the first request message and send a second response message indicating the first key pair to the first TA. In this way, the lock screen unlock request (first request message) can be responded to in a timely manner, and the conflict between the lock screen unlock request and the RSA key pair generation request can be avoided, resulting in lock screen unlock delay or no response.

[0129] Another embodiment of the present application provides a message processing method that can avoid the problem of lock screen unlocking delay or no response caused by the conflict between the lock screen unlocking request and the RSA key pair generation request. The method provided in the embodiment of the present application can be applied to an electronic device, which includes an SE chip, a first TA and a second TA, and the SE chip includes a first applet, a second applet and a core module. The following is an example of the first TA being a strongbox TA, the second TA being a weaver TA, the first applet being a strongbox applet, and the second applet being a weaver applet. As shown in Figure 6, the method includes the following steps:

[0130] 601. GMS sends RSA key pair request parameters to strongbox TA.

[0131] For example, in response to the user's operation of installing GMS, or in response to the completion of GMS download, GMS may send an RSA key pair request message to the strongbox TA. The RSA key pair request message may include RSA key pair request parameters, and the RSA key pair request parameters may include key type (first parameter), key length (second parameter), and key usage (third parameter).

[0132] Optionally, the RSA key pair request parameters may further include at least one of parameters such as a key alias, a key validity period, a key digest, and padding.

[0133] 602. The strongbox TA sends RSA key pair request parameters to the strongbox applet of the SE.

[0134] The strongbox TA may send a first I2C instruction (a first request message) to the strongbox applet of the SE. The first I2C instruction includes a first I2C message header and a first APDU instruction. The first APDU instruction includes an encapsulated RSA key pair request parameter.

[0135] 603. The strongbox applet sends RSA key pair request parameters to the core module.

[0136] After receiving the first I2C instruction, the strongbox applet can strip (remove) the first I2C message header of the first I2C request instruction to obtain the first APDU instruction, decapsulate the first APDU instruction to obtain the RSA key pair request parameters, and then forward the RSA key pair request parameters to the core module.

[0137] 604. The core module calculates the RSA key pair according to the RSA key pair request parameters.

[0138] After receiving the RSA key pair request parameters, the core module may save the RSA key pair request parameters to the storage unit of the SE (ie, write the received RSA key pair request parameters into the storage space of the storage unit).

[0139] In some embodiments, the core module may calculate the RSA key pair (first key pair) according to the RSA key pair request parameters based on the CPU capability of the SE.

[0140] It should be understood that the length of an RSA key pair is more than 2048 bits, so calculating an RSA key pair is very time-consuming. However, the CPU of the SE has a low computing speed, and calculating an RSA key pair usually takes more than 5 to 10 seconds.

[0141] While the SE chip is calculating the key pair, the user may switch privacy spaces. When switching privacy spaces, the user can enter the privacy space lock screen password, so that the lock screen application can call the weaver TA to request the lock screen verification parameters (e.g., value) from the SE. This allows steps 605-616 to be executed.

[0142] 605. In response to the user inputting the lock screen credentials to the lock screen application, the lock screen application sends a lock screen unlock request parameter to the weaver TA. The lock screen unlock request parameter includes slotId (the fourth parameter) and weaver key (the fifth parameter).

[0143] Before step 605, optionally, in response to the user setting the lock screen credentials for the privacy space (e.g., a lock screen password), the core module of the SE chip can generate a value (lock screen verification parameter) based on the lock screen password corresponding to the privacy space (fourth parameter) and the weaver key (fifth parameter). When switching to a privacy space, the user can enter the lock screen password for the privacy space. The lock screen application can request the corresponding value from the SE chip based on the slotId and weaver key corresponding to the lock screen password to verify the lock screen password of the privacy space.

[0144] 606. The weaver TA sends the slotId and weaver key to the weaver applet.

[0145] The weaver TA may send a second I2C instruction (a second request message) to the weaver applet of the SE, wherein the second I2C instruction includes a second I2C message header and a second APDU instruction, and the second APDU instruction includes an encapsulated slotId and a weaver key.

[0146] 607. The weaver applet sends the slotId and weaver key to the core module.

[0147] After receiving the second I2C instruction, the weaver applet can strip (remove) the second I2C message header of the second I2C instruction to obtain a second APDU instruction, decapsulate the second APDU instruction to obtain a slotId and a weaver key, and send the slotId and the weaver key to the core module.

[0148] 608. The core module interrupts the calculation of the RSA key pair, queries the value corresponding to the slotId and the weaver key, and returns the value to the weaver applet.

[0149] After receiving the slotId and weaver key, the core module can interrupt the calculation of the RSA key pair and first query whether the slotId and weaver key have a corresponding value. If the core module can query the value corresponding to the slotId and weaver key, it returns the value to the weaver applet.

[0150] In some embodiments, the weaver request message and the RSA key pair request message may carry priority information. The priority information may be, for example, a number, where a larger number indicates a higher priority. The weaver request message may have a higher priority than the RSA key pair request message. That is, the core module may respond to the weaver request message (including slotId and weaver key) first, and then respond to the RSA key pair request message (including RSA key pair request parameters).

[0151] In some implementations, after the core module interrupts the calculation of the RSA key pair, it may discard the calculation result of the RSA key pair and recalculate the RSA key according to the RSA key pair request parameters saved in step 604 .

[0152] In other implementations, after the core module interrupts the calculation of the RSA key pair, the calculation result (intermediate result) of the RSA key pair can be saved so as to continue to calculate the RSA key according to the saved calculation result.

[0153] 609. The weaver applet sends value to the weaver TA.

[0154] The SE's weaver applet may send a third I2C instruction (first response message) to the weaver TA, wherein the third I2C instruction includes a third I2C message header and a third APDU instruction, and the third APDU instruction includes a lock screen verification parameter (eg, value).

[0155] 610. The weaver TA sends the verification result determined according to the value to the lock screen application through the lock screen service.

[0156] The weaver TA returns the value to the lock screen service so that the lock screen service can verify whether the lock screen credentials entered by the user are valid based on the value and send the verification result to the lock screen application.

[0157] 611. The lock screen application decides whether to unlock based on the verification result.

[0158] The verification results can include verification success or verification failure.

[0159] If the verification result is successful, the lock screen application can unlock the electronic device. If the verification result is failed, the lock screen application can prompt the user that the lock screen credentials are entered incorrectly and remind the user to try again.

[0160] 612. The core module recalculates or continues to calculate the RSA key pair.

[0161] In some embodiments, after the core module processes the weaver request (i.e., in step 608, after the core module returns the value to the weaver applet), it obtains the RSA key pair request parameters it saves (the RSA key pair request parameters saved in step 604), recalculates the RSA key pair based on the RSA key pair request parameters, and returns the RSA key pair to the strongbox applet after the calculation is completed.

[0162] In other embodiments, after the core module processes the weaver request, it obtains the RSA key pair calculation result saved by it (the calculation result of the RSA key pair saved in step 608), continues to calculate the RSA key pair based on the RSA key pair calculation result, and returns the RSA key pair to the strongbox applet after the calculation is completed.

[0163] 613. The core module sends the RSA key pair to the strongbox applet storage / cache.

[0164] The core module sends the RSA key pair to the strongbox applet. After receiving the RSA key pair, the strongbox applet stores / caches the RSA key pair calculation result.

[0165] 614. The strongbox TA queries the security chip for the RSA key pair calculation result.

[0166] Strongbox TA can proactively query the security chip for the existence of RSA key pair calculation results.

[0167] In the embodiment of the present application, the original synchronous message processing flow of the strongbox TA can be modified into an asynchronous message processing flow.

[0168] The synchronous message processing process means that after the strongbox TA sends the RSA key pair request parameters to the strongbox applet of the SE, it synchronously waits for the SE to return the processing result.

[0169] To adapt to the weaver preemption process, the synchronous message processing process can be modified to an asynchronous message processing process. The asynchronous message processing process means that after the strongbox TA sends the RSA key pair request parameters to the strongbox applet, it polls the SE chip at a fixed time slice to check whether there is an RSA key pair calculation result.

[0170] In a possible implementation, the strongbox TA polls the security chip at a fixed time slice to check whether there is an RSA key pair calculation result.

[0171] The strongbox TA can set a timer that polls based on a fixed time slice (fixed time interval). Based on this timer, it polls the SE at fixed time intervals (e.g., 1 second). For example, it sends a request (poll request) to the strongbox applet to read the RSA key pair calculation result. That is, the strongbox TA can request the strongbox applet to obtain the RSA key pair calculation result once every fixed time interval (e.g., 1 second).

[0172] 615. The strongbox applet returns the RSA key pair to the strongbox TA.

[0173] After receiving the RSA key pair calculation result reading request (polling request) sent by strongbox TA, strongbox applet can send a fourth I2C instruction (second response message) to strongbox TA, the fourth I2C instruction includes a fourth I2C message header and a fourth APDU instruction, and the fourth APDU instruction includes the RSA key pair (first key pair).

[0174] 616. Strongbox TA returns the RSA key pair to GMS.

[0175] 617. After receiving the RSA key pair, the GMS saves the RSA key pair and can sign and verify the signature based on the RSA key pair.

[0176] After receiving the RSA key pair, the strongbox TA can delete the timer that polls the SE based on a fixed time slice. This can avoid the problem of the strongbox TA continuing to poll the SE and causing power consumption waste.

[0177] It should be noted that there is no necessary execution order between steps 609-611 and steps 612-616. Steps 609-611 and steps 612-616 can be executed simultaneously. This embodiment does not specifically limit the execution order between the steps.

[0178] In other embodiments, multiple RSA key pairs may be pre-stored (saved) in the SE.

[0179] Optionally, the core module can record the correspondence between the RSA key pair request parameters and the read RSA key pair, so that when the same RSA key pair request parameters are received next time, the same RSA key pair is assigned to the RSA key pair request parameters. In this way, it can be ensured that the same RSA key pair is read during multiple verifications of the same business, thereby ensuring the normal operation of the business. If the core module does not record the correspondence between the RSA key pair request parameters and the RSA key pair, an RSA key pair can be randomly selected from the RSA key pairs for which no corresponding relationship exists among the pre-stored multiple RSA key pairs.

[0180] In some embodiments, after receiving the RSA key pair request parameter, the core module may read an RSA key pair from a plurality of pre-stored RSA key pairs based on the RSA key pair request parameter, and return the RSA key pair to the strongbox applet.

[0181] In other embodiments, if a weaver request is received while the core module is reading the RSA key pair, the core module may interrupt the RSA key pair reading process and prioritize responding to the weaver request message. For details, please refer to step 608, which will not be described in detail here. After the core module processes the weaver request, it may again read an RSA key pair from multiple pre-stored RSA key pairs based on the RSA key pair request parameters, and then return the RSA key pair to the strongbox applet.

[0182] Based on the method provided in the embodiment of the present application, when a lock screen unlock request conflicts with an RSA key pair generation request, the lock screen unlock request can be processed first. This can avoid the problem of lock screen unlock delay or unresponsiveness caused by conflicts between lock screen unlock and Strongbox service requests, and can improve the user experience.

[0183] After testing by the inventor, it was found that in the related art, when strongbox TA and weaver TA concurrently access SE (i.e., when strongbox TA and weaver TA access SE and conflict occurs), weaver TA's request usually needs to be responded to after a long time (e.g., about 17283ms). This is because when strongbox TA and weaver TA access SE and conflict occurs, it is necessary to wait for the RSA key pair to be calculated before responding to weaver TA's request (lock screen unlock request). This cannot meet the user's expectation of real-time unlocking and will reduce the user experience. Based on the method provided in the embodiment of the present application, when strongbox TA and weaver TA concurrently access SE (i.e., when strongbox TA and weaver TA access SE and conflict occurs), weaver TA's request will be responded to after a short time (e.g., about 113ms). This is because when strongbox TA and weaver TA access SE and conflict occurs, SE can temporarily interrupt the calculation of the RSA key pair, first respond to weaver TA's request (lock screen unlock request), and then calculate the RSA key pair. In this way, the problem of lock screen unlocking delay or unresponsiveness caused by the conflict between the lock screen unlocking and the RSA key pair generation request can be avoided, which can improve the user experience.

[0184] Another embodiment of the present application provides a message processing method that can avoid the problem of lock screen unlocking delay or no response caused by the conflict between the lock screen unlocking request and the RSA key pair generation request. The method provided in the embodiment of the present application can be applied to an electronic device, which includes an SE chip and a first TA, the first TA is located in the TEE, and the SE chip pre-stores multiple key pairs, and the multiple key pairs include the first key pair. The following is an example of the first TA being a strongbox TA. As shown in Figure 7, the method includes the following steps:

[0185] 701. The SE chip receives a first request message from the strongbox TA.

[0186] For related descriptions, please refer to the relevant instructions of step 101, which will not be repeated here.

[0187] 702. In response to the first request message, the SE chip sends a first response message to the strongbox TA.

[0188] In a possible implementation, the first response message is an I2C command (a fourth I2C command).

[0189] The first response message indicates a first key pair, which is read from a plurality of key pairs pre-stored in the SE chip.

[0190] Based on the method provided in the embodiments of the present application, the SE chip can send a second response message indicating a first key pair to the first TA in response to the first request message, where the first key pair is one of multiple pre-stored key pairs. In this way, the SE chip does not need to spend a long time calculating the RSA key pair, and can avoid the problem of the core module being unable to respond to the lock screen unlock request during the calculation of the RSA key pair, resulting in a lock screen unlock delay or no response.

[0191] Another embodiment of the present application provides a message processing method that can avoid the problem of lock screen unlocking delay or unresponsiveness. As shown in FIG8 , the method includes the following steps:

[0192] 801. The core module of SE pre-stores multiple RSA key pairs.

[0193] In some embodiments, the strongbox TA can generate multiple RSA key pairs and send them to the core module via the strongbox applet. After receiving the multiple RSA key pairs, the core module can store (write) them to the SE's storage unit. In other words, the strongbox TA on the TEE side can generate multiple RSA key pairs and store them in the SE's storage unit in advance.

[0194] In other embodiments, the core module can generate multiple RSA key pairs and store (write) them to the storage unit of the SE. In one possible implementation, after the electronic device is turned on, the CPU of the SE (i.e., the core module) can calculate and store several RSA key pairs in an idle state. That is, the core module can generate multiple RSA key pairs and store them in the storage unit of the SE in advance. It should be understood that the generation of multiple RSA key pairs by the SE ensures that the generation of the RSA key pairs is completely within the SE, which can ensure the hardware-level confidentiality of the RSA key pairs.

[0195] Optionally, after step 801, steps 802-804 may be executed. For steps 802-804, reference may be made to the relevant description of steps 601-603, which will not be repeated here.

[0196] 805. The core module reads an RSA key pair from a plurality of pre-stored RSA key pairs according to the RSA key pair request parameter.

[0197] In one possible design, when the core module receives the RSA key pair request parameter, it can read an RSA key pair from multiple RSA key pairs stored in the storage unit.

[0198] In one possible implementation, the core module can record the correspondence between the RSA key pair request parameter and the read RSA key pair. This allows the core module to assign the same RSA key pair to the next request parameter upon receiving the same RSA key pair request parameter. This ensures that the same RSA key pair is read during multiple verifications of the same service, thereby ensuring the normal operation of the service.

[0199] In another possible design, multiple RSA key pairs stored in the storage unit can correspond to multiple indexes, with different indexes pointing to different RSA key pairs. When the core module receives the RSA key pair request parameter, it allocates an index according to the RSA key pair request parameter and obtains the RSA key pair pointed to by the index according to the allocated index (i.e., reads the RSA key pair pointed to by the index from the storage unit). The index helps to improve the distribution efficiency of the RSA key pair.

[0200] Furthermore, the core module can record the correspondence between the RSA key pair request parameters and the assigned index, so that the next time the RSA key pair request parameters are received, the same index is assigned to the RSA key pair request parameters and the RSA key pair is retrieved based on the index. This ensures that the same RSA key pair is read during multiple verifications of the same service, thereby ensuring the normal operation of the service. Compared to the core module recording the correspondence between the RSA key pair request parameters and the RSA key pair, the core module recording the correspondence between the RSA key pair request parameters and the index can save storage space.

[0201] Optionally, the embodiment of the present application further includes the following steps:

[0202] 806. The core module sends the RSA key pair to the strongbox applet.

[0203] 807. The strongbox applet returns the RSA key pair to the strongbox TA.

[0204] The strongbox applet can return the RSA key pair to the strongbox TA via the I2C channel.

[0205] 808. Strongbox TA returns the RSA key pair to GMS.

[0206] 809. GMS signs and verifies the signature based on the RSA key pair.

[0207] Based on the method provided in the embodiment of the present application, multiple RSA key pairs can be pre-stored in the SE. When the core module receives the RSA key pair request parameters, an RSA key pair can be read from the multiple RSA key pairs according to the RSA key pair request parameters. In this way, when a lock screen unlock request and an RSA key pair generation request conflict, the core module does not need to spend a long time calculating the RSA key pair, which can avoid the problem of the core module being unable to respond to the lock screen unlock request during the calculation of the RSA key pair, resulting in a delayed or unresponsive lock screen unlock.

[0208] An embodiment of the present application provides another message processing method that can avoid the problem of lock screen unlocking delay or no response caused by a conflict between a lock screen unlocking request and an RSA key pair generation request. As shown in FIG9 , the method includes the following steps:

[0209] For steps 901-907, reference may be made to the relevant description of steps 601-607, which will not be repeated here.

[0210] 908. After receiving the slotId and weaver key, the core module sends an indication message to the weaver applet, where the indication message indicates that the chip is busy.

[0211] After receiving the slotId and weaver key, the core module does not interrupt the calculation of the RSA key pair, but can send an indication message to the weaver TA through the weaver applet that the chip (SE chip) is busy.

[0212] 909. The weaver applet sends instruction information to the weaver TA.

[0213] 910. The weaver TA returns the instruction information to the lock screen application.

[0214] 911. The lock screen application prompts the user to wait according to the instruction information.

[0215] For example, as shown in FIG10 , the lock screen application may display an interface 1001 , and the interface 1001 may include a prompt message 1002 , and the prompt message 1002 may prompt the user “Processing, please wait”.

[0216] 912. After the core module calculates the RSA key, it sends the RSA key pair to the strongbox applet.

[0217] After step 912, steps 913 to 915 may be performed. For steps 913 to 915, reference may be made to the relevant description of steps 615 to 617, which will not be repeated here.

[0218] Based on the method provided in the embodiments of this application, the core module can respond to weaver requests in a timely manner, avoiding the problem of frozen screen and stuck mobile phones. In addition, in the event of abnormal or timeout scenarios (for example, the chip is busy), timely prompts can be given to the user, which can reduce the user's perceived waiting time and improve the user experience.

[0219] In some embodiments, as shown in FIG. 11A , the above step 601 may include steps 1101 - 1104 ; the above step 602 may include steps 1105 - 1110 .

[0220] 1101. In response to the user's operation of installing the GMS, the GMS calls the keystore API to request the keystore to generate an RSA key pair.

[0221] For example, using a mobile phone as an example, as shown in Figure 4A , in response to a user's operation (e.g., a click) on the installation control 402 corresponding to "GMS" in the app store's application installation interface 401, the mobile phone can download and install the GMS installation package. As shown in Figure 4A (b), when the GMS installation package download progress reaches 100%, i.e., after the GMS installation package download is complete, GMS can call the strongbox TA to request the SE chip to generate an RSA key pair.

[0222] During GMS installation, GMS can call the Keystore API to request the Keystore to generate an RSA key pair. An RSA key pair includes a public key and a private key. The RSA key pair is used to sign and verify applications that use GMS services (e.g., applications installed via GMS).

[0223] This application embodiment uses GMS calling the Android keystore API to request the generation of an RSA key pair as an example, but this application is not limited to this. For example, in some scenarios, a payment application or a life service application can call the Android keystore API to request the generation of a key pair (e.g., an RSA key pair).

[0224] 1102. The keystore sends an RSA key pair request message to the strongbox CA.

[0225] The keystore can send RSA key pair request messages to the strongbox CA through the strongbox HAL.

[0226] The keystore can call the KeyPairGenerator class to generate an RSA key pair request message and send the RSA key pair request message to the strongbox HAL. The strongbox HAL can send the RSA key pair request message to the strongbox CA.

[0227] The RSA key pair request message may include RSA key pair request parameters, and the RSA key pair request parameters may include parameters such as key type, key length, key purpose, key alias, key validity period, key digest, and padding.

[0228] For example, the RSA key pair request parameters may be as shown in Table 1:

[0229] Table 1

[0230] Among them, the key type can be RSA, the key length can be 2048 bits, the key purpose can be SIGN and VERIFY (signature and verification), the key alias can be, for example, alias (the key alias can be other names, which is not limited in this application), the key validity period, key summary and padding can be empty (None).

[0231] Optionally, the RSA key pair request message may further include signature key information and certificate issuer information, and the signature key information and certificate issuer may be empty.

[0232] The RSA key pair request message may be encoded in the concise binary object representation (CBOR) format defined by Google.

[0233] 1103. Strongbox CA encapsulates the key pair request parameters in the RSA key pair request message into TEE parameters.

[0234] The TEE parameter carries the RSA key pair request parameter.

[0235] 1104. Strongbox CA sends the TEE parameters to Strongbox TA.

[0236] Strongbox CA can send TEE parameters to Strongbox TA by calling TEE Client API.

[0237] 1105. The strongbox TA parses the TEE parameters to obtain RSA key pair request parameters, and encapsulates the RSA key pair request parameters into the first APDU instruction.

[0238] The first APDU instruction may include a CLA field, an INS field, a P1 field, a P2 field, an Lc field, and a Data field.

[0239] Among them, the CLA field indicates the instruction type; the INS field indicates the instruction code; the P1 and P2 fields indicate the instruction parameters, and P1 and P2 can be the default value 0; the Lc field indicates the length of the Data field; the Data field can be filled with RSA key pair request parameters.

[0240] 1106. The strongbox TA sends the first APDU instruction to the secflash service (first service).

[0241] The first APDU instruction carries an RSA key pair request parameter.

[0242] 1107. The secflash service adds a first I2C message header to the first APDU instruction to obtain a first I2C instruction.

[0243] For example, the length of the first I2C message header may be 4 bytes, wherein the first byte indicates the message sending direction, the second and third bytes indicate the default attributes, and the fourth byte indicates the length of the first APDU instruction.

[0244] 1108. The secflash service sends a first I2C instruction to the I2C driver.

[0245] 1109a. The I2C driver sends a first I2C command to the strongbox applet.

[0246] The I2C driver can transparently transmit the first I2C command to the strongbox applet of the security chip.

[0247] 1109b. The strongbox applet parses the first I2C instruction to obtain RSA key pair request parameters.

[0248] After receiving the first I2C instruction at the first moment, the strongbox applet may strip (remove) the I2C message header of the first I2C instruction to obtain a first APDU instruction, and parse the first APDU instruction to obtain an RSA key pair request parameter.

[0249] 1110. The strongbox applet sends RSA key pair request parameters to the core module.

[0250] In some embodiments, as shown in FIG. 11B , the above step 615 may include steps 1111 - 1115 ; and the above step 616 may include steps 1116 - 1120 .

[0251] 1111. The strongbox applet encapsulates the RSA key pair into a third APDU instruction, and then adds a third I2C message header to the third APDU instruction to obtain a third I2C instruction.

[0252] The third APDU instruction may include a CLA field, an INS field, a P1 field, a P2 field, an Lc field, and a Data field. The Data field may be filled with an RSA key pair. For the remaining fields, refer to the description of step 1105.

[0253] Exemplarily, the length of the third I2C message header may be 4 bytes, wherein the first byte indicates the message sending direction, the second and third bytes indicate the default attributes, and the fourth byte indicates the length of the third APDU instruction.

[0254] 1112. The strongbox applet sends a third I2C command to the I2C driver.

[0255] The strongbox applet may send a third I2C instruction to the I2C driver at a third moment.

[0256] 1113. The I2C driver sends a third I2C instruction to the secflash service.

[0257] 1114. After receiving the third I2C instruction, the secflash service strips off the third I2C message header of the third I2C instruction to obtain a third APDU instruction.

[0258] 1115. The secflash service sends a third APDU instruction to the strongbox TA.

[0259] 1116. After receiving the third APDU instruction, the strongbox TA parses the third APDU instruction to obtain an RSA key pair, and encapsulates the RSA key pair into TEE parameters.

[0260] 1117. Strongbox TA sends TEE parameters to Strongbox CA.

[0261] 1118. After receiving the TEE parameters sent by the strongbox TA, the strongbox CA parses the TEE parameters to obtain the RSA key pair.

[0262] 1119. Strongbox CA sends the RSA key pair to the keystore.

[0263] Strongbox CA can send RSA key pairs to the keystore through Strongbox HAL. Strongbox HAL can fill the RSA key pairs into the Android Interface Definition Language (AIDL) interface and send the RSA key pairs to the keystore through the AIDL interface.

[0264] 1120. The keystore sends the RSA key pair to the GMS through the keystore API.

[0265] The keystore can obtain the RSA key pair by parsing the AIDL interface and return the RSA key pair to the keystore API. The keystore API returns the RSA key pair to GMS so that GMS can sign and verify the signature based on the RSA key pair.

[0266] In some embodiments, as shown in FIG12A , the above step 605 may include steps 1201 - 1207 ; the above step 606 may include steps 1208 - 1212 .

[0267] It should be understood that when the user sets the lock screen credentials (for example, the lock screen password), the core module of the SE can generate a value (lock screen verification parameter) based on the slotId and weaver key corresponding to the lock screen password. The value can be used to verify the lock screen credentials (for example, the lock screen password). The value can be a secure random number. The core module can save the correspondence between the slotId, weaver key, and value. When unlocking, the user can enter the lock screen password set in the interface of the lock screen application. The lock screen application can request the corresponding value from the SE based on the slotId and weaver key corresponding to the lock screen password to verify the lock screen password.

[0268] 1201. In response to a user inputting a lock screen credential into a lock screen application, the lock screen application sends the lock screen credential to a lock screen service.

[0269] Among them, the lock screen credentials include the lock screen password, lock screen pattern, personal identification number (PIN), etc. The lock screen password can include a preset number (for example, 4 or more) of numbers or letters. The PIN can include a preset number (for example, 4 or more) of numbers. Generally speaking, the longer the PIN and lock screen password, the more secure it can be. The lock screen pattern refers to a simple pattern drawn by the user with his finger (for example, a Z-shaped pattern, an X-shaped pattern, etc.).

[0270] For example, as shown in FIG4B (a), the lock screen application of the mobile phone may display a lock screen interface 408. Lock screen interface 408 may include an unlock icon 409 (displayed as a closed icon) and a prompt text "Swipe up to unlock" 410. In response to the user's swipe up operation, as shown in FIG4B (b), the lock screen application of the mobile phone may display an interface 411, which may include a prompt text "Enter password" 413 and a soft keyboard 416. The user can enter the lock screen password through soft keyboard 416 to unlock the phone.

[0271] 1202. The lock screen service determines slotId (card slot identifier) ​​and Pwkey (first key value) according to the lock screen credential.

[0272] After receiving the lock screen credential sent by the lock screen application, the lock screen service determines the user's userId based on the lock screen credential and obtains the corresponding slotId based on the userId. The lock screen service can then use an encryption algorithm (for example, the scrypt algorithm) to calculate the lock screen credential and generate a PWkey.

[0273] 1203. The lock screen service sends the slotId and PWkey to the weaver service.

[0274] 1204. After receiving the slotId and PWkey from the lock screen service, the weaver service determines the weaver key (second key value) according to the PWkey.

[0275] For example, the weaver service may intercept a portion of the PWkey as the weaver key.

[0276] 1205. The weaver service sends the slotId and weaver key to the weaver CA.

[0277] The weaver service can send slotId and weaver key to the weaver CA through the weaver HAL.

[0278] The weaver service can send slotId and weaver key to the weaver HAL, and the weaver HAL can send slotId and weaver key to the weaver CA. The weaver HAL can send slotId and weaver key to the weaver CA based on the AIDL interface.

[0279] 1206. Weaver CA encapsulates slotId and weaver key into TEE parameters.

[0280] 1207. The weaver CA sends TEE parameters to the weaver TA.

[0281] Weaver CA can send TEE parameters to weaver TA by calling TEE Client API.

[0282] 1208. The weaver TA parses the TEE parameters to obtain the slotId and weaver key, and encapsulates the second APDU instruction according to the slotId and weaver key.

[0283] For example, the format of the second APDU instruction may be as shown in Table 2:

[0284] Table 2

[0285] Among them, the CLA field indicates the instruction type; 0x80 indicates the Global Platform command (GlobalPlatform command), which is an inter-industry command (GP standard command); the INS field indicates the instruction code, and 0x06 indicates the weaver read interface instruction defined by Google; the P1 and P2 fields indicate the instruction parameters, and P1 and P2 can be the default value 0; the Lc field indicates the length of the Data field; the Data field is filled with the SlotId and key (weaver key) passed by the upper-layer lock screen service; the Le field indicates the expected return message length; the expected return message can include a 16-byte value and a 2-byte lock screen unlock request response status (status), and the expected return message length can be 0x12.

[0286] 1209. The weaver TA sends a second APDU instruction to the secflash service.

[0287] 1210. The secflash service adds a second I2C message header to the second APDU instruction to obtain a second I2C instruction.

[0288] Exemplarily, the format of the second I2C command (I2C message) may be as shown in Table 3:

[0289] Table 3

[0290] The second I2C message header can be 4 bytes long. The first byte 0x21 indicates that the message is sent from the host to the slave. The second and third bytes 00 00 indicate default attributes. The fourth byte 18 indicates the length of the second APDU instruction. The host can be a SoC of an electronic device, and the slave can be an SE.

[0291] 1211. The secflash service sends a second I2C instruction to the I2C driver.

[0292] 1212. The I2C driver sends a second I2C command to the weaver applet.

[0293] The I2C driver may send a second I2C instruction to the weaver applet at a second moment.

[0294] In some embodiments, as shown in FIG12B , the above step 609 may include steps 1213 - 1216 ; the above step 610 may include steps 1217 - 1222 .

[0295] 1213. The weaver applet sends a fourth I2C instruction to the I2C driver. The fourth I2C instruction includes the value and status corresponding to the slotId and key.

[0296] The weaver applet can encapsulate the value (the value corresponding to the slotId and key) and status into a fourth APDU instruction, add a fourth I2C message header to the fourth APDU instruction to obtain a fourth I2C instruction, and then send the fourth I2C instruction to the I2C driver. In other words, the weaver applet can call the I2C driver to return the value and status.

[0297] For example, the format of the fourth APDU instruction may be as shown in Table 4:

[0298] Table 4

[0299] The status field indicates whether the lock screen unlock request was successful, that is, whether the SE was able to retrieve the value based on the slotId and weaver key. A status field of 00 indicates OK, meaning the SE retrieved the value. The data field contains the 16-byte value. The ret field is the status word, consisting of two bytes: SW1 and SW2. A value of 0x9000 for both SW1 and SW2 indicates a successful APDU response. A value of 0x6982 for both SW1 and SW2 indicates an unsuccessful APDU response.

[0300] For example, the format of the fourth I2C instruction may be as shown in Table 5:

[0301] Table 5

[0302] The length of the fourth I2C message header may be 4 bytes. The first byte 0x12 indicates that the message is sent from the slave to the host, the second and third bytes 40 00 indicate message attributes, and the fourth byte 13 indicates the length of the fourth APDU instruction.

[0303] The weaver applet may send a fourth I2C instruction to the I2C driver at a fourth moment.

[0304] 1214. The I2C driver sends a fourth I2C instruction to the secflash service.

[0305] 1215. The secflash service strips the fourth I2C message header of the fourth I2C instruction to obtain a fourth APDU instruction.

[0306] 1216. The secflash service sends a fourth APDU instruction to the weaver TA.

[0307] 1217. The weaver TA parses the fourth APDU instruction to obtain value and status, and encapsulates value and status into TEE parameters.

[0308] After receiving the fourth APDU command, the weaver TA checks sw1 and sw2 of the fourth APDU command. If the values ​​of sw1 and sw2 are 9000, that is, the APDU response is successful, it further parses the data field of the fourth APDU command to obtain value and status.

[0309] In addition, if the values ​​of sw1 and sw2 of the fourth APDU instruction are not 9000, it means that the APDU response is wrong (failed), and the corresponding error message processing flow can be performed, which will not be described in detail here.

[0310] Weaver TA can encapsulate value and status into TEE parameters and return the TEE parameters to the caller weaver CA through the TEE channel.

[0311] 1218. After receiving the TEE parameters, the weaver CA parses the TEE parameters to obtain the value and status (status parameters).

[0312] 1219. Weaver CA sends value and status to the weaver service.

[0313] Weaver CA can send value and status to the weaver service through weaver HAL.

[0314] Weaver CA can send value and status to weaver HAL, and weaver HAL can backfill value and status to weaver AIDL interface so that value and status can be sent to weaver service through weaver AIDL interface.

[0315] 1220. The weaver service strips the status and returns the value to the lock screen service.

[0316] The weaver service can get the value and status by parsing the weaver AIDL interface.

[0317] 1221. The lock screen service verifies the lock screen credential entered by the user according to the value to obtain a verification result.

[0318] After the lock screen service obtains the value, it can verify whether the lock screen credentials entered by the user are valid based on the value.

[0319] Optionally, the lock screen service can also obtain other lock screen verification parameters (for example, PwdToken saved on the REE side, which is derived from the lock screen credentials entered by the user), and verify whether the lock screen credentials entered by the user are valid based on the value and the obtained lock screen verification parameters. This can ensure the security of the lock screen credentials and prevent the lock screen credentials from being easily cracked.

[0320] 1222. The lock screen service sends the verification result to the lock screen application.

[0321] Some embodiments of the present application provide an electronic device that may include a touch screen, a memory, and one or more processors. The touch screen, memory, and processor are coupled. The memory is used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device may perform the various functions or steps performed by the electronic device in the above-described method embodiments. The structure of the electronic device may refer to the structure of electronic device 100 shown in Figure 2.

[0322] An embodiment of the present application also provides a security element (SE), as shown in Figure 13, the security element includes an acquisition module 1301 and a core module 1302, the acquisition module 1301 can obtain a first request message from a first TA at a first moment, and obtain a second request message from a second TA at a second moment, the second moment being later than the first moment; the core module 1302 responds to the second request message and sends a first response message at a third moment, the first response message indicating a lock screen verification parameter to the second TA, the core module 1302 responds to the first request message and sends a second response message at a fourth moment, the second response message indicating a first key pair to the first TA; wherein the fourth moment is later than the third moment.

[0323] Optionally, the acquisition module 1301 includes a first applet and a second applet, and the acquisition module 1301 acquires a first request message from the first TA at a first moment, including: the first applet acquires a first request message from the first TA at a first moment, and the first request message is a first integrated circuit bus I2C instruction; the acquisition module 1301 acquires a second request message from the second TA at a second moment, including: the second applet acquires a second request message from the second TA at a second moment, and the second request message is a second I2C instruction; before the core module 1302 responds to the second request message and sends the first response message at a third moment, the second applet The first applet parses the second I2C instruction to obtain the fourth parameter and the fifth parameter, and sends the fourth parameter and the fifth parameter to the core module 1302, which receives the fourth parameter and the fifth parameter; wherein the fourth parameter and the fifth parameter are related to the lock screen verification parameter; before the core module 1302 responds to the first request message and sends the second response message at the fourth moment, the first applet parses the first I2C instruction to obtain the first parameter, the second parameter and the third parameter, and sends the first parameter, the second parameter and the third parameter to the core module 1302, which receives the first parameter, the second parameter and the third parameter; wherein the first parameter, the second parameter and the third parameter are related to the first key pair.

[0324] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0325] An embodiment of the present application also provides an electronic device, which includes: a security element SE, one or more processors and a memory; the memory is used to store computer program code, and the computer program code includes computer instructions. When one or more processors execute the computer instructions, the electronic device executes the message processing method of the above embodiment.

[0326] An embodiment of the present application also provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device, the electronic device executes the various functions or steps executed by the electronic device in the above-mentioned method embodiment.

[0327] An embodiment of the present application further provides a computer program product. When the computer program product is run on an electronic device, the electronic device is enabled to perform the functions or steps performed by the electronic device in the above method embodiment.

[0328] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned 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.

[0329] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0330] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0331] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0332] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0333] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A message processing method, characterized in that: Applied to an electronic device, the electronic device includes a security element (SE) chip, a first trusted application (TA) and a second trusted application (TA), the first TA and the second TA being located in a trusted execution environment (TEE), and the method includes: At a first moment, the SE chip receives a first request message from the first TA; At a second moment, the SE chip receives a second request message from the second TA; wherein the second moment is later than the first moment; In response to the second request message, the SE chip sends a first response message to the second TA at a third time, where the first response message indicates a lock screen verification parameter; In response to the first request message, the SE chip sends a second response message to the first TA at a fourth time, where the second response message indicates the first key pair; wherein the fourth time is later than the third time.

2. The method according to claim 1, characterized in that The first request message, the second request message, the first response message, and the second response message are integrated circuit bus I2C commands; The first request message includes a first parameter, a second parameter, and a third parameter, where the first parameter, the second parameter, and the third parameter are related to the first key pair; The second request message includes a fourth parameter and a fifth parameter, and the fourth parameter and the fifth parameter are related to the lock screen verification parameter.

3. The method according to claim 1 or 2, characterized in that The second request message and the first response message are transmitted on a first logical channel; The first request message and the second response message are transmitted on a second logical channel, and the second logical channel is different from the first logical channel.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: After receiving the first request message, the SE chip calculates the first key pair; The sending, by the SE chip, a first response message to the second TA in response to the second request message includes: After receiving the second request message, the SE chip interrupts the calculation of the first key pair, obtains the lock screen verification parameter, and sends the first response message to the second TA.

5. The method according to claim 4, characterized in that The method further comprises: After the SE chip interrupts the calculation of the first key pair, it discards the calculation result of the first key pair; After sending the first response message to the second TA, the SE chip recalculates the first key pair.

6. The method according to claim 4, characterized in that The method further comprises: After the SE chip interrupts the calculation of the first key pair, it saves the calculation result of the first key pair; After sending the first response message to the second TA, the SE chip continues to calculate the first key pair according to the saved calculation result.

7. The method according to any one of claims 1 to 3, characterized in that The SE chip pre-stores a plurality of key pairs, the plurality of key pairs including the first key pair, and the method further includes: After receiving the first request message, the SE chip reads the first key pair; The sending, by the SE chip, a first response message to the second TA in response to the second request message includes: After receiving the second request message, the SE chip interrupts reading the first key pair, obtains the lock screen verification parameter, and sends the first response message to the second TA; After sending the first response message to the second TA, the SE chip re-reads the first key pair.

8. The method according to claim 7, characterized in that The multiple key pairs are generated by the first TA and sent to the SE; or The multiple key pairs are generated by the SE.

9. The method according to claim 2, characterized in that The method further comprises: After sending the first request message to the SE chip, the first TA polls the SE chip for the first key pair.

10. The method according to claim 2, characterized in that The electronic device further includes a first service and an I2C driver, and the SE chip receiving a first request message from the first TA includes: The first TA generates a first application protocol data unit APDU instruction, where the first APDU instruction includes the first parameter, the second parameter, and the third parameter; The first TA sends the first APDU instruction to the first service; In response to the first APDU instruction, the first service adds a first I2C message header to the first APDU instruction to obtain a first I2C instruction; The first service sends the first I2C instruction to the I2C driver; In response to the first I2C instruction, the I2C driver sends the first I2C instruction to the SE chip; The SE chip receives the first I2C instruction from the I2C driver; The SE chip receiving the second request message from the second TA includes: The second TA generates a second APDU instruction, where the second APDU instruction includes the fourth parameter and the fifth parameter; The second TA sends the second APDU instruction to the first service; In response to the second APDU instruction, the first service adds a second I2C message header to the second APDU instruction to obtain a second I2C instruction; The first service sends the second I2C instruction to the I2C driver; In response to the second I2C instruction, the I2C driver sends the second I2C instruction to the SE chip; The SE chip receives the second I2C instruction from the I2C driver.

11. The method according to claim 10, characterized in that The SE includes a core module, a first applet and a second applet, and the SE chip receives the first I2C instruction from the I2C driver, including: The first applet receives the first I2C instruction from the I2C driver; In response to the first I2C instruction, the first applet parses the first I2C instruction to obtain the first parameter, the second parameter, and the third parameter; The first applet sends the first parameter, the second parameter and the third parameter to the core module; The core module calculates or reads the first key pair according to the first parameter, the second parameter and the third parameter; The SE chip receiving the second I2C instruction from the I2C driver includes: The second applet receives the second I2C command from the second TA; In response to the second I2C instruction, the second applet parses the second I2C instruction to obtain the fourth parameter and the fifth parameter; The second applet sends the fourth parameter and the fifth parameter to the core module; The core module reads the lock screen verification parameter according to the fourth parameter and the fifth parameter.

12. The method according to claim 11, characterized in that The SE chip sending the first response message to the second TA at the third moment includes: The first applet receives the first key pair from the core module, encapsulates the first key pair into a third APDU instruction, and then adds a third I2C message header to the third APDU instruction to obtain a third I2C instruction; The first applet sends the third I2C instruction to the I2C driver at the third moment; The I2C driver sends the third I2C instruction to the first service; In response to the third I2C instruction, the first service decapsulates the third I2C instruction to obtain the third APDU instruction, and sends the third APDU instruction to the second TA; The SE chip sending a second response message to the first TA at the fourth moment includes: The second applet receives the lock screen verification parameter from the core module, encapsulates the lock screen verification parameter into a fourth APDU instruction, and then adds a fourth I2C message header to the fourth APDU instruction to obtain a fourth I2C instruction; The second applet sends the fourth I2C instruction to the I2C driver at the fourth moment; The I2C driver sends the fourth I2C instruction to the first service; In response to the fourth I2C instruction, the first service decapsulates the fourth I2C instruction to obtain the fourth APDU instruction, and sends the fourth APDU instruction to the first TA.

13. A message processing method, characterized in that: Applied to an electronic device, the electronic device includes a security element (SE) chip and a first trusted application (TA), the SE chip pre-stores multiple key pairs, the multiple key pairs include a first key pair, and the first TA is located in a trusted execution environment (TEE). The method includes: The SE chip receives a first request message from the first TA; In response to the first request message, the SE chip sends a first response message to the first TA, where the first response message indicates the first key pair.

14. The method according to claim 13, characterized in that The multiple key pairs are generated by the first TA and sent to the SE; or The multiple key pairs are generated by the SE.

15. The method according to claim 13 or 14, characterized in that The first request message and the first response message are integrated circuit bus I2C commands; The first request message includes a first parameter, a second parameter, and a third parameter, where the first parameter, the second parameter, and the third parameter are related to the first key pair.

16. The method according to claim 15, characterized in that The electronic device further includes a first service and an I2C driver, and the SE chip receiving a first request message from the first TA includes: The first TA generates a first application protocol data unit APDU instruction, where the first APDU instruction includes the first parameter, the second parameter, and the third parameter; The first TA sends the first APDU instruction to the first service; In response to the first APDU instruction, the first service adds a first I2C message header to the first APDU instruction to obtain a first I2C instruction; The first service sends the first I2C instruction to the I2C driver; In response to the first I2C instruction, the I2C driver sends the first I2C instruction to the SE chip; The SE chip receives the first I2C instruction from the I2C driver.

17. The method according to claim 16, characterized in that The SE includes a core module, a first applet and a second applet, and the SE chip receives the first I2C instruction from the I2C driver, including: The first applet receives the first I2C instruction from the I2C driver; In response to the first I2C instruction, the first applet parses the first I2C instruction to obtain the first parameter, the second parameter, and the third parameter; The first applet sends the first parameter, the second parameter and the third parameter to the core module; The core module reads the first key pair according to the first parameter, the second parameter and the third parameter.

18. The method according to claim 17, characterized in that The SE chip sending a first response message to the first TA includes: The first applet receives the first key pair from the core module, encapsulates the first key pair into a third APDU instruction, and then adds a third I2C message header to the third APDU instruction to obtain a third I2C instruction; The first applet sends the third I2C instruction to the I2C driver at the third moment; The I2C driver sends the third I2C instruction to the first service; In response to the third I2C instruction, the first service decapsulates the third I2C instruction to obtain the third APDU instruction, and sends the third APDU instruction to the first TA.

19. The method according to claim 17 or 18, characterized in that Before the core module reads the first key pair according to the first parameter, the second parameter, and the third parameter, the method further includes: The SE chip stores a correspondence between the first parameter, the second parameter, the third parameter and the first key pair; or The SE chip stores a correspondence between the first parameter, the second parameter, the third parameter, and a first index, where the first index is used to index the first key pair.

20. A security element, characterized in that: Including acquisition module and core module, The acquisition module acquires a first request message from a first TA at a first time, and the acquisition module acquires a second request message from a second TA at a second time, where the second time is later than the first time; The core module responds to the second request message and sends a first response message at a third moment, where the first response message indicates the lock screen verification parameters to the second TA. The core module responds to the first request message and sends a second response message at a fourth moment, where the second response message indicates the first key pair to the first TA; wherein the fourth moment is later than the third moment.

21. The security element according to claim 20, characterized in that The acquisition module includes a first applet and a second applet. The acquiring module acquiring the first request message from the first TA at the first moment includes: The first applet program obtains a first request message from a first TA at a first moment, where the first request message is a first integrated circuit bus I2C command; The acquiring module acquiring the second request message from the second TA at the second moment includes: The second applet obtains, at a second moment, a second request message from a second TA, where the second request message is a second I2C command; Before the core module sends the first response message at a third time in response to the second request message, the second applet parses the second I2C instruction to obtain a fourth parameter and a fifth parameter, sends the fourth parameter and the fifth parameter to the core module, and the core module receives the fourth parameter and the fifth parameter; wherein the fourth parameter and the fifth parameter are related to the lock screen verification parameter; Before the core module sends a second response message in response to the first request message at a fourth moment, the first applet parses the first I2C instruction to obtain a first parameter, a second parameter, and a third parameter, and sends the first parameter, the second parameter, and the third parameter to the core module, and the core module receives the first parameter, the second parameter, and the third parameter; wherein the first parameter, the second parameter, and the third parameter are related to the first key pair.

22. The security element according to claim 21, characterized in that After receiving the first parameter, the second parameter and the third parameter, the core module calculates the first key pair according to the first parameter, the second parameter and the third parameter; The core module sends a first response message at a third moment in response to the second request message, including: After receiving the fourth parameter and the fifth parameter, the core module interrupts the calculation of the first key pair, obtains the lock screen verification parameter according to the fourth parameter and the fifth parameter, and sends the first response message to the second TA.

23. The security element according to claim 22, characterized in that After the core module interrupts the calculation of the first key pair, the calculation result of the first key pair is discarded; After sending the first response message to the second TA, the core module recalculates the first key pair.

24. The security element according to claim 22, characterized in that After the core module interrupts the calculation of the first key pair, the calculation result of the first key pair is saved; After sending the first response message to the second TA, the core module continues to calculate the first key pair according to the saved calculation result.

25. The security element according to claim 21, characterized in that The security element pre-stores a plurality of key pairs, the plurality of key pairs including the first key pair, and the core module reads the first key pair according to the first parameter, the second parameter, and the third parameter after receiving the first parameter, the second parameter, and the third parameter; The core module sends a first response message at a third moment in response to the second request message, including: After receiving the fourth parameter and the fifth parameter, the core module interrupts reading the first key pair, obtains the lock screen verification parameter, and sends the first response message to the second TA; After sending the first response message to the second TA, the core module rereads the first key pair.

26. An electronic device, characterized in that: The electronic device comprises: a memory and one or more processors; the memory is coupled to the processor; The memory is used 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 executes the method according to any one of claims 1 to 19.

27. A computer-readable storage medium, characterized in that including computer instructions; When the computer instructions are executed on an electronic device, the electronic device is caused to execute the method according to any one of claims 1 to 19.

Images