Key use method and related product
By processing key requests on devices with secure hardware environments, the risk of key leakage in terminal devices is resolved, enabling secure key use and efficient data processing, while also increasing the complexity and supported types of keys.
Patent Information
- Application Number
- CN202511404770.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2020-08-29
- Publication Date
- 2026-02-03
AI Technical Summary
In terminal devices, there is a risk of leakage during the generation, storage, use and destruction of keys, especially in devices without secure hardware environments, where the complexity of keys is limited and cannot support more types and complex encryption operations.
The first device sends a key usage request to a second device with a secure hardware environment. The second device processes the data to be processed and returns the result, thus avoiding the storage and use of keys in devices without a secure hardware environment. This achieves key custody and index management, ensuring the security of key storage and unrestricted computing power.
It enables the secure use of keys in devices without secure hardware environments, avoids the risk of key leakage, increases the complexity of keys and the types and complexity of supported keys, and improves processing efficiency.
Smart Images

Figure CN121456892A_ABST
Abstract
Description
[0001] This application is a divisional application. The original application has the application number 202010890848.1 and the original application date is August 29, 2020. The entire contents of the original application are incorporated herein by reference. Technical Field
[0002] This application relates to the field of terminal technology, and in particular to a key usage method and related products. Background Technology
[0003] With the continuous development of electronic and computer technologies, mobile phones, tablets, smart wearable devices, and other terminals have become widespread. Data encryption, data integrity protection, and identity authentication on these terminals rely on keys to ensure security and reliability. The complete lifecycle of a key includes its generation, storage, use, transmission, and destruction. Each stage carries the risk of leakage. Summary of the Invention
[0004] This application provides a method for using a key and related products.
[0005] In a first aspect, embodiments of this application provide a key usage method, including:
[0006] The first device sends a key usage request to the second device, which includes a secure hardware environment;
[0007] The first device receives a key usage result sent by the second device. The key usage result is obtained by the second device processing the data to be processed in the key usage request based on the key in the security hardware environment.
[0008] In this way, during key usage, it is not necessary to store the key on a first device lacking secure hardware, nor is it necessary for the first device to use the key to process the data to be processed. This not only avoids the key being cracked if stored on a first device lacking secure hardware, but also allows the complexity of the key to be unrestricted by the computing power of the first device, enabling the first device to support more types and more complex keys.
[0009] In this application, the first device may be a device without a secure hardware environment. The first device may also be referred to as a thin device, and the second device may be referred to as a rich device.
[0010] In some implementations, before the first device sends a key usage request to the second device, the method further includes:
[0011] The first device obtains the connection status between itself and one or more second devices in the device list;
[0012] The first device selects a second device from the one or more second devices to process the key usage request based on the connection status between the first device and the one or more second devices;
[0013] The first device sends a key usage request to the second device, including:
[0014] The first device sends the key usage request to the second device used to process the key usage request.
[0015] In this way, the first device can select the second device with the best connection status from multiple second devices, thereby enabling it to process the data to be processed more quickly and efficiently using the key in the second device.
[0016] In some implementations, before the first device sends a key usage request to the second device, the method further includes:
[0017] The first device sends a key escrow request to the second device, the key escrow request including the key, the key escrow request being used to request the second device to store the key.
[0018] In some implementations, the key escrow request further includes an index of the key, and the key escrow is further configured to request the second device to save the index of the key; the key usage request includes the index of the key and the data to be processed.
[0019] In this way, the first device can entrust the key to the second device after it is generated. The second device then stores the key in a secure hardware environment, thereby ensuring the security of the key storage.
[0020] Secondly, this application provides another method for using the key, including:
[0021] The second device receives a key usage request sent by the first device, and the second device includes a secure hardware environment;
[0022] The second device uses a key in the secure hardware environment to process the data to be processed in the key usage request, and obtains the key usage result;
[0023] The second device sends the key usage result to the first device.
[0024] In this way, during key usage, it is not necessary to store the key on a first device lacking secure hardware, nor is it necessary for the first device to use the key to process the data to be processed. This not only avoids the key being cracked if stored on a first device lacking secure hardware, but also allows the complexity of the key to be unrestricted by the computing power of the first device, enabling the first device to support more types and more complex keys.
[0025] In some embodiments, before the second device receives the key usage request sent by the first device, the method further includes:
[0026] The second device receives a key escrow request from the first device, the key escrow request including the key;
[0027] The second device stores the key in the secure hardware environment.
[0028] In this way, the first device can entrust the key to the second device after it is generated. The second device then stores the key in a secure hardware environment, thereby ensuring the security of the key storage.
[0029] In some implementations, the key escrow request further includes an index of the key; the method further includes: the second device storing the index of the key in the secure hardware environment;
[0030] The key usage request includes the index of the key and the data to be processed.
[0031] In this way, the second device can find the key to be used based on the key index in the key usage request, thereby helping to improve the accuracy and efficiency of responding to the key usage request of the first device.
[0032] Thirdly, this application provides an electronic device including a memory, one or more processors, and multiple application programs. The memory stores one or more programs, and when the one or more processors run the one or more programs, the terminal executes the application processing method described in any of the possible embodiments of the first aspect.
[0033] Fourthly, embodiments of this application provide a computer storage medium including computer instructions that, when executed on a terminal, cause the terminal to perform an application processing method according to any possible implementation of the first aspect described above.
[0034] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal, causes the terminal to execute the application processing method of any possible implementation of the first aspect described above. Attached Figure Description
[0035] Figure 1 This is a schematic diagram of the network architecture of an embodiment of this application;
[0036] Figure 2 This is a schematic diagram of the terminal structure provided in the embodiments of this application;
[0037] Figure 3 A software structure block diagram of the terminal provided in the embodiments of this application;
[0038] Figure 4A This is a flowchart illustrating the key usage method according to an embodiment of this application;
[0039] Figure 4B This is a flowchart illustrating another key usage method according to an embodiment of this application;
[0040] Figure 5 This is a flowchart illustrating the key storage method according to an embodiment of this application;
[0041] Figure 6 This is a schematic diagram of the modules of the first and second devices according to an embodiment of this application;
[0042] Figure 7 This is another flowchart illustrating the key storage method according to an embodiment of this application;
[0043] Figure 8 This is another flowchart illustrating the key usage method according to an embodiment of this application. Detailed Implementation
[0044] The technical solutions in the embodiments of this application will now be described clearly and in detail with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.
[0045] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.
[0046] Please see Figure 1 , Figure 1 This is a network architecture diagram provided for an embodiment of this application. For example... Figure 1 As shown, the network architecture 100 includes a first device 10 and a second device 20. A first device 10 can communicate with one or more second devices 20 via a communication link 30. The communication between the first device 10 and the second devices 20 can be wireless or wired communication. Both the first device 10 and the second device 20 are electronic devices.
[0047] The first device 10 may be, for example, a terminal. The second device 20 may be, for example, a server or a terminal. The first device 10 does not include a security hardware environment, while the second device 20 does include a security hardware environment.
[0048] Terminals may include, but are not limited to, personal computers, smartphones, smart wearable devices, tablets, personal digital assistants, Bluetooth speakers, Bluetooth headsets, smart home appliances, etc.
[0049] Figure 2 A schematic diagram of the terminal is shown. This terminal can be either a first device or a second device.
[0050] The following uses a terminal as an example to illustrate the implementation details. It should be understood that... Figure 2 The terminal shown is merely an example, and terminals can have more than [specific features]. Figure 2 The more or fewer components shown can be combined into two or more components, or they can have different component configurations. The various components shown in the figure can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.
[0051] The terminal 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, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.
[0052] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the terminal. In other embodiments of this application, the terminal may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
[0053] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.
[0054] The controller can serve as the nerve center and command center of the terminal. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.
[0055] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.
[0056] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.
[0057] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thus realizing the touch function of the terminal.
[0058] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.
[0059] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.
[0060] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.
[0061] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the terminal's shooting function. The processor 110 and the display screen 194 communicate via the DSI interface to enable the terminal's display function.
[0062] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.
[0063] USB port 130 is a USB standard compliant interface, which can be a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge the device, or to transfer data between the device and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.
[0064] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a limitation on the structure of the terminal. In other embodiments of this application, the terminal may also adopt different interface connection methods or a combination of multiple interface connection methods as described in the above embodiments.
[0065] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via a USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the terminal. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.
[0066] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, external memory, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.
[0067] The terminal's wireless communication function can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.
[0068] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the terminal can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.
[0069] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G in terminals. The mobile communication module 150 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.
[0070] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.
[0071] The wireless communication module 160 can provide solutions for wireless communication applications on terminals, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.
[0072] In some embodiments, antenna 1 of the terminal is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the terminal to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).
[0073] The terminal implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.
[0074] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a minimized display, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the terminal may include one or N displays 194, where N is a positive integer greater than 1.
[0075] The terminal can achieve shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.
[0076] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.
[0077] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the terminal may include one or N cameras 193, where N is a positive integer greater than 1.
[0078] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when a terminal selects a frequency, a DSP can perform a Fourier transform on the frequency energy.
[0079] Video codecs are used to compress or decompress digital video. A terminal can support one or more video codecs. This allows the terminal to play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.
[0080] NPU stands for Neural Network (NN) Computing Processor. By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in terminals, such as image recognition, facial recognition, speech recognition, and text understanding.
[0081] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the terminal's storage capacity. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.
[0082] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various terminal functions and data processing by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during terminal use (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.
[0083] The terminal can implement audio functions, such as music playback and recording, through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, and an application processor.
[0084] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.
[0085] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The terminal can listen to music or make hands-free calls through the speaker 170A.
[0086] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the terminal is answering a phone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.
[0087] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. A terminal can have at least one microphone 170C. In some embodiments, the terminal can have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, the terminal can have three, four, or more microphones 170C, enabling sound signal collection, noise reduction, sound source identification, and directional recording, among other functions.
[0088] The 170D headphone jack is used to connect wired headphones. The 170D headphone jack can be a USB 130 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.
[0089] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. The terminal determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, the terminal detects the intensity of the touch operation based on pressure sensor 180A. The terminal can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example: when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.
[0090] The gyroscope sensor 180B can be used to determine the motion posture of the terminal. In some embodiments, the gyroscope sensor 180B can determine the angular velocity of the terminal around three axes (i.e., the x, y, and z axes). The gyroscope sensor 180B can be used for image stabilization. For example, when the shutter is pressed, the gyroscope sensor 180B detects the angle of the terminal's shake, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to counteract the terminal's shake through reverse movement, thus achieving image stabilization. The gyroscope sensor 180B can also be used in navigation and motion-sensing game scenarios.
[0091] The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the terminal calculates altitude using the air pressure value measured by the barometric pressure sensor 180C to assist in positioning and navigation.
[0092] The magnetic sensor 180D includes a Hall effect sensor. The terminal can use the magnetic sensor 180D to detect the opening and closing of the flip cover. In some embodiments, when the terminal is a flip phone, the terminal can detect the opening and closing of the flip cover using the magnetic sensor 180D. Then, based on the detected opening and closing state of the cover or the flip cover, features such as automatic flip unlocking can be set.
[0093] The 180E accelerometer can detect the magnitude of acceleration in various directions (typically three axes) of a device. When the device is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the posture of electronic devices, and is applied to applications such as screen orientation switching and pedometers.
[0094] A distance sensor 180F is used to measure distance. The terminal can measure distance via infrared or laser. In some embodiments, during a shooting scene, the terminal can utilize the distance sensor 180F to measure distance for rapid focusing.
[0095] The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED. The terminal emits infrared light outward through the LED. The terminal uses the photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that an object is near the terminal. When insufficient reflected light is detected, the terminal can determine that no object is near the terminal. The terminal can use the proximity sensor 180G to detect when a user holds the terminal close to their ear for a call, so as to automatically turn off the screen to save power. The proximity sensor 180G can also be used in holster mode and pocket mode for automatic unlocking and screen locking.
[0096] The ambient light sensor 180L is used to detect ambient light intensity. The device can adaptively adjust the brightness of the display screen 194 based on the detected ambient light intensity. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 180L can also work with the proximity sensor 180G to detect whether the device is in a pocket to prevent accidental touches.
[0097] The fingerprint sensor 180H is used to collect fingerprints. The terminal can use the collected fingerprint characteristics to achieve fingerprint unlocking, accessing app locks, taking photos with fingerprints, answering calls with fingerprints, etc.
[0098] Temperature sensor 180J is used to detect temperature. In some embodiments, the terminal uses the temperature detected by temperature sensor 180J to execute a temperature processing strategy. For example, when the temperature reported by temperature sensor 180J exceeds a threshold, the terminal reduces the performance of the processor located near temperature sensor 180J to reduce power consumption and implement thermal protection. In other embodiments, when the temperature is below another threshold, the terminal heats battery 142 to prevent abnormal shutdown due to low temperature. In still other embodiments, when the temperature is below yet another threshold, the terminal boosts the output voltage of battery 142 to prevent abnormal shutdown due to low temperature.
[0099] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of the terminal, in a different position than display screen 194.
[0100] The bone conduction sensor 180M can acquire vibration signals. In some embodiments, the bone conduction sensor 180M can acquire vibration signals from the vibrating bone segments of the human vocal cords. The bone conduction sensor 180M can also contact the human pulse to receive blood pressure signals. In some embodiments, the bone conduction sensor 180M can also be incorporated into headphones to form bone conduction headphones. The audio module 170 can parse the voice signals from the vibrating bone segments of the vocal cords acquired by the bone conduction sensor 180M to realize voice functionality. The application processor can parse heart rate information from the blood pressure signals acquired by the bone conduction sensor 180M to realize heart rate detection functionality.
[0101] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. The terminal can receive button input and generate key signal inputs related to user settings and function control of the terminal.
[0102] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations performed on different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations performed on different areas of the display screen 194. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.
[0103] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.
[0104] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the terminal. The terminal can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, and other SIM cards. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The terminal interacts with the network through the SIM card to achieve functions such as calls and data communication. In some embodiments, the terminal uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the terminal and cannot be separated from the terminal.
[0105] The terminal's software system can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application uses a layered Android system as an example to illustrate the terminal's software structure.
[0106] Figure 3 This is a software structure block diagram of the terminal according to an embodiment of this application.
[0107] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.
[0108] The application layer can include a series of application packages.
[0109] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.
[0110] like Figure 3 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.
[0111] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.
[0112] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.
[0113] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.
[0114] A phone manager is used to provide communication functions for the terminal, such as managing call status (including connection and disconnection).
[0115] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.
[0116] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.
[0117] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.
[0118] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.
[0119] The application layer and application framework layer run in the Android Virtual Machine (DALVIK). The Android Virtual Machine executes the Java files of the application layer and application framework layer as binary files. The Android Virtual Machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.
[0120] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.
[0121] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.
[0122] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.
[0123] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.
[0124] A 2D graphics engine is a graphics engine for 2D drawing.
[0125] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.
[0126] In the existing technology, key management schemes include local key management schemes and key management schemes that rely on cloud interaction.
[0127] The local management scheme employs a multi-level key management approach, from the root key to the working key. The root key is composed of key components. During key storage, the protection of the root key relies on hard-coding the key components. These key components are stored distributed across local memory. When using a key, the key is first recovered using the key components, and then the key is used to encrypt the data to be encrypted. However, this scheme, with its hard-coded key components, cannot prevent decompilation. An unauthorized user can decompile the password, obtaining the key components and their assembly method, thus enabling them to crack the key.
[0128] In key management schemes that rely on cloud interaction, terminals can store keys on cloud servers. This ensures key security during storage. However, terminal devices have limited computing power. When using keys, terminals need to perform encryption and decryption operations, and the limited computing power of terminals results in a limited number of supported key types.
[0129] This application provides a key protection scheme based on... Figure 1 The network architecture shown associates a first device with one or more second devices. The first device can be understood as a thin device, and the second device as a rich device. A rich device is a device with a secure hardware environment, while a thin device is a device without a secure hardware environment.
[0130] During key storage, the first device stores the key on multiple second devices. When the first device needs to use the key, for example, to encrypt data, it sends the data to the second devices. The second devices then encrypt the data using the stored key and send the encrypted data back to the first device. In this way, the first device can obtain the encrypted data from the second devices. Even if the first device lacks secure hardware, the fact that the key is not stored on the first device prevents unauthorized users from stealing and decompiling it. Furthermore, since the encryption process is performed on the second devices, the complexity of the key is not limited by the computing power of the first device, thus supporting more and more complex key types.
[0131] In this application, the first device can be understood as a thin device, and the second device can be understood as a rich device.
[0132] The first device can be, for example, a terminal device that lacks a secure hardware environment. Specifically, the first device can be, but is not limited to, smart speakers, smart home appliances, mobile phones without a secure hardware environment, media players, etc.
[0133] The second device can be, but is not limited to, a server, a mobile phone with a secure hardware environment, a personal computer, a tablet computer, etc.
[0134] In one possible implementation, the secure hardware environment is a trusted execution environment (TEE). For example, the second device includes both a TEE and a rich execution environment (REE). The TEE provides a secure execution environment for trusted applications (TAs), while also protecting the confidentiality, integrity, and access rights of the TA's resources and data. The REE runs a terminal operating system, such as Android.
[0135] In another possible implementation, the security hardware environment is Software Guard Extensions (SGX). SGX is a security hardware environment on Intel chips.
[0136] In another possible implementation, the secure hardware environment is a Secure Enclave Processor (SEP). The second device may include a hardware environment running the iOS system, as well as the SEP.
[0137] The technical solution of this application will be explained in detail below in conjunction with the key usage method.
[0138] like Figure 4A The flowchart shown illustrates the key usage method. The key usage method in this embodiment includes the following steps:
[0139] 401. The first device sends a key usage request to the second device, the second device including a secure hardware environment;
[0140] The first device is a user-side terminal device, and the second device can be a terminal device, a server, or a cloud device. The first device and the second device can communicate via wired or wireless communication methods.
[0141] Specifically, the first device sends a key usage request to the second device based on the key usage request from the business module.
[0142] The key usage request includes data to be processed. This data can be understood as the object of key usage. Optionally, the key usage request may also include at least one of the following: the identifier of the first device, the index of the key, parameters required for key usage, the identifier of the business module, and key usage operations.
[0143] Key usage operations may include, but are not limited to, requesting the encryption or decryption of data to be processed, requesting the generation or verification of certificates, etc.
[0144] The business module is used to implement the functional business of the first device. For example, a smart speaker can implement the business function of voiceprint encryption, but the smart speaker lacks a secure hardware environment. The smart speaker's use of a key to encrypt the voiceprint and storing the key may lead to the theft of the key. Therefore, using the technical solution of this application, when the smart speaker needs to use a key to encrypt the voiceprint and store the key, it can send a key usage request to a second device after generating the key. This key usage request includes data to be processed, which may include the voiceprint to be encrypted. The second device has a secure hardware environment, so the key stored on the second device can be used to encrypt the voiceprint. The key stored on the second device may be sent to the second device by the first device.
[0145] 402. The second device processes the key usage request using the key stored in the secure hardware environment, and obtains the key usage result.
[0146] Specifically, the second device uses a key stored in a secure environment to process the data to be processed and obtain the key usage result.
[0147] For example, if the key usage request is to encrypt a voiceprint, the second device can use a key stored in a secure environment to encrypt the voiceprint, obtaining a key usage result that includes the encrypted voiceprint. Of course, the key usage result can also include whether the key usage was successful or failed, and it can also include other information.
[0148] Optionally, the key usage request may include the verification information of the first device. The second device may verify the legitimacy of the key usage request sent by the first device based on the verification information of the first device before processing the data to be encrypted to obtain the key usage result.
[0149] 403. The second device sends the key usage result to the first device.
[0150] The result of key usage may include the data obtained after performing the key usage steps on the data to be processed, and may also include result information such as whether the key usage steps were executed normally.
[0151] In this way, the second device can send the result of key usage to the first device. For example, after encrypting the voiceprint, the second device sends the resulting encrypted voiceprint to the first device.
[0152] The first device can then obtain the encrypted voiceprint.
[0153] As can be seen, in the technical solution of this application, the first device, which lacks a secure hardware environment, can entrust the key to a second device that has a secure hardware environment. When the first device needs to use the key, it can send a key usage request to the second device. The key usage request includes the data to be processed, which can be understood as the key usage object. After the second device processes the data to be processed using the key stored in the secure environment, it obtains the key usage result and sends the key usage result to the first device. In this way, during the key usage process, it is not necessary to store the key in the first device, which lacks a secure hardware environment, nor is it necessary for the first device to use the key to process the data to be processed. This not only avoids the key being cracked if stored in the first device without a secure hardware environment, but also ensures that the complexity of the key is not limited by the computing power of the first device, enabling the first device to support more types and more complex keys.
[0154] Optional, such as Figure 4B The flowchart shown may include the following steps before step 401:
[0155] 404. The first device checks the connection status of one or more second devices in the device list and selects a second device from the device list to process the key usage request; in step 401, the first device may send a key usage request to the selected second device to process the key usage request.
[0156] The first device stores a device list and association relationships. The device list includes the identifiers of second devices that are connected to the first device and store the key of the first device. The association relationships include the connection methods between each second device in the device list and the first device.
[0157] For example, the device list may include the identifiers of second device 1, second device 2, second device 3, and second device 4, which are associated with the first device and store the key of the first device. The association relationships include: the first device and second device 1 are associated via Bluetooth; the first device and second device 2 are associated via Bluetooth; the first device and second device 3 are associated via WiFi; and the first device and second device 4 are associated via wired connection.
[0158] When the first device obtains the connection status of one or more second devices in the device list, it first determines whether each second device in the device list can connect normally to the first device according to the connection method in the stored association relationship. The first device then selects the second device with the best connection status from the second devices that can connect normally. The second device with the best connection status may be, for example, the second device that responded to the connection first first, or the second device with the highest security level of the connection method with the first device.
[0159] If the first device selects the second device k according to the above selection method, then the first device sends a key usage request to the second device k.
[0160] In this way, the first device can select the second device with the best connection status from multiple second devices, thereby enabling it to process the data to be processed more quickly and efficiently using the key in the second device.
[0161] It should be understood that steps 401-404 above are steps in the process of using the key. Before using the key, the first device can entrust the key to the second device. That is, before using the key, the first device can send the key to the second device, which stores the key in a secure hardware environment.
[0162] Specifically, before using the key, the key usage method in this application embodiment may further include a step of escrowing the key, which can also be understood as a step of storing the key, such as... Figure 5 The flowchart shown may include the following steps for managing the key:
[0163] 501. The first device generates a key;
[0164] Specifically, the first device generates a key based on the business request from the business module. More specifically, the first device generates a key according to the key parameters input by the business module. The key parameters can be, for example, plaintext provided by the business module, which the first device encrypts to obtain the key.
[0165] 502. The first device sends a key escrow request to the second device, the key escrow request including a key;
[0166] After generating the key, the first device sends a key escrow request to the second device to escrow the key.
[0167] Specifically, the key escrow request may also include an index of the key, or an index of the escrow key. This way, when a subsequent business module needs to use the key, the first and second devices can determine which key the business module needs to use based on the key's index.
[0168] Optionally, the key escrow request may also include the identifier of the first device. This allows the second device to identify which first device sent the key based on the key escrow request.
[0169] Optionally, the key escrow request may also include a service identifier corresponding to the service module. This allows the second device to identify which service module the key belongs to based on the service identifier in the key escrow request.
[0170] 503. The second device stores the received key;
[0171] Specifically, the second device stores the key in a secure hardware environment.
[0172] Optionally, the second device includes a device list and associated relationships. The device list of the second device includes identifiers of multiple first devices, where each first device in the device list is a first device that has a communication connection with the second device and hosts the storage key of the second device. The associated relationships stored in the second device include the connection methods between each first device in the device list and the second device.
[0173] For example, the device list of the second device includes the identifiers of the first device 1, the first device 2, the first device 3, and the first device 4. The second device also stores the association relationship between the first device 1 and the second device as relation_1, the association relationship between the first device 2 and the second device as relation_2, the association relationship between the first device 3 and the second device as relation_3, and the association relationship between the first device 4 and the second device as relation_4.
[0174] If the first device sending the key is the first device 5, and the connection between the first device 5 and the second device is a WiFi connection, then the second device adds the identifier of the first device 5 to the device list and stores the association between the first device 5 and the second device as a WiFi connection.
[0175] In this way, the first device can entrust the key to the second device after it is generated. The second device then stores the key in a secure hardware environment, thereby ensuring the security of the key storage.
[0176] The association between the first and second devices during the key escrow phase is the same as the association between the first and second devices during key usage. During the key usage phase, the second device can determine the communication method with the first device based on the association relationships in its storage device list.
[0177] Optionally, the steps for managing the key may also include:
[0178] 504. The second device sends a management completion notification message to the first device.
[0179] In this way, after storing the key, the second device notifies the first device that the key has been successfully saved by sending a custody completion notification message. The first device confirms that the custody of the key has been completed based on the custody completion notification message.
[0180] Specifically, such as Figure 6 As shown, in the technical solution of this application, both the first device and the second device include a key hosting logic processing module, a local key management module, a device connection module, and a device association storage module.
[0181] The key escrow logic processing module is used to interface with upper-layer business and lower-layer functional modules, specifically for the logical processing of key escrow and usage processes.
[0182] The local key management module is used to handle key lifecycle management processes such as key generation, key storage, key usage, and key destruction.
[0183] The device connectivity module includes a device connectivity status awareness submodule and a connectivity method processing module. The device connectivity status awareness submodule is used to sense the connection status of the local device and the rich devices in the managed device list. The connectivity method processing module is used to manage the connection between the first device and the second device.
[0184] The device association storage module is used to store the device list and the association between each device in the device list and itself.
[0185] To better describe the technical solution of this application, the following is based on... Figure 6 The module structures of the first and second devices shown are illustrated, and the technical solution of this application is explained in detail in conjunction with the key storage method and the key usage method.
[0186] like Figure 7 The flowchart shown illustrates the key storage method. The key storage method of this embodiment includes the following steps:
[0187] 701. The key escrow logic processing module of the first device UDID_S receives the key escrow request sent by the service module;
[0188] When the business module of the first device needs to generate and store a key, it sends a key escrow request to the key escrow logic processing module of the first device. This escrow request may include key parameters used to generate the key. For example, it can be plaintext, enabling the local key management module to generate a key based on the plaintext.
[0189] Optionally, the business module can specify the key index keyAlias, the device list, and the association relationship. This association relationship can be understood as the communication connection method between the first device and the second device.
[0190] For example, the business module can specify that the device list includes second device 1 (UDID_1), second device 2 (UDID_2), second device 3 (UDID_3) and second device 4 (UDID_4), and indicate the connection relationship between second device 1 to second device 4 and the first device.
[0191] Specifically, the business module can specify the index keyAlias of the managed key and input a list of managed devices and corresponding relationships {(UDID_1, relation_1), (UDID_2, relation_2)……}.
[0192] 702. The key escrow logic processing module of the first device sends a key generation request to the local key management module;
[0193] After receiving the key escrow request from the business module, the key escrow logic processing module of the first device sends a key generation request to the local key management module. The key generation request includes the key parameter keyParams used to generate the key.
[0194] 703. The local key management module of the first device generates a key based on the key generation request;
[0195] The local key management module of the first device generates a key based on the key parameter keyParams in the key generation request and the key generation algorithm.
[0196] 704. The local key management module of the first device sends the generated key to the key escrow logic processing module of the first device;
[0197] 705. The key escrow logic processing module of the first device sends a key escrow request to the device connection module of the first device and requests to save the key generated by the local key management module to the second device;
[0198] After obtaining the key generated by the local key management module, the key escrow logic processing module of the first device sends a key escrow request to the device connection module of the first device to initiate the key escrow process.
[0199] 706. The key management logic processing module of the first device sends the device list and association relationship to the association relationship storage module of the first device.
[0200] In this way, the first device's association storage module stores the device list and its associations.
[0201] Specifically, the association relationship storage module of the first device stores keyAlias—UDID_S—{(UDID_1, relation_1), (UDID_2, relation_2)…….
[0202] 707. The device connection module of the first device reads the device list and association stored in the device association storage module, and sends a key escrow request to at least one second device in the device list. The key escrow request includes the key.
[0203] The device connection module of the first device sends a key escrow request to at least one second device in the device list according to the association relationship, so as to escrow the key.
[0204] For example, the device connection module of the first device sends a key escrow request to UDID_1 through relation_1.
[0205] The key escrow request may also include at least one of the following: an index of the key, an identifier of the first device, and an identifier of the business module.
[0206] 708. The device connection module of the second device receives the key escrow request sent by the device connection module of the first device, and sends the key escrow request to the key escrow logic processing module of the second device.
[0207] After receiving the key escrow request, the device connection module of the second device hands it over to the key escrow logic processing module of the second device for processing.
[0208] 709. The key escrow logic processing module of the second device sends the key escrow request to the local key management module of the second device.
[0209] 710. The local key management module of the second device receives and saves the key.
[0210] The local key management module of the second device stores the key in the secure hardware environment of the second device.
[0211] In this way, the key generated by the first device is managed by the local key management module stored on the second device.
[0212] 711. The key escrow logic processing module of the second device sends the association relationship between the second device and the first device to the device association relationship storage module of the second device.
[0213] The relationship between the second device and the first device includes the communication connection method between the second device and the first device.
[0214] Optionally, steps 711 and 709 can be executed in parallel.
[0215] In other words, while the key hosting logic processing module of the second device sends the key to the local key management module, it can also send the association relationship between the second device and the first device to the device association relationship storage module of the second device, so that the device association relationship storage module can store the association relationship between the first device and the second device.
[0216] 712. The device association relationship storage module of the second device stores the association relationship between the first device and the second device.
[0217] The connection between the first device and the second device is the communication connection method between the first device and the second device.
[0218] This association can be stored in the secure hardware environment of the second device, which can comprehensively protect the security of key-related data, thereby improving key security.
[0219] For example, the device association storage module of the second device i can store UDID_S—UDID_i, relation_i, i=1,2,3,4.
[0220] 713. The key escrow logic processing module of the second device sends an escrow completion notification to the device connection module of the second device;
[0221] 714. The connection management module of the second device sends a management completion notification to the device connection module of the first device;
[0222] In this way, through the above-described key storage steps, the first device can entrust the generated key to the secure hardware environment of the second device, thereby ensuring the security of the key during storage.
[0223] Optionally, the device connection module of the first device may send the key completion notification to the key escrow logic processing module of the first device.
[0224] like Figure 8 The flowchart shown illustrates the key usage method. The key usage method in this embodiment includes the following steps:
[0225] 801. The key escrow logic processing module of the first device receives a key usage request sent by the service module of the first device. The key usage request includes data to be processed. This data to be processed can be understood as the data of the key usage object.
[0226] Optionally, the key usage request may also include parameters required for key usage. This enables the second device to complete the key usage steps based on the key, the parameters required for key usage, and the data to be processed.
[0227] Optionally, the key usage request may also include an index, keyAlias, for the managed key. This allows the second device managing the key to determine the key to be used based on the keyAlias.
[0228] When a service module of the first device needs to use a key, it sends a key usage request to the key escrow logic processing module of the first device. For example, when the service module used for voiceprint recognition needs to encrypt the voiceprint, it can send a key usage request to the key escrow logic processing module of the first device to encrypt the voiceprint using the key. The voiceprint that needs to be encrypted can be understood as data to be processed, data of the key-using object, or parameters required when using the key.
[0229] 802. The key escrow logic processing module of the first device sends a key usage request to the device connection module.
[0230] The key escrow logic processing module sends the key usage request sent by the business module to the device connection module of the first device.
[0231] 803. The device connection module of the first device obtains the device list and association relationship from the association relationship storage module of the first device.
[0232] For example, the association storage module of the first device stores keyAlias—UDID_S—{(UDID_1, relation_1), (UDID_2, relation_2)...}. Then, the connection module of the first device can obtain keyAlias—UDID_S—{(UDID_1, relation_1), (UDID_2, relation_2)...} stored in the association storage module, thereby obtaining the list of devices and associations corresponding to the keys indexed by keyAlias.
[0233] 804. The device connection module of the first device determines the second device for processing key usage requests based on the device list and association relationships.
[0234] Specifically, the connection method processing unit of the device connection module checks the connection status of one or more second devices in the device list, and selects one second device from the one or more devices in the device list to process the key usage request.
[0235] The device connection module selects a scheme for the second device used to process key usage requests. Refer to the relevant description in the explanation of step 404 above, which will not be elaborated here.
[0236] For example, the device connection status sensing unit of the device connection module determines the local connection status and checks one by one whether each second device (UDID_i) in the device list can be connected through the specified connection relationship relationship_i (i is 1, 2, 3, 4, ..., n). Based on the available connection status of each device, it selects the optimal connection method relationship_k and the optimal second device UDID_k. The optimal connection method includes, but is not limited to, the device that responds first, the connection method with the highest security level, etc. relationship_k is one of relationship_1, relationship_2, relationship_3, ..., relationship_n.
[0237] 805. The device connection module of the first device sends a key usage request to the second device used to process key usage requests.
[0238] Optionally, the key usage request includes the key index, the data to be processed, and the parameters required for key usage. The parameters required for key usage can be understood as the relevant algorithm parameters for key usage.
[0239] 806. The device connection module of the second device receives the key usage request sent by the first device and sends the key usage request to the key escrow logic processing module of the second device.
[0240] It is understandable that the device connection module of the second device forwards the received key usage request to the key escrow logic processing module of the second device.
[0241] 807. The key escrow logic processing module of the second device obtains the stored association relationship from the device association relationship storage module.
[0242] For example, the key logic hosting processing module of the second device can determine the key to be used based on the key usage request, and determine the first device corresponding to the key and the connection relationship between the second device and the first device based on the device list and association stored in the device association storage module.
[0243] 808. The key escrow logic processing module of the second device verifies whether the key usage request is reasonable.
[0244] Specifically, the key escrow logic processing module of the second device verifies whether the first device sending the key usage request has the authority to request the second device to process the key usage request. For example, the key usage request may include the identifier of the first device. The key escrow logic module of the second device can verify whether the first device is a device in the device list based on the identifier of the first device, and verify whether the connection method between the first device and the second device conforms to the stored association relationship between the first device and the second device. If the first device is a device in the device list, and the connection relationship between the two also conforms to the stored association relationship between the first device and the second device, then the key usage request is verified as reasonable.
[0245] Steps 808 and 807 can be executed in parallel, or step 808 can be executed first and then step 807, or step 807 can be executed first and then step 808.
[0246] 809. When the key usage request is reasonable, the key escrow logic processing module of the second device sends the data to be processed in the key usage request and the parameters required for key usage to the local key management module of the second device.
[0247] Optionally, the key escrow logic processing module of the second device can also send the key index to the local key management module of the second device. This allows the local key management module of the second device to accurately determine which stored key needs to be used to process the data to be processed.
[0248] 810. The local key management module of the second device executes the key usage steps, processes the data to be processed using the stored key and the parameters required for key usage, and obtains the key usage result.
[0249] Key usage steps can include encryption, decryption, signing, signature verification, etc. Based on the example above where the data to be processed is a voiceprint to be encrypted, the local key management module of the second device can use the key hosted by the first device and related algorithm parameters to encrypt the voiceprint.
[0250] The result of key usage may include the data obtained after performing the key usage steps on the data to be processed, and may also include result information such as whether the key usage steps were executed normally.
[0251] 811. The local key management module of the second device sends the key usage result to the key hosting logic processing module of the second device.
[0252] 812. The key hosting logic processing module of the second device sends the key usage result to the device connection module.
[0253] 813. The device connection module of the second device sends the key usage result to the device connection module of the first device.
[0254] 814. The device connection module of the first device sends the key usage result to the key custody logic processing module of the first device.
[0255] 815. The key escrow logic processing module of the first device feeds back the key usage result to the business module.
[0256] Through steps 810-815, the second device feeds back the key usage result to the first device, enabling the service module that sent the key usage request to obtain the key usage result and complete the key usage process.
[0257] Therefore, the technical solution of this application involves the first device storing the key on a connected and authenticated second device, utilizing the secure hardware environment of the second device for key storage. The first device sends the parameters required for key usage and the data to be processed to the second device, leveraging the computing power of the second device to use the key, or in other words, using the computing power of the second device to process the data to be processed. In this way, storing the key on a second device with a secure hardware environment ensures the security of key storage; moreover, the keys usable by the first device can overcome the limitations of the first device's own computing power, allowing for a wider variety of keys that the first device can use.
[0258] This application provides a computer storage medium including computer instructions that, when executed on a terminal, cause the terminal to perform the processing method of an application in any of the above possible embodiments.
[0259] This application provides a computer program product that, when run on a terminal, causes the terminal to execute the processing method of the application in any of the above possible embodiments.
[0260] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A method for using a key, characterized in that, include: The first device sends a key usage request to the identified second device, which includes a secure hardware environment; The first device receives a key usage result sent by the second device. The key usage result is obtained by the second device processing the data to be processed in the key usage request based on the key in the security hardware environment.
2. The method according to claim 1, characterized in that, Before the first device sends a key usage request to the second device, the method further includes: The first device obtains the connection status between itself and one or more second devices in the device list; The first device selects a second device from the one or more second devices to process the key usage request based on the connection status between the first device and the one or more second devices. The first device sends a key usage request to the second device, including: The first device sends the key usage request to the second device used to process the key usage request.
3. The method according to claim 1, characterized in that, Before the first device sends a key usage request to the second device, the method further includes: The first device sends a key escrow request to the second device, the key escrow request including the key, the key escrow request being used to request the second device to store the key.
4. The method according to claim 3, characterized in that, The key escrow request also includes the index of the key, and the key escrow is further used to request the second device to save the index of the key; the key usage request includes the index of the key and the data to be processed.
5. A method for using a key, characterized in that... include: The second device receives a key usage request sent by the first device. The second device includes a secure hardware environment and is determined by the first device. The second device uses a key in the secure hardware environment to process the data to be processed in the key usage request, and obtains the key usage result; The second device sends the key usage result to the first device.
6. The method according to claim 5, characterized in that, Before the second device receives the key usage request sent by the first device, the method further includes: The second device receives a key escrow request from the first device, the key escrow request including the key; The second device stores the key in the secure hardware environment.
7. The method according to claim 6, characterized in that, The key escrow request also includes an index of the key; the method further includes: the second device storing the index of the key in the secure hardware environment; The key usage request includes the index of the key and the data to be processed.
8. An electronic device comprising a memory, one or more processors, and multiple application programs, wherein, The memory stores one or more programs; characterized in that, when the one or more processors run the one or more programs, the terminal performs the method as described in any one of claims 1 to 7.
9. A computer storage medium, characterized in that, Includes computer instructions that, when executed on a terminal, cause the terminal to perform the method as described in any one of claims 1 to 7.
10. A computer program product, characterized in that, When the computer program product is run on a terminal, the terminal causes the terminal to perform the method as described in any one of claims 1 to 7.