Authentication method, device and equipment based on pre-shared key

Abstract

The embodiment of the invention provides an authentication method, device and equipment based on a pre-shared key, in the authentication method based on the pre-shared key, after the equipment sends a key acquisition request to a first server, the equipment receives a ciphertext of the pre-shared key sent by the first server, then decrypts the ciphertext of the pre-shared key, and sends the decrypted ciphertext to the first server; according to the technical scheme of the invention, the method comprises the steps: obtaining a plaintext of a pre-shared key, and carrying out the identity authentication or encryption and decryption service with a second server according to the plaintext of the pre-shared key, thereby achieving the storage of a ciphertext of the pre-shared key encrypted by a key at a device side through a first server with a security authentication and authentication mechanism. Therefore, the security of the pre-shared key is greatly improved, and in the method, the key is separated from the ciphertext, and the first server does not have a decryption capability (because the first server does not have a decryption key), so that the risk of leakage of the pre-shared key at the first server side can be avoided.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of smart devices, and in particular to an authentication method, apparatus and device based on a pre-shared key. Background Art

[0002] The Internet of Things (IoT) is an Internet that connects everything, enabling interconnection between things and things, and between people and things. Devices can exchange information with servers by accessing the IoT. To ensure security, when a device initiates an access request, the server needs to authenticate the device, and only when the authentication is passed will the device be allowed to access the IoT. The device and the server will pre-store a common pre-shared key (PSK). Authentication based on pre-shared keys depends on the participation of time-varying parameters. During authentication, the pre-shared key is used to perform cryptographic operations on the timestamp, serial number or random number and then sent to the authenticator. The authenticator uses the same pre-shared key to perform the same operation, and uses the judgment rules of the timestamp, serial number and random number to make judgments to prove that the authenticated party has the correct pre-shared key, thereby judging the legitimacy of the authenticated party's identity.

[0003] The pre-shared key in the device cannot resist reverse analysis or dynamic hooking, so there may be security issues when using the pre-shared key in the device, and the solutions provided in the existing related technologies cannot solve the security issues of the pre-shared key in the device. Summary of the invention

[0004] The embodiments of the present application provide an authentication method, apparatus and device based on a pre-shared key. The embodiments of the present application also provide a readable storage medium to resist reverse analysis or dynamic hook and improve the security of the pre-shared key.

[0005] The first aspect provides an authentication method based on a pre-shared key, which is executed by a device and includes: sending a key acquisition request to a first server; receiving a ciphertext of a pre-shared key sent by the first server; wherein the ciphertext of the pre-shared key is obtained by encrypting the plaintext of the pre-shared key using a key on the device side; the plaintext of the pre-shared key is obtained by the device from a second server; the ciphertext of the pre-shared key is decrypted to obtain the plaintext of the pre-shared key; and identity authentication or encryption and decryption services are performed with the second server based on the plaintext of the pre-shared key.

[0006] In the above authentication method based on pre-shared key, after the device sends a key acquisition request to the first server, it receives the ciphertext of the pre-shared key sent by the first server, and then decrypts the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key, and then performs identity authentication or encryption and decryption services with the second server based on the plaintext of the pre-shared key, so that the first server with a security authentication and authorization mechanism can store the ciphertext of the pre-shared key encrypted with the key on the device side, thereby greatly improving the security of the pre-shared key and resisting reverse analysis or dynamic hooks. In addition, in the above method, the key is separated from the ciphertext (the key is on the device side, and the ciphertext is on the first server side), and the first server does not have the decryption capability (because the first server does not have the decryption key of the ciphertext of the pre-shared key), so that the risk of leakage of the pre-shared key on the first server side can be avoided.

[0007] In one possible implementation method, performing identity authentication or encryption / decryption services with the second server based on the plain text of the pre-shared key includes: using the plain text of the pre-shared key, or a key derived from the plain text of the pre-shared key, to perform identity authentication or encryption / decryption services with the second server.

[0008] In one possible implementation, sending a key acquisition request to the first server includes: sending an authentication request to the first server; performing two-way authentication with the first server; and after the two-way authentication passes, sending a key acquisition request to the first server.

[0009] In one possible implementation, after decrypting the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key, it also includes: storing the plaintext of the pre-shared key in the secure hardware environment of the device; or encrypting the plaintext of the pre-shared key using the key in the secure hardware environment of the device and storing it in the device.

[0010] In one possible implementation, the method further includes: using the plain text of the pre-shared key stored in the secure hardware environment of the device to perform identity authentication or encryption and decryption services with the second server; or, using the key in the secure hardware environment of the device to decrypt the pre-shared key encrypted and stored in the device to obtain the plain text of the pre-shared key, and using the plain text of the pre-shared key to perform identity authentication or encryption and decryption services with the second server.

[0011] In one possible implementation, after performing identity authentication or encryption / decryption services with the second server, it also includes: if the identity authentication fails or the decryption fails, determining that the pre-shared key has been updated; and re-executing the step of sending a key acquisition request to the first server and its subsequent steps.

[0012] In one possible implementation, before receiving the ciphertext of the pre-shared key sent by the first server, it also includes: receiving a security status detection request initiated by the first server; sending the security status data of the device to the first server so that the first server can determine whether the device is in a secure state.

[0013] In one possible implementation manner, the ciphertext of the pre-shared key sent by the first server includes the ciphertext of the pre-shared key sent by the first server after determining that the device is in a secure state.

[0014] In one possible implementation, the ciphertext of the pre-shared key sent by the first server includes: the ciphertext of the updated pre-shared key; wherein the ciphertext of the updated pre-shared key is the plaintext of the updated pre-shared key obtained by the device from the second server, encrypted with the key on the device side, and then saved in the first server.

[0015] The second aspect provides an authentication device based on a pre-shared key, which is included in a device and has the function of implementing the device behavior in the first aspect and the possible implementation of the first aspect. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions. For example, a sending module, a receiving module, an encryption and decryption module, and an authentication module.

[0016] The third aspect provides a device, comprising: one or more processors; a memory; multiple applications; and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs include instructions, and when the instructions are executed by the device, the device executes the method provided by the first aspect.

[0017] It should be understood that the second and third aspects of the embodiments of the present application are consistent with the technical solutions of the first aspect of the embodiments of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here.

[0018] A fourth aspect provides a readable storage medium, in which a program is stored. When the program is run on a device, the device executes the method provided in the first aspect.

[0019] The fifth aspect provides a program, which, when executed by a device, is used to execute the method provided by the first aspect.

[0020] In one possible design, the program in the fifth aspect may be stored in whole or in part on a storage medium packaged together with the processor, or may be stored in whole or in part on a memory not packaged together with the processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A flowchart for one-way authentication using a timestamp or sequence number;

[0022] Figure 2 A flowchart for one-way authentication using random numbers;

[0023] Figure 3 A schematic diagram of the structure of a device provided in one embodiment of the present application;

[0024] Figure 4 A schematic diagram of a system architecture provided for an embodiment of the present application;

[0025] Figure 5 An architectural diagram of a ciphertext for automatically updating a pre-shared key provided by an embodiment of the present application;

[0026] Figure 6 A flowchart of a pre-shared key-based authentication method provided by an embodiment of the present application;

[0027] Figure 7 A flowchart of a pre-shared key-based authentication method provided by another embodiment of the present application;

[0028] Figure 8 A flowchart of a pre-shared key-based authentication method provided in yet another embodiment of the present application;

[0029] Fig. 9 A schematic diagram of the structure of a device provided in another embodiment of the present application;

[0030] Fig.10 A schematic diagram of the structure of a device provided in yet another embodiment of the present application. DETAILED DESCRIPTION

[0031] The terms used in the implementation section of this application are only used to explain the specific embodiments of this application and are not intended to limit this application.

[0032] For identity authentication, the existing related technologies provide two one-way authentication schemes, namely "one-way authentication using a timestamp or a serial number" and "one-way authentication using a random number".

[0033] Figure 1Flowchart for one-way authentication using timestamp or sequence number. Figure 1 In the authentication scheme shown, authentication client A initiates authentication, and authentication server B authenticates authentication client A. Uniqueness and timeliness are controlled by generating and verifying a timestamp or a serial number.

[0034] The specific certification process may include:

[0035] Step 1: Authentication client A generates and sends a Token to authentication server B. AB Token AB =[T A |N A ]||Text2||fK AB ([T A |N A ]||B||Text1).

[0036] Among them, T A is the timestamp, N A is the serial number, [T A |N A ] means to select one of them, which one to choose depends on the technical capabilities and environment of the authentication client A and the authentication server B;

[0037] fK(X) is the cryptographic check value calculated for data X using the cryptographic check function f and the key K;

[0038] Text1 is known to the authentication server B or is contained in Text2.

[0039] The "B" in the formula represents the identity identifier of the authentication server B. AB Whether to include the identity identifier B in Token is optional. AB The identity identifier B is included to prevent the attacker from impersonating the authentication server B and reusing the token for the authentication client A. AB The inclusion of the identifier B is optional because it can be omitted in environments where this type of attack is not likely to occur.

[0040] Step 2: Once the Token is received AB The authentication server B verifies the timestamp or sequence number and calculates fK AB ([T A |N A ]||B||Text1) and compare it with the cryptographic check value in the received message, and verify the correctness of the identity identifier B (if any) and the timestamp or serial number to verify the Token AB .

[0041] Figure 2 This is a flowchart of one-way authentication using random numbers. Figure 2 In the authentication scheme shown, the authentication server B initiates the authentication process and authenticates the authentication client A. The uniqueness and timeliness are controlled by generating and verifying random numbers.

[0042] The specific certification process may include:

[0043] Step 0: Authentication client A requests login authentication from authentication server B.

[0044] Step 1: Authentication server B sends a random number R to authentication client A. B , and optionally send a text field Text1.

[0045] Step 2: Authentication client A generates and sends a Token to authentication server B AB ,

[0046] Token AB =Text3||fK AB (R B ||B||Text2).

[0047] fK(X) is the cryptographic verification value calculated for data X using the cryptographic verification function f and the key K.

[0048] Note: In Token AB The inclusion of the identifier B in the is to prevent the so-called reflection attack, the characteristic of which is that the intruder pretends to be the authentication client A and stimulates the random number R B "Reflect" to the authentication server B. In Token AB Whether to include the identifier B is optional. The reason why the identifier B is included is that the identifier can be omitted in an environment where such attacks will not occur.

[0049] Step 3: Once the Token is received AB , the authentication server B calculates fK AB (R B ||B||Text2) and compare it with Token AB The password check value in is compared and the correctness of the identity identifier B (if any) and the random number R sent to the authentication client A in step 1 is verified. B Is it related to Token AB The random number contained in the Token is consistent, thereby verifying the Token AB .

[0050] The pre-shared key in the device cannot resist reverse analysis or dynamic hook, so the device may not be safe to use the pre-shared key solution. However, general pan-network devices are in the operator's computer room, which is inaccessible to users and very difficult to dynamically hook, so it is more suitable to use an authentication solution based on pre-shared keys. However, some third-party ecological application scenarios, such as the authentication of third-party software development kits (SDKs) and third-party cloud servers, or the authentication of third-party Android application packages (APKs) and third-party cloud servers, still widely use pre-shared key authentication technology. Therefore, how to securely pre-set pre-shared keys in devices to resist reverse analysis or dynamic hooks and prevent pre-shared keys from being stolen is an urgent problem that needs to be solved.

[0051] The most commonly thought of solution to the above problems is encrypted storage. However, traditional cryptography was invented to solve the information transmission security of communication channels. As for what kind of attacks people or devices at both ends of the communication will be subject to, it is not within the scope of cryptography. In other words, the implicit assumption in the security model of traditional cryptography is that both parties in communication and their devices are trustworthy. For attackers, attackers can only intercept and / or modify the communication content on the communication channel. The two parties in communication are a black box to the attacker. The attacker can only see the input and output information of the black box, but knows nothing about what happens inside the black box. In this black box model, cryptography can play a good role. But in the scenario of devices, the user of the device can be the attacker. At the same time, because the device is in the hands of the attacker, the attacker can disassemble the device at any time and reverse analyze the software on it to crack it. In this scenario, traditional cryptography is powerless.

[0052] To solve this problem, 3 solutions are provided.

[0053] Solution 1: Secure Hardware Protection

[0054] Simply put, secure hardware protection is to put the key into a piece of hardware that is difficult to disassemble, so that (average) users cannot obtain the key. Common secure hardware environments can include:

[0055] Trusted execution environment (TEE), for example, TEE is a secure hardware environment in Android.

[0056] Software guard xtensions (SGX), SGX is a secure hardware environment on Intel chips;

[0057] The secure enclave processor (SEP), which is the secure hardware environment of the iPhone operating system (IOS);

[0058] Trusted platform module (TPM), etc.

[0059] However, the cost of protecting a proprietary secure hardware environment is relatively high, and some cheaper or lightweight devices do not have the ability to protect a secure hardware environment. For most third-party applications in the ecosystem, it is not possible to preset their own pre-shared keys in the secure hardware environment of all devices before the devices leave the factory. In addition, in the secure hardware protection solution, the pre-shared keys are not convenient to update dynamically.

[0060] Solution 2: White Box Cryptography

[0061] White-box cryptography assumes that the attacker has full control over the entire encryption operation process and is fully visible to it. In this case, the attacker faces a serious threat. Hackers can observe the operation of dynamic encryption without restriction, and the details of the internal algorithm are fully visible and can be changed at will. Although the method of white-box cryptography is completely transparent, it combines the pre-shared key so that the pre-shared key is not easy to extract. In short, white-box encryption is an encryption technology that can resist white-box attacks. The plaintext of the pre-shared key will be protected after white-box encryption. It will not appear directly in the memory, so it cannot be extracted.

[0062] However, although white-box cryptography can resist key recovery attacks to a certain extent, it cannot resist code extraction attacks. Even after code obfuscation, it only increases the workload of decompilation and the difficulty of some attacks, but does not increase the technical difficulty. In addition, the pre-shared key after white-box encryption is not convenient to update dynamically.

[0063] Solution 3: Root key management solution based on key components

[0064] In the root key management scheme based on key components, the key components that make up the root key are stored in a dispersed manner in the system, and the root key is dynamically generated by the key components only when needed. This method effectively solves the problem of "hard coding" of the root key and can ensure the security of the root key to a certain extent.

[0065] However, this solution cannot resist reverse analysis, and all key components may be extracted by decompilation and other means, and finally the root key is calculated. Even after code obfuscation, it only increases the workload of decompilation and increases the difficulty of some attacks, but does not increase the technical difficulty. Similarly, the encrypted pre-shared key is not convenient for dynamic update.

[0066] Based on the above problems, an embodiment of the present application provides an authentication method based on a pre-shared key, which can resist reverse analysis or dynamic hook and improve the security of the pre-shared key.

[0067] The pre-shared key-based authentication method provided in the embodiments of the present application can be applied to devices, wherein the above-mentioned devices include but are not limited to smart phones, tablet computers, wearable devices, smart robots, smart speakers, smart screen vehicle-mounted devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPC), netbooks or personal digital assistants (PDA) and other devices; the embodiments of the present application do not impose any restrictions on the specific types of devices.

[0068] For example, Figure 3 A schematic diagram of the structure of a device provided in one embodiment of the present application is shown in FIG. Figure 3 As shown, the device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light 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.

[0069] It is understandable that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the device 100. In other embodiments of the present application, the device 100 may include more or fewer components than shown, or combine some components, or separate some components, or arrange the components differently.

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

[0071] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0072] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

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

[0074] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only a schematic illustration and does not constitute a structural limitation on the device 100. In other embodiments of the present application, the device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0075] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the device 100. While the charging management module 140 is charging the battery 142, it may also power the device 100 through the power management module 141.

[0076] The power management module 141 is used to connect 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, and supplies power to the processor 110, the internal memory 121, the display screen 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0077] The wireless communication function of the device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0078] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antennas.

[0079] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G applied on the device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0080] The modem processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate 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 the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a receiver 170B, etc.), or displays an image or video through a display screen 194. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0081] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the device 100. 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 the antenna 2, modulates the frequency of the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0082] In some embodiments, antenna 1 of device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that device 100 can communicate with the network and other devices through wireless communication technology.

[0083] The device 100 implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0084] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0085] The device 100 can implement a shooting function through an ISP, a camera 193, a video codec, a GPU, a display screen 194, and an application processor.

[0086] The ISP is used to process data fed back by the camera 193. For example, when taking a photo, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, and the light signal is converted into an electrical signal. The camera photosensitive element transmits the electrical signal to the ISP for processing and converts it into an image visible to the naked eye.

[0087] The camera 193 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element converts the optical signal into an electrical signal, which is then transmitted to the ISP for conversion into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format.

[0088] Digital signal processors are used to process digital signals. In addition to processing digital image signals, they can also process other digital signals.

[0089] Video codecs are used to compress or decompress digital videos. Device 100 may support one or more video codecs. In this way, device 100 may play or record videos in multiple coding formats.

[0090] NPU is a neural network (NN) computing processor, which can quickly process input information and continuously self-learn by drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain. NPU can realize applications such as intelligent cognition of device 100.

[0091] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function.

[0092] The internal memory 121 can be used to store executable program codes, which include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function), etc. The data storage area may store data (such as audio data) created during the use of the device 100, etc. In addition, the internal memory 121 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. The processor 110 executes various functional applications and data processing of the device 100 by running instructions stored in the internal memory 121 and / or instructions stored in a memory provided in the processor.

[0093] The device 100 can implement audio functions through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D, and the application processor.

[0094] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signal. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 are arranged in the processor 110. The speaker 170A, also known as the "speaker", is used to convert audio electrical signals into sound signals. The receiver 170B, also known as the "earpiece", is used to convert audio electrical signals into sound signals. The microphone 170C, also known as the "microphone" and "microphone", is used to convert sound signals into electrical signals. The headphone interface 170D is used to connect wired headphones. The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. The gyroscope sensor 180B can be used to determine the motion posture of the device 100. The air pressure sensor 180C is used to measure the air pressure. The magnetic sensor 180D includes a Hall sensor. The acceleration sensor 180E can detect the magnitude of the acceleration of the device 100 in various directions (generally three axes). The distance sensor 180F is used to measure the distance. The proximity light sensor 180G may include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The ambient light sensor 180L is used to sense the brightness of the ambient light. The fingerprint sensor 180H is used to collect fingerprints. The temperature sensor 180J is used to detect the temperature. The touch sensor 180K, also known as a "touch device". The touch sensor 180K can be set on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, also known as a "touch screen". The bone conduction sensor 180M can obtain vibration signals. The button 190 includes a power button, a volume button, etc. The motor 191 can generate a vibration prompt. The indicator 192 can be an indicator light, which can be used to indicate the charging status, the change of the power, and can also be used to indicate messages, missed calls, notifications, etc. The SIM card interface 195 is used to connect the SIM card. In some embodiments, the device 100 uses an eSIM, ie, an embedded SIM card.

[0095] The authentication method based on pre-shared key provided in the embodiment of the present application can be applied to the scenario where the device 100 and another device are authenticated by using the pre-shared key, wherein the other device can be a server set in the cloud, or a device other than the device 100. Specifically, the authentication method based on pre-shared key provided in the embodiment of the present application can be applied to the pre-setting and updating of the pre-shared key in the device 100 when another device authenticates the device 100 by using the pre-shared key.

[0096] Figure 4 A schematic diagram of a system architecture provided for an embodiment of the present application is shown in FIG. Figure 4 As shown, the above system architecture includes a first server 401 , a second server 402 and a device 100 .

[0097] Among them, the second server 402 and the device 100 perform identity authentication or encryption and decryption services based on the pre-shared key. In order to ensure the security of the pre-shared key used by the device 100 and the second server 402, the pre-shared key is not directly stored in the device 100, but the pre-shared key is encrypted using white box encryption or a root key management scheme based on key components and then stored in the first server 401. Here, the first server 401 is a cloud device with a complete and secure authentication mechanism with the device 100. The authentication mechanism here can be various existing mature and secure authentication mechanisms, such as: public key infrastructure (PKI) certificate authentication mechanism, public and private key authentication mechanism, account authentication mechanism and / or pre-shared key authentication mechanism, etc.

[0098] The second server 402 is a cloud device that needs to be authenticated with the device 100 through a pre-shared key, and it is necessary to consider how to securely pre-set the pre-shared key to the device 100. The pre-shared key of the second server 402 is generally directly stored in encrypted form in the memory of the second server 402, and is directly obtained and decrypted from the second server 402 when needed.

[0099] Of course, the embodiments of the present application are not limited to this. The first server 401 and the second server 402 can also be replaced by other types of devices other than servers. For example, the other devices can be smart phones, set-top boxes, tablet computers, wearable devices, smart robots, smart speakers, smart screen car devices, laptops, UMPCs, netbooks or PDAs and other devices. This embodiment is not limited to this, but in the description of the following embodiments of the present application, the first server 401 and the second server 402 are used as examples for illustration.

[0100] For ease of understanding, the following embodiments of the present application will be described in detail with Figure 3 As an example, the device with the structure shown in the figure is Figure 4 The system architecture shown specifically describes the pre-shared key-based authentication method provided in the embodiment of the present application.

[0101] The authentication method based on the pre-shared key provided in the embodiment of the present application may include:

[0102] Step 0: Preset process. Specifically, step 0 may include:

[0103] Step 01 : A pre-shared key for authentication with the device 100 is preset in the second server 402 . The pre-shared key is generally encrypted and stored locally in the second server 402 .

[0104] Step 02: The first server 401 is provisioned with a device 100 that encrypts the ciphertext of the pre-shared key using a terminal-side key (such as white-box encryption or a root key management solution based on a key component).

[0105] It should be noted that step 01 and step 02 may be executed in parallel or sequentially, and this embodiment does not limit the execution order of step 01 and step 02.

[0106] Step 1: First authentication process. Specifically, step 1 may include:

[0107] Step 11: When the device 100 needs to authenticate with the second server 402, the device 100 first sends an authentication request to the first server 401, and the first server 401 and the device 100 start two-way authentication.

[0108] The two-way authentication here can adopt various existing mature and secure authentication mechanisms, such as: PKI certificate authentication mechanism, public-private key authentication mechanism, account authentication mechanism and / or pre-shared key authentication mechanism.

[0109] Step 12: After the two-way authentication is passed, the device 100 initiates a key acquisition request to the first server 401. After the first server 401 authenticates the device 100, it proceeds to step 13.

[0110] Step 13, optionally, the first server 401 initiates a security status detection request to the device 100 to check whether the device 100 is in a safe state, for example: detecting whether the device 100 is in a root user (root) state, whether the security level of the device 100 reaches a threshold, whether there is a secure hardware environment, whether antivirus software is installed, whether there are abnormalities in traffic monitoring and / or whether a lock screen password is set, etc.

[0111] In step 14 , the device 100 returns security status data to the first server 401 . If the first server 401 determines that the device 100 is in a secure state, the first server 401 sends a ciphertext of the pre-shared key to the device 100 .

[0112] In step 15 , the device 100 decrypts the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key, and uses the plaintext of the pre-shared key to perform identity authentication or encryption and decryption services with the second server 402 .

[0113] Step 16: If there is a secure hardware environment in the device 100, the plain text of the pre-shared key in step 15 can be stored in the secure hardware environment; or the plain text of the pre-shared key can be encrypted and stored using the key in the secure hardware environment (such as encrypted storage using Android's keystore) for subsequent use. In the subsequent authentication process, the device 100 will first obtain the pre-shared key from the secure hardware environment of the device 100; and if the device 100 does not have a secure hardware environment, after the pre-shared key is used, the device 100 will clear the pre-shared key stored in the internal memory (including the plain text and cipher text of the pre-shared key), and continue to obtain the pre-shared key from the first server 401 the next time it is used.

[0114] Step 2: Subsequent authentication process. Specifically, step 2 may include:

[0115] Step 21, if the device 100 does not store the pre-shared key in the first authentication process (for example: there is no secure hardware environment in the device 100), the subsequent authentication process between the device 100 and the second server 402 is the same as the first authentication process, which will not be repeated here.

[0116] In step 22, if there is a secure hardware environment in the device 100 and a pre-shared key has been stored in the first authentication process, the device 100 will subsequently preferentially use the locally stored pre-shared key to perform identity authentication or encryption and decryption services with the second server 402.

[0117] Specifically, if the plain text of the pre-shared key is stored in the secure hardware environment of the device 100, the device 100 uses the plain text of the pre-shared key stored in the secure hardware environment to perform identity authentication or encryption and decryption services with the second server 402. If the pre-shared key in the device 100 is stored in an encrypted form, the key in the secure hardware environment of the device 100 can be used to first decrypt the encrypted pre-shared key stored in the device 100 to obtain the plain text of the pre-shared key, and then the plain text of the pre-shared key can be used to perform identity authentication or encryption and decryption services with the second server 402.

[0118] Step 3, the update process of the pre-shared key. Specifically, step 3 may include:

[0119] In step 31, the second server 402 updates the preset stored pre-shared key to a new version of the pre-shared key, and the second server 402 encrypts and stores the new version of the pre-shared key in an internal memory.

[0120] In step 32, the first server 401 updates the ciphertext of the pre-shared key stored in the pre-set state to the ciphertext of the new pre-shared key encrypted using the end-side key of the device 100. In specific implementation, the device 100 may encrypt the new version of the pre-shared key using white box encryption or a root key management solution based on key components.

[0121] Step 4, authentication process after the pre-shared key is updated. Specifically, step 4 may include:

[0122] Step 41, if the device 100 does not store the pre-shared key in the first authentication process or the authentication process that has been carried out, the authentication process after the pre-shared key is updated is the same as the first authentication process, which will not be repeated here.

[0123] Step 42: If the device 100 has stored a pre-shared key in the initial authentication process or in an ongoing authentication process, the locally stored pre-shared key is preferentially used to perform identity authentication or encryption / decryption services with the second server 402.

[0124] Step 43, if the identity authentication with the second server 402 using the locally stored pre-shared key in step 42 fails, it proves that the pre-shared key has been updated, and the ciphertext of the new pre-shared key is obtained from the first server 401 again. The subsequent steps are the same as the first authentication process.

[0125] The authentication method based on pre-shared keys provided in the embodiment of the present application can prevent the pre-shared keys from being cracked in the device 100 that does not have a secure hardware environment if the device 100 does not have a secure hardware environment, thereby improving the security of the pre-shared keys. If the device 100 has a secure hardware environment, it can also solve the problem that third-party manufacturers or some self-developed applications cannot pre-set their own pre-shared keys in the secure hardware environment of all devices 100 before the device 100 leaves the factory.

[0126] In addition, the ciphertext of the pre-shared key in the first server 401 is encrypted and stored using the key on the device 100, the key is separated from the ciphertext (the key is on the device 100 side, and the ciphertext is on the first server 401 side), and the first server 401 does not have the decryption capability (because the first server 401 does not have the decryption key for the ciphertext of the pre-shared key), thereby avoiding the risk of leakage of the pre-shared key on the first server 401 side.

[0127] The authentication method based on pre-shared keys provided in the embodiment of the present application also solves the problem that it is inconvenient to dynamically update the pre-shared keys in the terminal. Furthermore, even if the device 100 is completely controlled by an attacker (for example, the root privilege is obtained), since the first server 401 will check whether the device 100 is in a safe state, it will not send the ciphertext of the pre-shared key to the device 100 if a security risk is detected, and the risk of the pre-shared key being leaked on the terminal side can also be avoided.

[0128] In the existing related technologies, devices generally do not have a secure hardware environment, or manufacturers are unable to pre-set the pre-shared key in the secure hardware environment of all devices before the devices leave the factory. Pre-shared keys are generally pre-set in devices through white box encryption, root key management scheme encryption based on key components, or direct plain text storage, which cannot resist reverse analysis or dynamic hooks, making pre-shared keys easy to crack. The embodiment of the present application introduces a first server 401 with a security authentication and authorization mechanism with the device 100 to store the ciphertext of the pre-shared key, thereby greatly improving the security of the pre-shared key and solving the pre-setting and update problems of the above-mentioned pre-shared key.

[0129] Moreover, in the embodiment of the present application, the ciphertext of the pre-shared key in the first server 401 is stored after being encrypted using the key on the device 100, and the key is separated from the ciphertext (the key is on the device 100 side, and the ciphertext is on the first server 401 side). The first server 401 does not have the decryption capability, thereby avoiding the risk of leakage of the pre-shared key on the first server 401 side.

[0130] The first server 401 checks whether the device 100 is in a safe state, such as whether the device 100 is in a root state, whether the device security level reaches a threshold (whether there is a secure hardware environment), whether anti-virus software is installed, whether there are abnormalities in traffic monitoring and / or whether a lock screen password is set, etc. If a security risk is detected, the ciphertext of the pre-shared key will not be sent to the device 100, thereby avoiding the risk of the pre-shared key being leaked on the device 100 side.

[0131] The following describes the two-way authentication scheme between the first server 401 and the device 100 in step 11.

[0132] Since the first server 401 is set in the cloud, the authentication between the first server 401 and the device 100 is end-to-end authentication. End-to-end authentication is a problem that devices often need to face. For security reasons, many current scenarios involving cloud-based interactions require two-way authentication, that is, the device 100 side needs to verify the identity of the first server 401 to ensure that it is not counterfeited, and the first server 401 also needs to verify the identity of the device 100 to ensure that it is not counterfeited. When the front-end side authenticates the cloud, the most common way is to authenticate through the secure sockets layer (SSL) / transport layer security (TLS) certificate when performing hypertext transfer protocol secure (HTTPS) communication, and there are many common methods for the cloud side to authenticate the end side. Here we introduce common public and private key authentication schemes, PKI certificate authentication schemes, and pre-shared key authentication schemes.

[0133] 1. Public and private key authentication scheme

[0134] 1. Product production stage:

[0135] 1) The device is pre-set with a private key during the production phase;

[0136] 2) The corresponding public key is stored on the manufacturer's device public key server;

[0137] 2. Identity Authentication:

[0138] 1) The device signs the data using the private key on the client side and sends the signed data to the server side;

[0139] 2) The server queries the public key server for the public key corresponding to the device, and uses the public key to verify the signed data to complete the identity authentication of the device.

[0140] 2. PKI Certificate Authentication Solution

[0141] Two-way authentication:

[0142] The device trusts the cloud side, and the device pre-installs the cloud side's HTTPS certificate and passes HTTPS authentication;

[0143] The cloud side trusts the device, and the cloud side pre-installs the manufacturer's certificate authority (CA) root certificate and passes the PKI authentication.

[0144] Certification process:

[0145] 1. The manufacturer's CA server issues a unique certificate for each device that leaves the factory (each device is different);

[0146] 2. The product manufacturer will pre-install the issued device certificate and the corresponding device key into each device;

[0147] 3. Cloud services or third-party servers only need to pre-install the root certificate (there is no need to pre-install device certificates for all devices);

[0148] 4. When performing device authentication on the device side, the multi-level certificate chain needs to be uploaded to the cloud service or third-party server;

[0149] 5. The cloud service or third-party server uses the root certificate to verify the legitimacy of the certificate chain uploaded by the device to verify the legitimacy of the device's identity.

[0150] 3. Pre-shared key authentication scheme

[0151] The pre-shared key authentication scheme is a widely used authentication scheme. Because the pre-shared key is the credential for authentication between two parties, the two parties A and B should share a common secret authentication key K before starting authentication. AB , or two one-way secret keys K AB and K BA , one-way key K AB and K BA B is used to authenticate A and A is used to authenticate B respectively.

[0152] Authentication based on pre-shared keys all rely on the participation of time-varying parameters. During authentication, the pre-shared key (or the authentication key derived from the pre-shared key) is used to perform cryptographic operations on the timestamp, serial number or random number and then sent to the authenticator. The authenticator uses the same pre-shared key (or the same authentication key derived from the pre-shared key) to perform the same operation and uses the judgment rules of the timestamp, serial number and / or random number to prove that the authenticated party has the correct pre-shared key, thereby judging the legitimacy of the authenticated party's identity.

[0153] Authentication methods based on pre-shared keys can be divided into two categories based on encryption methods: symmetric encryption algorithms and cryptographic verification functions. Common symmetric encryption algorithms include Advanced Encryption Standard (AES) 128 and AES256; common cryptographic verification functions include hash-based message authentication code (HMAC) or cipher block chaining-message authentication code (CMAC). The advantages of symmetric encryption algorithms are that in addition to achieving authentication by encrypting time-varying parameters, they can also encrypt the to-be-executed messages or commands that are transmitted along with the time-varying parameters to ensure the confidentiality of the message. However, when symmetric encryption algorithms are difficult to obtain or do not meet the product's computing performance requirements, the cryptographic verification function method can be used.

[0154] For the authentication method using symmetric encryption and password verification of pre-shared keys, two categories of ten models of authentication using pre-shared keys are described according to the different encryption methods selected, different time-varying parameters selected, one-way or two-way authentication, and / or whether a trusted third party is involved in the authentication. When designing an authentication scheme based on pre-shared keys, you can directly use the existing standard authentication protocol based on pre-shared keys, or you can use these ten authentication models.

[0155] The first server 401 and the device 100 can ensure through two-way authentication that the identities of the first server 401 and the device 100 are authentic and not forged, and attackers cannot carry out man-in-the-middle attacks, thus avoiding the risk of data leakage and the leakage of the ciphertext of the pre-shared key.

[0156] The scheme of presetting the ciphertext of the pre-shared key in the first server 401 in step 02 and updating the ciphertext of the pre-shared key in the first server 401 in step 32 is described below.

[0157] The pre-shared key is stored in the first server 401 after being encrypted using the key on the device 100 (such as white box encryption or a root key management scheme based on key components). After manually performing encryption on a device 100, the ciphertext can be manually configured to the first server 401 through operation and maintenance. It is also possible to connect the first server 401 and the second server 402 through a key management cloud server to achieve automatic configuration and update of the key. The following first introduces the basic concepts of white box encryption technology and root key management scheme based on key components:

[0158] White-box encryption technology: White-box encryption technology (also known as white-box cryptography technology) assumes that the attacker has full control over the entire encryption operation process and is fully visible to it. The attacker can observe the operation process of dynamic password generation without restriction, and the detailed content and process of the internal algorithm are also fully visible and can be changed at will. Although the method of white-box cryptography technology is completely transparent, white-box encryption tightly binds the algorithm and key together, and generates an encryption table and a decryption table from the algorithm and key. Then, encryption can be performed independently by looking up the encryption table and decryption can be performed by using the decryption table, which no longer depends on the original encryption and decryption algorithm and key. One implementation idea of ​​white-box encryption is to completely replace the algorithm with a lookup table. Because the algorithm is known and the encryption key is known, the algorithm and key are solidified into a lookup table representation, which is the implementation process of the white-box key. In short, white-box encryption is an encryption technology that can resist white-box attacks. The plaintext key will not appear directly in the memory, so it will not be extracted.

[0159] The security of white-box cryptography itself is divided into two requirements: one is that it is difficult for an attacker to recover the key from the pre-calculated table; the other is that the attacker cannot invert the white-box encryption (decryption) function to calculate the decryption (encryption), which means that it is difficult to invert the white-box encryption and decryption algorithm. If the attacker can recover the key, then he must be able to invert it, so if you can defend against inversion attacks, you can definitely defend against key recovery attacks; but conversely, if you defend against key recovery attacks, you may not be able to defend against inversion attacks. Therefore, the feature that can defend against key recovery attacks is called weak white-box security, and the feature that can defend against inversion attacks is called strong white-box security.

[0160] Root key management scheme based on key components: In the root key management scheme based on key components, the key components that make up the root key are stored in a dispersed manner in the system, and the root key is dynamically generated by the key components only when needed. This method effectively solves the problem of "hard coding" of the root key and ensures the security of the root key to a certain extent.

[0161] In the root key management scheme based on key components, key components are multiple blocks of fixed-length random data generated by a secure random number generator. These key components are stored in the system in a dispersed manner. Key components can be saved in the form of files or partially hard-coded into the code. When generating a root key, all key components need to be input into the key generation module, and the root key is obtained after calculation by the key derivation algorithm. After the root key is generated, it is only stored in the memory. All cryptographic operations using the root key are performed in the root key cryptographic operation module. The business logic module cannot directly access the root key data. It can only input the plaintext (or ciphertext) of the key to be protected into the root key cryptographic module. The root key cryptographic module uses the root key to operate and outputs the ciphertext (or plaintext) of the key.

[0162] The ciphertext presetting or updating scheme of the pre-shared key can be implemented in two ways: manual operation and maintenance and automatic operation.

[0163] 1. Manual operation and maintenance, that is, the ciphertext of the pre-shared key in the first server 401 is preset or updated by manual operation and maintenance, specifically including:

[0164] Step 1: Obtain or negotiate the plain text of the pre-shared key between the second server 402 and the device 100 from the manufacturer of the second server 402 .

[0165] Step 2: Use a device 100 to encrypt the plain text of the pre-shared key using the key on the device 100 to obtain the ciphertext. The encryption method may be a commonly used symmetric encryption method, such as the AES-Galois counter mode (GCM) mode encryption algorithm.

[0166] Step 3, export the encrypted ciphertext, and then preset or update the ciphertext to the first server 401 through manual operation and maintenance. The storage method on the first server 401 can be stored in various ways such as configuration files and / or databases, which is not limited in this embodiment.

[0167] 2. Automatically presetting or updating, specifically, Figure 5 The following is an architecture diagram of the ciphertext of the automatic update pre-shared key provided by an embodiment of the present application. Figure 5 A scheme for automatically updating the ciphertext of a pre-shared key is introduced.

[0168] Step 1, the second server 402 sends the plain text of the pre-shared key that needs to be preset or updated to the key management server 501 of the device 100 manufacturer through an encrypted channel of a wired or wireless network (for example, transport layer security (TLS) protocol or HTTPS protocol). The key management server 501 can be set in the cloud.

[0169] In step 2, the key management server 501 is pre-set with the same key as the key on the device 100, and the same encryption algorithm (such as white box encryption or a root key management scheme based on key components). The key management server 501 encrypts the plain text of the pre-shared key obtained from the second server 402 to obtain the ciphertext of the pre-shared key.

[0170] Step 3: The password management server 501 sends the ciphertext of the pre-shared key to the first server 401 via a wired or wireless network encryption channel (eg, TLS protocol or HTTPS protocol).

[0171] In step 4, the first server 401 presets or updates the ciphertext of the pre-shared key obtained from the key management server 501 to the first server 401 to make it effective. The ciphertext of the pre-shared key can be stored in the first server 401 in a variety of ways such as a configuration file and / or a database, which is not limited here.

[0172] Step 5: The first server 401 notifies the key management server 501 of the result (success or failure) of pre-setting or updating the pre-shared key.

[0173] Step 6: The key management server 501 notifies the second server 402 of the result (success or failure) of pre-setting or updating the pre-shared key.

[0174] Step 7: If the second server 402 receives a notification that the pre-shared key has been successfully preset or updated, the second server 402 activates the new pre-shared key to perform subsequent authentication processes.

[0175] As described above, an embodiment of the present application provides an authentication method based on a pre-shared key. The device 100 stores the ciphertext of the pre-shared key encrypted with the key of the device 100 side through a cloud (first server 401) with a secure authentication and authorization mechanism, thereby greatly improving the security of the pre-shared key and solving the problem of pre-setting and updating the pre-shared key.

[0176] Figure 6 A flowchart of a pre-shared key-based authentication method provided by an embodiment of the present application, such as Figure 6 As shown, the above authentication method based on the pre-shared key may include:

[0177] In step 601, the device 100 sends a key acquisition request to the first server 401. The key acquisition request is used to acquire a pre-shared key for identity authentication or encryption / decryption services with the second server 402.

[0178] Specifically, the device 100 sending a key acquisition request to the first server 401 may include: the device 100 sending an authentication request to the first server 401 and performing a two-way authentication with the first server 401; after the above two-way authentication passes, the device 100 sends a key acquisition request to the first server 401.

[0179] Step 602 : The device 100 receives the ciphertext of the pre-shared key sent by the first server 401 .

[0180] The ciphertext of the pre-shared key is obtained by encrypting the plaintext of the pre-shared key using the key on the device 100 side; the plaintext of the pre-shared key is obtained by the device 100 from the second server 402.

[0181] Specifically, the plain text of the pre-shared key being obtained by the device 100 from the second server 402 may include: the pre-shared key being obtained by the device 100 from the second server; or the pre-shared key being generated by negotiation between the device 100 and the second server 402 .

[0182] In this embodiment, the ciphertext of the pre-shared key sent by the first server 401 may be the ciphertext of the updated pre-shared key; wherein the ciphertext of the updated pre-shared key is obtained by the device 100 from the second server 402, and is encrypted using the key on the device 100 side and then saved in the first server 401. As mentioned above, the update of the pre-shared key may be performed in two ways: manual operation and maintenance and automatic operation, which will not be described in detail here.

[0183] In step 603, the device 100 decrypts the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key.

[0184] In step 604, the device 100 performs identity authentication or encryption / decryption services with the second server 402 according to the plain text of the pre-shared key.

[0185] Specifically, according to the plain text of the pre-shared key, identity authentication or encryption and decryption services with the second server can be: using the plain text of the pre-shared key or a key derived from the plain text of the pre-shared key to perform identity authentication or encryption and decryption services with the second server 402.

[0186] In the above authentication method based on pre-shared key, after the device 100 sends a key acquisition request to the first server 401, it receives the ciphertext of the pre-shared key sent by the first server 401, and then decrypts the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key, and then performs identity authentication or encryption and decryption services with the second server 402 according to the plaintext of the pre-shared key, so that the first server 401 with a security authentication and authorization mechanism can store the ciphertext of the pre-shared key encrypted with the key on the device 100 side, thereby greatly improving the security of the pre-shared key and resisting reverse analysis or dynamic hook. In addition, in the above method, the key is separated from the ciphertext (the key is on the device 100 side, and the ciphertext is on the first server 401 side), and the first server 401 does not have the decryption capability (because the first server 401 does not have the decryption key of the ciphertext of the pre-shared key), so that the risk of leakage of the pre-shared key on the first server 401 side can be avoided.

[0187] Figure 7 A flowchart of a pre-shared key-based authentication method provided in another embodiment of the present application is shown in FIG. Figure 7 As shown, this application Figure 6In the illustrated embodiment, after step 603, the following may also be included:

[0188] Step 701 , the device 100 stores the plain text of the pre-shared key in the secure hardware environment of the device 100 ; or encrypts the plain text of the pre-shared key using a key in the secure hardware environment of the device 100 and stores it in the device 100 .

[0189] In step 702, the device 100 uses the plain text of the pre-shared key stored in the secure hardware environment of the device 100 to perform identity authentication or encryption and decryption services with the second server 402; or, uses the key in the secure hardware environment of the device 100 to decrypt the encrypted pre-shared key stored in the device 100, obtains the plain text of the pre-shared key, and uses the plain text of the pre-shared key to perform identity authentication or encryption and decryption services with the second server 402.

[0190] That is, if there is a secure hardware environment in the device 100 and a pre-shared key has been stored in the first authentication process or an ongoing authentication process, the device 100 will subsequently preferentially use the locally stored pre-shared key to perform identity authentication or encryption and decryption services with the second server 402.

[0191] Furthermore, after step 702, the following steps may also be included:

[0192] Step 703, if the identity authentication fails or the decryption fails, the device 100 determines that the above-mentioned pre-shared key has been updated. After that, the device 100 re-executes step 601 and its subsequent steps. It should be noted that when the device 100 re-executes step 701, the device 100 can store the plaintext of the re-acquired pre-shared key in the secure hardware environment of the device 100, and delete the plaintext of the pre-shared key originally stored in the secure hardware environment of the device 100; or use the key in the secure hardware environment of the device 100 to encrypt the plaintext of the re-acquired pre-shared key, store it in the device 100, and delete the pre-shared key originally encrypted and stored in the device 100.

[0193] Figure 8 A flowchart of a pre-shared key-based authentication method provided in another embodiment of the present application is shown in FIG. Figure 8 As shown, this application Figure 6 In the illustrated embodiment, before step 602, the following may also be included:

[0194] Step 801 : the device 100 receives a security status detection request initiated by the first server 401 .

[0195] In step 802, the device 100 sends the security status data of the device 100 to the first server 401, so that the first server 401 can determine whether the device is in a safe state.

[0196] In this way, in step 602, the ciphertext of the pre-shared key sent by the first server 401 may be the ciphertext of the pre-shared key sent by the first server 401 after determining that the device 100 is in a secure state.

[0197] In this embodiment, the device 100 receives a security status detection request initiated by the first server 401, and the above security status detection request is used to check whether the device 100 is in a secure state, such as whether the device 100 is in a root state, whether the device security level reaches a threshold (whether there is a secure hardware environment), whether anti-virus software is installed, whether there are abnormalities in traffic monitoring and / or whether a lock screen password is set, etc. Then, the device 100 sends the security status data of the device 100 to the first server 401. After the first server 401 determines that the device 100 is in a secure state based on the above security status data, the first server 401 sends the ciphertext of the pre-shared key to the device 100. If the first server 401 detects a security risk, it will not send the ciphertext of the pre-shared key to the device 100, thereby avoiding the risk of the pre-shared key being leaked on the device 100 side.

[0198] It is to be understood that some or all of the steps or operations in the above embodiments are merely examples, and the embodiments of the present application may also perform other operations or variations of various operations. In addition, the various steps may be performed in different orders presented in the above embodiments, and it is possible that not all of the operations in the above embodiments need to be performed.

[0199] It is understandable that, in order to implement the above functions, the device includes hardware and / or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiments disclosed in this application, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of this application.

[0200] This embodiment can divide the functional modules of the device according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one module. The above integrated module can be implemented in the form of hardware. It should be noted that the division of modules in this embodiment is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0201] Fig. 9A schematic diagram of the structure of a device provided in another embodiment of the present application, in which each functional module is divided according to each function, Fig. 9 A possible schematic diagram of the composition of the device 900 involved in the above embodiment is shown. Fig. 9 As shown, the device 900 may include: a sending module 901, a receiving module 902, an encryption and decryption module 903 and an authentication module 904;

[0202] The sending module 901 is used to send a key acquisition request to the first server;

[0203] The receiving module 902 is used to receive the ciphertext of the pre-shared key sent by the first server; wherein the ciphertext of the pre-shared key is obtained by encrypting the plaintext of the pre-shared key using the key on the device side; the plaintext of the pre-shared key is obtained by the device from the second server;

[0204] The encryption and decryption module 903 is used to decrypt the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key;

[0205] An authentication module 904, configured to perform identity authentication with the second server according to the plain text of the pre-shared key;

[0206] The encryption and decryption module 903 is further used to perform encryption and decryption services with the second server according to the plain text of the pre-shared key.

[0207] In this embodiment, the authentication module 904 is specifically configured to use the plain text of the pre-shared key, or a key derived from the plain text of the pre-shared key, to perform identity authentication with the second server.

[0208] The encryption and decryption module 903 is specifically configured to use the plain text of the pre-shared key, or a key derived from the plain text of the pre-shared key, to perform encryption and decryption services with the second server.

[0209] It should be noted that this application Figure 6 All relevant contents of each step involved in the illustrated method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0210] The device 900 provided in this embodiment is used to execute the present application Figure 6 The authentication method based on the pre-shared key provided in the illustrated embodiment can therefore achieve the same effect as the above method.

[0211] Fig.10 A schematic diagram of a structure of a device provided in another embodiment of the present application, Fig. 9 Compared to the devices shown, Fig.10In the device 900 shown, the sending module 901 is further used to send an authentication request to the first server;

[0212] The authentication module 904 is further used to perform two-way authentication with the first server;

[0213] The sending module 901 is further configured to send a key acquisition request to the first server after the above two-way authentication is passed.

[0214] Furthermore, the device 900 may also include: a storage module 905;

[0215] The storage module 905 is used to store the plain text of the pre-shared key in the secure hardware environment of the device after the encryption / decryption module 903 obtains the plain text of the pre-shared key; or to encrypt the plain text of the pre-shared key using the key in the secure hardware environment of the device and store it in the device.

[0216] Thus, the authentication module 904 is specifically used to use the plain text of the pre-shared key stored in the secure hardware environment of the device to perform identity authentication with the second server; or the encryption and decryption module 903 is specifically used to use the plain text of the pre-shared key stored in the secure hardware environment of the device to perform encryption and decryption services with the second server;

[0217] or,

[0218] The encryption and decryption module 903 is further used to use the key in the secure hardware environment of the above-mentioned device to decrypt the pre-shared key encrypted and stored in the device to obtain the plain text of the pre-shared key;

[0219] The authentication module 904 is specifically used to perform identity authentication with the second server using the plain text of the pre-shared key; or the encryption and decryption module 903 is specifically used to perform encryption and decryption services with the second server using the plain text of the pre-shared key.

[0220] Furthermore, the device 900 may also include: a determination module 906;

[0221] The determination module 906 is configured to determine that the pre-shared key has been updated if the identity authentication or the decryption service fails after the identity authentication or the encryption / decryption service is performed with the second server.

[0222] In this embodiment, the receiving module 902 is further configured to receive a security status detection request initiated by the first server before receiving the ciphertext of the pre-shared key sent by the first server;

[0223] The sending module 901 is further used to send the security status data of the above-mentioned device to the first server, so that the first server can determine whether the above-mentioned device is in a safe state.

[0224] In this way, the ciphertext of the pre-shared key sent by the first server includes the ciphertext of the pre-shared key sent by the first server after determining that the above-mentioned device is in a secure state.

[0225] In this embodiment, the ciphertext of the pre-shared key sent by the first server includes: the ciphertext of the updated pre-shared key; wherein the ciphertext of the updated pre-shared key is the plaintext of the updated pre-shared key obtained by the device from the second server, encrypted using the key on the device side and saved in the first server.

[0226] It should be noted that this application Figure 6 to Figure 8 All relevant contents of each step involved in the illustrated method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0227] The device 900 provided in this embodiment is used to execute the present application Figure 6 to Figure 8 The authentication method based on the pre-shared key provided in the illustrated embodiment can therefore achieve the same effect as the above method.

[0228] It should be understood that the device 900 may correspond to Figure 3 The device 100 shown in FIG. The functions of the sending module 901 and the receiving module 902 can be Figure 3 The processor 110 and the mobile communication module 150 in the device 100 shown in the figure, and / or, are implemented by the processor 110 and the wireless communication module 160; the functions of the encryption and decryption module 903, the authentication module 904 and the determination module 906 can be implemented by Figure 3 The processor 110 in the device 100 shown in the figure is implemented; the function of the storage module 905 can be implemented by Figure 3 The device 100 is shown implemented as an internal memory 121 .

[0229] In the case of an integrated unit, the device 900 may include a processing module, a storage module, and a communication module.

[0230] The processing module can be used to control and manage the actions of the device 900, for example, it can be used to support the device 900 to execute the steps executed by the above modules. The storage module can be used to support the device 900 to store program codes and data, etc. The communication module can be used to support the communication between the device 900 and other devices.

[0231] Among them, the processing module can be a processor or a controller, which can implement or execute various exemplary logic boxes, modules and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, and so on. The storage module can be a memory. The communication module can specifically be a device that interacts with other electronic devices such as a radio frequency circuit, a Bluetooth chip and / or a Wi-Fi chip.

[0232] In one embodiment, when the processing module is a processor and the storage module is a memory, the device 900 involved in this embodiment may be a Figure 3 Device of the structure shown.

[0233] The embodiment of the present application also provides a readable storage medium, in which a program is stored, and when the program is run on a device, the device executes the present application. Figure 6 to Figure 8 The method provided by the illustrated embodiment.

[0234] The embodiment of the present application also provides a program product, which includes a program, which, when running on a device, enables the device to execute the present application. Figure 6 to Figure 8 The method provided by the illustrated embodiment.

[0235] In the embodiments of the present application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent the existence of A alone, the existence of A and B at the same time, and the existence of B alone. Among them, A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b and c can be represented by: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

[0236] In several embodiments provided in the present application, any function, if implemented in the form of a software functional unit and sold or used as an independent product, can be stored in a readable storage medium.

[0237] The above is only a specific implementation of the present application. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. The protection scope of the present application should be based on the protection scope of the claims.

Claims

1. An authentication method based on a pre-shared key, characterized in that: include: Sending a key acquisition request to the first server; Receiving a ciphertext of a pre-shared key sent by the first server; wherein the ciphertext of the pre-shared key is obtained by encrypting a plaintext of the pre-shared key using a key on the device side; the plaintext of the pre-shared key is obtained by the device from the second server; Decrypting the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key; Perform identity authentication or encryption / decryption services with the second server according to the plain text of the pre-shared key.

2. The method according to claim 1, characterized in that The performing identity authentication or encryption / decryption service with the second server according to the plain text of the pre-shared key includes: Use the plain text of the pre-shared key, or a key derived from the plain text of the pre-shared key, to perform identity authentication or encryption and decryption services with the second server.

3. The method according to claim 1 or 2, characterized in that The sending of the key acquisition request to the first server includes: Sending an authentication request to the first server; Performing two-way authentication with the first server; After the two-way authentication is passed, a key acquisition request is sent to the first server.

4. The method according to any one of claims 1 to 3, characterized in that After decrypting the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key, the method further includes: The plain text of the pre-shared key is stored in the secure hardware environment of the device; or the plain text of the pre-shared key is encrypted using a key in the secure hardware environment of the device and then stored in the device.

5. The method according to claim 4, characterized in that Also includes: Performing identity authentication or encryption / decryption services with the second server using the plain text of the pre-shared key stored in the secure hardware environment of the device; or, The key in the secure hardware environment of the device is used to decrypt the encrypted pre-shared key stored in the device to obtain the plain text of the pre-shared key, and the plain text of the pre-shared key is used to perform identity authentication or encryption and decryption services with the second server.

6. The method according to claim 5, characterized in that After performing identity authentication or encryption / decryption services with the second server, the method further includes: If the identity authentication fails or the decryption fails, determining that the pre-shared key has been updated; Re-execute the step of sending the key acquisition request to the first server and its subsequent steps.

7. The method according to any one of claims 1 to 6, characterized in that Before receiving the ciphertext of the pre-shared key sent by the first server, the method further includes: receiving a security status detection request initiated by the first server; The security status data of the device is sent to the first server so that the first server can determine whether the device is in a safe state.

8. The method according to claim 7, characterized in that The ciphertext of the pre-shared key sent by the first server includes: the ciphertext of the pre-shared key sent by the first server after determining that the device is in a secure state.

9. The method according to claim 1, characterized in that The ciphertext of the pre-shared key sent by the first server includes: the ciphertext of the updated pre-shared key; wherein, the ciphertext of the updated pre-shared key is the plaintext of the updated pre-shared key obtained by the device from the second server, encrypted using the key on the device side, and then saved in the first server.

10. A device, characterized in that include: one or more processors; Memory; Multiple applications; and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs include instructions, which, when executed by the device, cause the device to perform the method according to any one of claims 1 to 9.

Images