Key negotiation method and electronic device

Abstract

The present application provides a key negotiation method and electronic device, which generates the same session key based on the key generation requests sent by the access agent module of the first TEE and the TA of the second TEE respectively through the key derivation module, so that the first TEE can negotiate with the second TEE to obtain a consistent session key. In this way, when the first TA and the second TA perform business interactions, the business data can be encrypted / decrypted based on the session key to ensure the security of the business data when it is transmitted between multiple TEEs. The method includes: the access agent module sends a third key generation request to the key derivation module through the virtual machine monitor, the second TA sends a fourth key generation request to the key derivation module through the key management module, and in response to the third key generation request or the fourth key generation request, the key derivation module generates a session key based on the identity of the first TEE, the identity of the second TA and a random number, and the first TA performs business interactions with the second TA based on the session key.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a key negotiation method and electronic device. Background Art

[0002] With the rapid development of the mobile internet, the variety and number of mobile applications are increasing. The security of services processed and data stored on mobile terminals is increasingly threatened, especially in security-critical applications such as payment, office work, and copyright protection. However, the operating systems of smart terminals are designed to focus on functionality and openness. These systems are complex and prone to numerous system vulnerabilities, leading to the continuous emergence of malicious applications that threaten user data security.

[0003] To meet the high security requirements of mobile applications, a trusted execution environment (TEE) can be built on smart terminals. A TEE is an independent runtime environment that can be isolated from a rich execution environment (REE). Trusted applications (TAs) can run on a TEE, and TAs can provide security services to client applications (CAs) running outside the TEE, such as password entry, transaction signature generation, and facial recognition.

[0004] In existing technologies, in order to meet the increasing number and variety of business needs, equipment manufacturers try to adopt a multi-TEE architecture to improve service diversity, but there is a risk of data leakage in this architecture. Summary of the Invention

[0005] The present application provides a key negotiation method and electronic device, which can reduce the risk of data leakage and improve data security.

[0006] To achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, the present application provides a key agreement method, applied to an electronic device including a virtual machine monitor (HVM), a first trusted execution environment (TEE), and a second TEE. The first TEE includes an access proxy module and a first trusted application (TA), and the second TEE includes a second trusted application (TA) and a key derivation module. The method comprises: the access proxy module sending a first key generation request to the HVM; the first key generation request includes the identity of the second TA and a preset random number, and the first key generation request instructs the key derivation module to generate a session key between the first TEE and the second TA. In response to receiving the first key generation request, the HVM adds the identity of the first TEE to the first key generation request to generate a third key generation request. The HVM sends a third key generation request to the key derivation module, the third key generation request including the identity of the first TEE, the identity of the second TA, and the random number. In response to the third key generation request, the key derivation module generates a session key based on the identity of the first TEE, the identity of the second TA, and the random number. The key derivation module sends the session key to the access proxy module. The second TA sends a fourth key generation request to the key derivation module. The fourth key generation request includes the identity of the first TEE, the identity of the second TA, and a random number. The fourth key generation request instructs the key derivation module to generate a session key between the first TEE and the second TA. In response to the fourth key generation request, the key derivation module generates a session key based on the identity of the first TEE, the identity of the second TA, and the random number. The key derivation module sends the session key to the second TA. The first TA interacts with the second TA based on the session key.

[0008] It can be understood that the access proxy module of the first TEE and the second TA of the second TEE can respectively send key generation requests to the key derivation module. Since the key generation request on the first TEE side (i.e., the third key generation request) and the key generation request on the second TEE side (i.e., the fourth key generation request) contain the same information (i.e., both include the identity of the first TEE, the identity of the second TA, and a random number). The session keys generated by the key derivation module based on the two key generation requests are the same, so that the first TEE can negotiate with the second TEE to obtain a consistent session key. In this way, when the first TA and the second TA perform business interactions (such as sending sensitive data, files, information, instructions), the business data can be encrypted / decrypted based on the session key to ensure the security of business data when it is transmitted between multiple TEEs.

[0009] In an optional embodiment, a first TA performs service interaction with a second TA based on a session key, including: the first TA sends a service request to a virtual machine monitor; wherein the service request includes service data encrypted based on the session key, and the service request is used to instruct the second TA to perform service processing on the service data. The virtual machine monitor sends the service request to the second TA.

[0010] As can be seen, since the first TEE actually runs a virtual machine on a virtual machine monitor, it can directly interact with the second TA through the first TA. In addition, the business data during the business interaction is encrypted based on the session key, which can effectively ensure the security of the business data. It should be noted that in other implementations, the second TA can also send business requests to the first TA and similarly encrypt the business data based on the session key.

[0011] In an optional embodiment, the first TA performs business interaction with the second TA based on the session key, including: the first TA sends a business request to the virtual machine monitor; wherein the business request includes business data after encryption operation based on the session key, and the business request is used to instruct the second TA to perform business processing on the business data; the virtual machine monitor sends the business request to the CA; and the CA sends the business request to the second TA.

[0012] The second TEE contains TAs that can only be invoked by the REE-side CA. The first TA cannot access these TAs and must forward service requests through the REE-side CA. Furthermore, since the REE does not know the session key between the first TEE and the second TA, it cannot decrypt the encrypted service data, thus ensuring the security of the service data.

[0013] In an optional embodiment, the second TEE is also integrated with a key management module, and the second TA sends a fourth key generation request to the key derivation module, including: the second TA sends a second key generation request to the key management module; wherein the second key generation request includes the identity of the first TEE and a random number; in response to receiving the second key generation request, the key management module adds the identity of the second TA to the second key generation request to generate a fourth key generation request; the key management module sends the fourth key generation request to the key derivation module.

[0014] The key management module can provide key management services for all TAs in the second TEE, that is, it has the function of generating session keys for all TAs. In fact, after receiving the key generation request (for example, the second key generation request) from the second TA, the key management module can fill in the identity of the second TA (for example, the universal unique identifier) ​​and then send a second key generation request (that is, the fourth key generation request) filled in with the identity of the second TA to the key derivation module that actually generates the session key.

[0015] In an optional implementation, the key derivation module sends the session key to the second TA, including: the key derivation module sends second key information to the key management module; wherein the second key information includes the identity of the second TA and the session key; the key management module sends the session key to the second TA.

[0016] In an optional embodiment, the second TEE further integrates an application programming interface (API), and the second TA sends the fourth key generation request to the key derivation module, including: the second TA sends the fourth key generation request to the key derivation module through the API. It can be seen that the second TA may also send the fourth key generation request directly to the key derivation module through the API of the key derivation module.

[0017] In an optional embodiment, before the access agent module sends the first key generation request to the virtual machine monitor, the method further includes: the access agent module sending a random number to the second TA. That is, before the first TEE and the second TA negotiate the session key, the first TEE may generate a random number and send the random number to the second TA.

[0018] In an optional embodiment, the key derivation module sends a session key to the access proxy module, including: the key derivation module sends first key information to the virtual machine monitor; wherein the first key information includes the identity of the first TEE and the session key; the virtual machine monitor sends the session key to the access proxy module according to the identity of the first TEE.

[0019] In the second aspect, the present application also provides an electronic device, which is integrated with a virtual machine monitor, a first trusted execution environment TEE and a second TEE, the first TEE includes an access agent module and a first TA, the second TEE includes a first trusted application second TA and a key derivation module, the electronic device includes: a wireless communication module, a memory and one or more processors; the wireless communication module, the memory and the processor are coupled; wherein 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 any one of the key negotiation methods in the first aspect.

[0020] In a third aspect, the present application further provides a computer-readable storage medium comprising computer instructions; when the computer instructions are executed on an electronic device, the electronic device executes any one of the key negotiation methods in the first aspect.

[0021] In a fourth aspect, the present application provides a chip system comprising one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via a circuit. The chip system can be applied to an electronic device comprising a communication module and a memory. The interface circuit can read instructions stored in the memory of the electronic device and send the instructions to the processor. When the instructions are executed by the processor, the electronic device can perform any of the methods described in the first aspect.

[0022] In a fifth aspect, the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the key agreement method as described in any one of the first aspects.

[0023] It can be understood that the electronic device described in the second aspect, the computer-readable storage medium described in the third aspect, the chip system described in the fourth aspect, and the computer program product described in the fifth aspect are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 Schematic diagram of the interaction between TEE and REE;

[0025] Figure 2 A schematic diagram of the interaction between the first TEE and the second TEE;

[0026] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0027] Figure 4 Schematic diagram of a multi-TEE architecture provided in an embodiment of the present application;

[0028] Figure 5 A flowchart of a key agreement method based on a trusted execution environment provided in an embodiment of the present application;

[0029] Figure 6A Schematic diagram of an interaction between a first TA and a second TA;

[0030] Figure 6B Schematic diagram of an interaction between a first TA and a second TA;

[0031] Figure 7AA schematic diagram of the interaction between the first TEE and the second TEE provided in an embodiment of the present application;

[0032] Figure 7B A schematic structural diagram of a chip system is provided for an embodiment of the present application. DETAILED DESCRIPTION

[0033] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this embodiment, unless otherwise specified, "plurality" means two or more.

[0034] In order to make the description of the following embodiments clear and concise and to facilitate easy understanding by those skilled in the art, a brief introduction to relevant concepts or technologies is first given.

[0035] REE, or Rich Execution Environment, can also be called a Normal Execution Environment. REE generally refers to an operating environment that lacks specific security features, such as Android and iOS operating systems. It should be noted that in addition to being called a "Rich Execution Environment," REE can also be referred to as an "Untrusted Execution Environment," "Normal Execution Environment," "Insecure Execution Environment," and so on, and this is not limited to these terms in the present embodiment.

[0036] A TEE, or Trusted Execution Environment, is an independent, isolated runtime environment (REE). It offers security capabilities and is resistant to software attacks common to REEs. The TEE has its own runtime space and strict protections, offering a higher level of security than the REE. It protects assets within the TEE, such as data and software, from software attacks and certain types of security threats.

[0037] Among them, TEE implementation methods include at least the following two:

[0038] 1. Implementing a TEE based on TrustZone technology. TrustZone technology isolates all system-on-chip (SoC) hardware and software resources, placing them in two separate zones: the Normal World and the Secure World. Components in the Normal World cannot access resources in the Secure World, thus isolating the two worlds. In this scenario, the Secure World can function as a TEE.

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

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

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

[0042] A CA, or client application, typically refers to an application running in a REE. However, in some cases, the TA that initiates the call can also act as a CA. The CA can call the TA through the client application programming interface (API) and instruct the TA to perform security operations.

[0043] In the prior art, most electronic devices use the REE+TEE architecture. The REE+TEE architecture refers to an architecture that combines TEE and REE to provide services for applications. In other words, TEE and REE coexist in electronic devices. For example, TEE can implement an operating mechanism isolated from REE through hardware support. TEE has its own operating space and a higher security level than REE, which can protect assets in TEE (such as data, software, etc.) from software attacks. Only authorized security software can be executed in TEE, and it also protects the confidentiality of the resources and data of the security software. Compared with REE, TEE can better protect the security of data and resources due to its protection mechanisms such as isolation and permission control.

[0044] The following takes the business process of decrypting received encrypted data as an example to introduce how to implement this business process in the existing technology. Figure 1 In this business process, after receiving the encrypted data from the cloud server, the CA in the REE can send a decryption request to the TA. The decryption request includes the encrypted data and instructs the TA to decrypt the encrypted data. After receiving the decryption request, the TA can call the key management module to decrypt the encrypted data to obtain the decrypted data (i.e., the decrypted data). After obtaining the decrypted data, the TA can further store the decrypted data in secure memory to ensure data security.

[0045] It should be noted that Figure 1 The TEE in a TEE is usually implemented by chip manufacturers based on the TrustZone mechanism. The TA in the TEE is usually developed and configured by the chip manufacturer itself, and the types and number of TAs are relatively small. In other words, the security services that the TEE can support are relatively limited. However, as the types and number of mobile applications increase, the security services involved (for example, formal verification, financial field authentication, etc.) are also increasing. In order to enable the TEE to support more types of security services, device manufacturers can develop TAs for different security services. However, this is not user-friendly for developers (device manufacturers) who are not familiar with the chip development environment, resulting in poor scalability of the TA.

[0046] In order to improve the scalability of TA, a multi-TEE architecture can be adopted. Among them, a multi-TEE architecture refers to an architecture in which multiple TEEs jointly provide services for applications. Exemplarily, an electronic device may include a first TEE and a second TEE, and the first TEE and the second TEE are isolated from each other. Among them, the first TEE can be an execution environment independent of the REE (for example, a virtual machine) isolated based on virtualization technology under the original REE, and the second TEE can be implemented based on TrustZone technology. The first TEE can provide services for applications that do not involve calling secure hardware (for example, replay protected memory block (RPMB)), such as formal verification, financial field authentication, digital rights management (DRM) authentication, etc. The second TEE has core security capabilities and can provide applications with chip-level secure boot, secure hardware, key management (for example, key derivation function (KDF)) and other services. Providing services to applications by combining multiple TEEs can not only ensure the security of sensitive data, but also facilitate developers to expand security services on the first TEE for different business processes.

[0047] For example, we will still take the business process of decrypting received encrypted data as an example to introduce how to implement this process in a multi-TEE architecture. Figure 2 In this business process, after the CA in the REE receives the encrypted data sent by the cloud server, it can send a decryption request to TA1 in the first TEE. The decryption request includes the encrypted data, and the decryption request is used to instruct TA1 to decrypt the encrypted data. After receiving the decryption request, TA1 can call the key management module to decrypt the encrypted data to obtain the decrypted data. After TA1 obtains the decrypted data, it can send a storage request to TA2 in the second TEE. The storage request includes the decrypted data, and the storage request is used to instruct TA2 to store the decrypted data. In this way, after receiving the storage request, TA2 can store the decrypted data in secure memory.

[0048] exist Figure 2 In the illustrated business process, TA1 cannot directly access secure memory. Therefore, when it needs to store decrypted data, it must send a storage request to TA2, which then stores the decrypted data. This process involves the transmission of sensitive data between the first and second TEEs. In this scenario, if the first TEE is rooted or attacked, sensitive data could easily be leaked, making data security unreliable.

[0049] Based on the above problems, an embodiment of the present application provides a key negotiation method, which can be applied to electronic devices deployed with multiple TEEs (for example, a first TEE and a second TEE). This method enables the first TEE to negotiate with the TA in the second TEE to obtain a consistent session key, so that when the first TEE and the second TEE exchange sensitive content (such as sensitive data, sensitive files, sensitive information), the sensitive content can be encrypted / decrypted based on the session key, ensuring the security of the sensitive content during the transmission process.

[0050] It should be noted that the electronic devices involved in the embodiments of the present application can be any electronic device that deploys a multi-TEE architecture, such as portable computers (such as mobile phones), tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) and virtual reality (VR) devices, media players, smart door locks, and other devices. The embodiments of the present application do not impose any special restrictions on the specific form of the electronic device.

[0051] In the embodiment of the present application, the electronic device is a mobile phone as an example to illustrate the structure of the electronic device provided in the embodiment of the present application. Figure 3 As shown, the mobile phone may include: a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an earphone interface 270D, a sensor module 280, a button 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a SIM card interface 295, etc.

[0052] Among them, the above-mentioned sensor module 280 may include sensors such as pressure sensor, gyroscope sensor, air pressure sensor, magnetic sensor, acceleration sensor, distance sensor, proximity light sensor, fingerprint sensor, temperature sensor, touch sensor, ambient light sensor and bone conduction sensor.

[0053] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the mobile terminal 200. In other embodiments, the mobile terminal 200 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.

[0054] The processor 210 may include one or more processing units. For example, the processor 210 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.

[0055] The controller may be the nerve center and command center of the mobile terminal 200. 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.

[0056] It is understood that the interface connection relationship between the modules illustrated in this embodiment is merely an illustrative illustration and does not limit the structure of the mobile terminal 200. In other embodiments, the mobile terminal 200 may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0057] Mobile terminal 200 implements display functions through a GPU, display screen 294, and an application processor. The GPU is a microprocessor for image processing that connects display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 210 may include one or more GPUs that execute program instructions to generate or change display information.

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

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

[0060] The external memory interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the mobile terminal 200. The external memory card communicates with the processor 210 via the external memory interface 220 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0061] The internal memory 221 can be used to store computer executable program codes, which include instructions. The processor 210 executes various functional applications and data processing of the mobile terminal 200 by running the instructions stored in the internal memory 221. For example, in an embodiment of the present application, the processor 210 can execute instructions stored in the internal memory 221, and the internal memory 221 can include a program storage area and a data storage area.

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

[0063] The mobile terminal 200 can implement audio functions such as music playback and recording through the audio module 270, the speaker 270A, the receiver 270B, the microphone 270C, the headphone jack 270D, and the application processor.

[0064] See also Figure 4 , which is a multi-TEE architecture provided in the application embodiment. Figure 4 As shown in the figure, the architecture includes REE, n VMs (including VM1, VM2...VMn (i.e., the first TEE)), a second TEE, and a virtual machine monitor. Among them, VM1, VM2...VMn (the first TEE) are virtual machines built using virtualization technology. Each VM can be used as a TEE running independently from the REE. Each VM may include an access agent module and one or more TAs (the figure only takes one TA as an example). The second TEE may include one or more TAs (the figure takes TA1, TA2...TAn as an example), a key management module, and a key derivation module.

[0065] The access proxy module of each VM can be used to establish a session channel between the corresponding VM and the second TEE. For example, the access proxy module of the first TEE can establish a session channel between the first and second TEEs. This session channel can be used to transmit data, files, information, instructions, and other information sent by a TA in the first TEE to a TA in the second TEE (e.g., TA1), or to transmit data, files, information, instructions, and other information sent by a TA in the second TEE (e.g., TA1) to a TA in the first TEE. It should be noted that multiple session channels can exist between the first and second TEEs, each corresponding to a TA in the second TEE. For example, when the access proxy module receives a service request from a TA for TA1, it can send the service request through the session channel between the first TEE and TA1. It should be noted that this session channel is not to be understood as an actual channel; it merely represents a method for exchanging data between the first and second TEEs. For example, the session channels between the first and second TEEs may include: a session channel between the first TEE and TA1, a session channel between the first TEE and TA2, and so on.

[0066] For example, the first TEE can establish a session channel with TA1. To ensure the security of the session channel (i.e., to ensure the security of the session content between the first TEE and TA1), the first TEE can negotiate a session key with TA1 and perform encryption operations on the session content based on the session key. When negotiating the session key, the access proxy module of the first TEE can send a first key generation request to the key derivation module in the second TEE through the virtual machine monitor. In response to the first key generation request, the key derivation module can generate a session key and feed the session key back to the access proxy module of the first TEE. TA1 can also send a key generation request (e.g., a third key generation request) to the key derivation module through the key management module. In response to the third key generation request, the key derivation module can generate a session key and feed the session key back to TA1. After the access proxy module of the first TEE and TA1 obtain the session key, they can perform encryption operations on the session content between the first TEE and TA1 based on the session key to ensure the security of the session content.

[0067] A key generation request instructs the key derivation module to generate a session key between the client and the server. The client is the end that initiates the call, and the server is the end that provides services to the client. For example, the first TEE can use the access proxy module to send a request to TA1 in the second TEE. In response to this request, TA1 can perform relevant operations and provide feedback to the access proxy module of the first TEE regarding the results. In this business process, the first TEE can be considered the client, and TA1 can be considered the server. The key generation request can include a random number, the client's identity document (ID), and the server's ID. For example, the first TEE's ID is the client's ID, and TA1's ID is the server's ID. The random number is a number or character pre-negotiated between the client and the server, and can be any value. In other words, the random number carried in the key generation request sent by the client (e.g., the first key generation request) is consistent with the random number carried in the key generation request sent by the server (e.g., the third key generation request). For example, the random number can be any value, such as 5, 8, or 61.

[0068] After receiving the key generation request (for example, the first key generation request, the third key generation request), the key derivation module can generate a session key between the client and the server based on the random number, client ID and server ID carried in the key generation request.

[0069] It can be seen that after receiving the key generation request sent by the client / server, the key derivation module can generate the same session key based on the client ID, server ID and a unified random number, and feed it back to the client / server respectively, so that the client and server obtain the same session key and realize key negotiation between the client and server.

[0070] The following is a detailed description of the key negotiation method provided in the embodiment of the present application. Figure 5 , is a flow chart of a key agreement method provided in an embodiment of the present application. The method includes:

[0071] S501: The access agent module sends a random number to the second TA.

[0072] The random number can be a number randomly generated by the access agent module. Alternatively, the first TEE can include a random number generation module, which can send the random number to the access agent module after generating it. In addition, the random number can be generated when the first TEE is turned on or before the first TEE calls the second TA. In this embodiment, there are no restrictions on the timing and method of generating the random number. The first TEE can generate the random number in any way and at any time.

[0073] The access proxy module may select a TA from a preset TA information list according to business requirements. For example, the preset TA information list may include multiple TA identities (e.g., universally unique identifiers (UUIDs)) and the services that each TA can provide. For example, the preset TA information list may be as shown in Table 1:

[0074] Table 1

[0075] TA Identity Serve TA1 ID1 Secure storage TA2 ID2 encryption TA3 ID3 Face Recognition …… …… ……

[0076] Among them, Table 1 indicates that the second TEE includes TA1, TA2, and TA3. Among them, the identity identifier of TA1 is ID1, which can provide secure storage services for applications. The identity identifier of TA2 is ID2, which can provide encryption services for applications. The identity identifier of TA3 is ID3, which can provide face recognition services for applications. If the business requirement of the first TEE is to perform encryption operations on certain data / files, the access proxy module can select TA2 to process its business request. After the access proxy module determines the target TA (for example, the second TA), it can send a random number to the target TA. It should be noted that the access proxy module actually sends the random number to the virtual machine monitor first, and then the virtual machine monitor forwards the random number to the target TA.

[0077] In one possible design, the random number and the TA can be in a one-to-one correspondence, that is, the access agent module can send different random numbers to different TAs. In this scenario, the access agent module can store the correspondence between the random number and the TA. Exemplarily, the access agent module can generate a TA-random number relationship comparison table based on the correspondence between the random number and the TA. In another possible design, the first TEE can send the same random number to all TAs in the second TEE. In one possible design, after the access agent module sends the random number to the second TA, it can be considered that the random number has been negotiated between the access agent module and the second TA, which facilitates the subsequent negotiation of the session key. In another possible design, after the second TA receives the random number, it can send feedback information to the access agent module, and the feedback information is used to indicate that the second TA has received the random number. Only after the access agent module receives the feedback information can it be considered that the random number has been negotiated between the access agent module and the second TA.

[0078] S502: The second TA stores a random number.

[0079] When storing random numbers, the second TA can also store the correspondence between the random numbers and the random number sender (for example, the first TEE). For example, there are multiple VMs in the electronic device, and multiple VMs send random numbers to the second TA. The TA can store the correspondence between each VM ID and the random number and generate a client-random number relationship comparison table. For example, the client-random number relationship comparison table can be shown in Table 2:

[0080] Table 2

[0081]

[0082]

[0083] According to Table 2, the random number sent by the first TEE to the second TA is 5, the random number sent by VM2 to the second TA is 11, and the random number sent by VM3 to the second TA is 136.

[0084] S503: The access proxy module sends a first key generation request to the virtual machine monitor.

[0085] Among them, since the first TEE runs based on a virtual machine monitor (hypervisor), the access agent module on the first TEE can send requests to the outside through the virtual machine monitor (hypervisor). The first key generation request includes a random number and the TA's identity, which is used to instruct the key derivation module to generate a session key between the first TEE and the TA. In one possible design, if the access agent module sends different random numbers to different TAs, the access agent module can find the corresponding random number in the TA-random number relationship comparison table based on the identity of the second TA, and then generate a first key generation request based on the random number and the TA's identity. If the random number sent by the access agent module to all TAs is the same, the access agent module can directly read the random number and generate a first key generation request based on the random number and the identity of the second TA. Exemplarily, the first key generation request can be Getkey(R-number, TA ID). Wherein, R-number refers to the random number, and TAID refers to the identity of the second TA.

[0086] It should be noted that the access proxy module can send a first key generation request to obtain a session key at any time before the first TEE and the second TA exchange sensitive data (information / instructions / files, etc.). That is, the embodiment of the present application does not limit the specific timing of sending the first key generation request. Exemplarily, the access proxy module can send the first key generation request after negotiating a random number with the second TA (i.e., sending a random number to the second TA). Alternatively, the access proxy module can also send the first key generation request before sending sensitive data to the second TA.

[0087] S504: The virtual machine monitor obtains the identity of the first TEE and adds the identity of the first TEE to the first key generation request.

[0088] Since the key derivation module needs to use a random number, the client's ID (equivalent to the first TEE's ID) and the server's ID (equivalent to the TA's ID) to generate a session key, and the first key generation request does not include the identity of the first TEE. Therefore, after receiving the first key generation request, the virtual machine monitor can obtain the identity of the first TEE and fill the identity of the first TEE into the first key generation request to complete the information required for the key derivation module to generate the session key. Exemplarily, the first key generation request after adding the identity of the first TEE can be Getkey(R-number, TAID, Client ID). Among them, Client ID refers to the identity of the first TEE.

[0089] S505: The virtual machine monitor sends a first key generation request to the key derivation module, with the identity of the first TEE added.

[0090] S506: The key derivation module generates a session key according to the identity of the first TEE, the identity of the second TA and a random number.

[0091] The key derivation module can generate a session key based on the identity of the first TEE, the identity of the second TA, and a random number. For example, the identity of the first TEE can be ID1, the identity of the second TA can be ID2, and the random number is 11. Then, the KDF can generate a session key between the first TEE and the second TA based on ID1, ID2, and 11.

[0092] S507: The key derivation module sends the first key information to the virtual machine monitor.

[0093] The first key information includes the identity of the first TEE and the session key.

[0094] S508: In response to receiving the first key information, the virtual machine monitor sends a session key to the access proxy module.

[0095] After receiving the first key information, the virtual machine monitor can parse the first key information to obtain the identity of the first TEE and the session key. Then, based on the identity of the first TEE, the session key is sent to the access proxy module of the first TEE. As can be seen, after the key derivation module generates the session key, the virtual machine monitor can forward the session key to the access proxy module of the first TEE. It can be understood that after receiving the session key, the access proxy module can use the session key to encrypt / decrypt the session between the first TEE and the second TA.

[0096] Because the access proxy module can negotiate session keys with different TAs, to facilitate session key management, the access proxy module can store the corresponding relationship between the session key and the TA after receiving the session key. In this way, before sending sensitive data to a second TA, the access proxy module can first obtain the session key corresponding to the second TA from the corresponding relationship between the session key and the TA based on the second TA's identity and use the session key to encrypt / decrypt the sensitive data.

[0097] S509: The second TA sends a third key generation request to the key management module.

[0098] The third key generation request includes a random number and the identity of the first TEE, which is used to instruct the key derivation module to generate a session key between the first TEE and the second TA. In one possible design, the second TA can find the corresponding random number in the Client-random number relationship table based on the identity of the first TEE, and then generate the third key generation request based on the random number and the identity of the first TEE. Exemplarily, the third key generation request can be Getkey(R-number, Client ID).

[0099] It should be noted that the second TA can send a third key generation request to obtain the session key at any time before the session key is needed. That is, the embodiment of the present application does not limit the specific timing of sending the third key generation request. For example, the second TA can send the first key generation request after receiving the random number sent by the first TEE. Alternatively, the second TA can also send the first key generation request after receiving the encrypted session information sent by the first TEE.

[0100] S510: The key management module obtains the identity of the second TA and adds the identity of the second TA to the third key generation request.

[0101] Since the key derivation module needs to use a random number, the client's ID (equivalent to the ID of the first TEE) and the server's ID (equivalent to the ID of the second TA) to generate a session key, and the third key generation request does not include the identity of the second TA. Therefore, the key management module can provide a key derivation service for the second TA. That is, the key management module can receive the key generation request sent by the second TA, and after identifying the identity of the second TA, fill the identity of the second TA into the third key generation request to complete the information required for the key derivation module to generate the session key. Exemplarily, the third key generation request after adding the identity of the second TA can be Getkey(R-number, TA ID, Client ID).

[0102] S511: The key management module sends a third key generation request to the key derivation module, with the identity of the second TA added.

[0103] S512: The key derivation module generates a session key according to the identity of the first TEE, the identity of the second TA and a random number.

[0104] The key derivation module can call KDF to generate a session key based on the identity of the first TEE, the identity of the second TA, and a random number. For example, the identity of the first TEE can be ID1, the identity of the second TA can be ID2, and the random number is 11. Then, KDF can generate a session key between the first TEE and the second TA based on ID1, ID2, and 11.

[0105] It should be noted that, in an optional implementation, the third key generation request sent by the second TA may also include the identity of the second TA. In this case, the second TA may send the third key generation request to the key derivation module via an application programming interface.

[0106] S513: The key derivation module sends the second key information to the key management module.

[0107] The second key information includes the identity of the second TA and the session key.

[0108] S514: In response to receiving the second key information, the key management module sends the session key to the second TA.

[0109] After receiving the second key information, the key management module can parse the second TA's identity and session key from the second key information. The session key is then sent to the second TA based on the second TA's identity. As can be seen, after the key derivation module generates the session key, the key management module can send the session key to the second TA. As can be understood, after receiving the session key, the second TA can use it to encrypt / decrypt the session between the first TEE and the second TA.

[0110] Since the second TA can negotiate session keys with different VMs, to facilitate the second TA's management of session keys, after receiving the session key, the second TA can store the correspondence between the session key and the VM. In this way, when the TA receives a session request from the first TEE, it can obtain the session key corresponding to the first TEE from the correspondence between the session key and the VM based on the first TEE's identity and use the session key to decrypt / encrypt the session request.

[0111] S515: The first TA performs service interaction with the second TA based on the session key.

[0112] In a possible design, the process of service interaction between the first TA and the second TA can be as follows: Figure 6AAs shown. The first TA may send a service request to the virtual machine monitor, which then forwards the service request to the second TA. The service request includes service data encrypted based on the session key, and the service request is used to instruct the second TA to perform service processing on the service data.

[0113] In another possible design, the process of service interaction between the first TA and the second TA can also be as follows: Figure 6B The interaction process may include:

[0114] S701. TA1 encrypts service data based on the session key.

[0115] S702. TA1 sends a service request to CA.

[0116] The service request may include encrypted service data, the identity of the first TEE, and the identity of TA2. The service request is used to instruct TA2 to store the service data in secure memory. The service data may be instructions, data, information, etc.

[0117] S703: The CA sends a service request to the virtual machine monitor.

[0118] S704: The virtual machine monitor sends a service request to TA2.

[0119] After receiving the service request, TA2 can find the corresponding session key according to the identity of the first TEE, and decrypt the encrypted service data according to the session key to obtain the service data. Then the service data is processed accordingly.

[0120] It can be seen that since the REE does not know the session key between the first TEE and TA2, TA1 of the first TEE can still forward the request through the REE and the virtual machine monitor.

[0121] It can be seen that the key agreement method provided by this application can be divided into three stages: Stage 1 (S501-S502), the first TEE and the second TA unify the random number; Stage 2 (S503-S508), the key derivation module generates a session key according to the first key generation request sent by the first TEE; Stage 3 (S509-S514), the key derivation module generates a session key according to the third key generation request sent by the second TA. It should be noted that Figure 5 The flowchart shown is for illustrative purposes only. In practice, there is no strict order between Stage 2 and Stage 3. For example, Stage 2 (i.e., S503-S508) may be performed first, followed by Stage 3 (i.e., S509-S514); Stage 3 may be performed first, followed by Stage 2; or Stage 2 and Stage 3 may be performed simultaneously.

[0122] It should be noted that S501 to S514 only take the process of negotiating the session key between the first TEE (VMn) and the second TA as an example. Figure 4 Any VM in the TEE can serve as a TEE and use the process of S501 to S514 to negotiate a session key with the second TA or other TA in the second TEE.

[0123] For example, still taking the business process of decrypting the received encrypted data as an example, a possible implementation method of the process is introduced after the first TEE and the second TEE have negotiated the session key based on steps S501 to S504. Figure 7A In this business process, after the CA in the REE receives the encrypted data sent by the cloud server, it can send a decryption request to TA1 in the first TEE. The decryption request includes the encrypted data, and the decryption request is used to instruct TA1 to decrypt the encrypted data to obtain the decrypted data. After TA1 obtains the decrypted data, TA1 can re-encrypt the decrypted data based on the pre-negotiated session key, and then transmit the decrypted data after the re-encryption operation to TA2 through the virtual machine monitor. TA2 can decrypt the received data based on the pre-negotiated session key and then store the decrypted data in secure memory.

[0124] When TA1 needs to obtain decrypted data, it can send a request to TA2. In response to this request, TA2 can read the decrypted data from the secure memory, encrypt the decrypted data using the pre-negotiated session key, and then transmit the encrypted decrypted data to TA1. TA1 can then decrypt the received data using the session key to obtain the decrypted data.

[0125] Based on the above, it can be seen that this application negotiates a session key between the TA of the first TEE and the TA of the second TEE. The first TEE and the TA can encrypt the data transmitted to each other based on the session key to ensure the security of the session content.

[0126] Another embodiment of the present application provides a chip system 700, such as Figure 7B As shown, the chip system includes at least one processor 701 and at least one interface circuit 702. The processor 701 and the interface circuit 702 can be interconnected via a line. For example, the interface circuit 702 can be used to receive signals from other devices (e.g., a memory of an electronic device). For another example, the interface circuit 702 can be used to send signals to other devices (e.g., the processor 701).

[0127] For example, the interface circuit 702 may read instructions stored in a memory in the electronic device and send the instructions to the processor 701. When the instructions are executed by the processor 701, the electronic device may execute the steps in the above embodiments.

[0128] Through the description of the above embodiments, those skilled in the art will clearly understand that for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

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

[0130] 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 computer-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, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform 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 flash memory, mobile hard disk, read-only memory, random access memory, magnetic disk or optical disk.

[0131] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A key negotiation method, characterized in that: Applied to an electronic device including a virtual machine monitor, a first trusted execution environment (TEE), and a second TEE, wherein the first TEE includes an access agent module and a first trusted application (TA), and the second TEE includes a second TA and a key derivation module, the method comprising: The access agent module sends a first key generation request to the virtual machine monitor; wherein the first key generation request includes the identity of the second TA and a preset random number, and the first key generation request is used to instruct the key derivation module to generate a session key between the first TEE and the second TA; In response to receiving the first key generation request, the virtual machine monitor adds the identity of the first TEE to the first key generation request to generate a third key generation request, where the third key generation request is the first key generation request with the identity of the first TEE added; The virtual machine monitor sends the third key generation request to the key derivation module, where the third key generation request includes the identity of the first TEE, the identity of the second TA, and the random number; In response to the third key generation request, the key derivation module generates the session key according to the identity of the first TEE, the identity of the second TA, and the random number; The key derivation module sends the session key to the access proxy module; The second TA sends a fourth key generation request to the key derivation module; wherein the fourth key generation request includes the identity of the first TEE, the identity of the second TA, and the random number, and the fourth key generation request is used to instruct the key derivation module to generate a session key between the first TEE and the second TA; In response to the fourth key generation request, the key derivation module generates the session key according to the identity of the first TEE, the identity of the second TA, and the random number; The key derivation module sends the session key to the second TA; The first TA performs service interaction with the second TA based on the session key.

2. The key negotiation method according to claim 1, wherein: The first TA performs service interaction with the second TA based on the session key, including: The first TA sends a service request to the virtual machine monitor; wherein the service request includes service data encrypted based on the session key, and the service request is used to instruct the second TA to perform service processing on the service data; The virtual machine monitor sends the service request to the second TA.

3. The key negotiation method according to claim 1, wherein: The electronic device further includes a rich execution environment (REE), in which a client application (CA) runs. The first TA performs service interaction with the second TA based on the session key, including: The first TA sends a service request to the virtual machine monitor; wherein the service request includes service data encrypted based on the session key, and the service request is used to instruct the second TA to perform service processing on the service data; The virtual machine monitor sends the service request to the CA; The CA sends the service request to the second TA.

4. The key negotiation method according to claim 1, wherein: The second TEE further integrates a key management module, and the second TA sends a fourth key generation request to the key derivation module, including: The second TA sends a second key generation request to the key management module; wherein the second key generation request includes the identity of the first TEE and the random number; In response to receiving the second key generation request, the key management module adds the identity of the second TA to the second key generation request to generate the fourth key generation request; The key management module sends the fourth key generation request to the key derivation module.

5. The key negotiation method according to claim 4, wherein: The key derivation module sending the session key to the second TA includes: The key derivation module sends second key information to the key management module; wherein the second key information includes the identity of the second TA and the session key; The key management module sends the session key to the second TA.

6. The key negotiation method according to claim 1, wherein: The second TEE is further integrated with an application program interface, and the second TA sends a fourth key generation request to the key derivation module, including: The second TA sends a fourth key generation request to the key derivation module through the application program interface.

7. The key agreement method according to any one of claims 1 to 6, wherein: Before the access proxy module sends the first key generation request to the virtual machine monitor, the method further includes: The access agent module sends the random number to the second TA.

8. The key agreement method according to any one of claims 1 to 6, wherein: The key derivation module sends the session key to the access proxy module, comprising: The key derivation module sends first key information to the virtual machine monitor; wherein the first key information includes the identity of the first TEE and the session key; The virtual machine monitor sends the session key to the access proxy module according to the identity identifier of the first TEE.

9. An electronic device, characterized in that: The electronic device is integrated with a virtual machine monitor, a first trusted execution environment (TEE), and a second TEE. The first TEE includes an access proxy module and a first trusted execution environment (TA). The second TEE includes a first trusted application (TA) and a key derivation module. The electronic device includes: a wireless communication module, a memory, and one or more processors. The wireless communication module and the memory are 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 key agreement method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that including computer instructions; When the computer instructions are executed on the electronic device, the electronic device is enabled to perform the key negotiation method according to any one of claims 1 to 8.

Images