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

Abstract

The embodiment of the application provides a kind of based on pre-shared key authentication method, device and equipment, in the above-mentioned pre-shared key authentication method, device sends key acquisition request to first server, then receives the ciphertext of pre-shared key sent by first server, then the ciphertext of pre-shared key is decrypted, the plaintext of pre-shared key is obtained, and then according to the plaintext of pre-shared key, identity authentication or encryption and decryption service is carried out with second server, so that it can be realized by one first server with security authentication and authentication mechanism to store the ciphertext of pre-shared key encrypted by the key of equipment side, so that the security of pre-shared key is greatly improved, and in the above-mentioned method, key and ciphertext are separated, and first server does not have decryption capability (because first server does not have decryption key), so that the risk of pre-shared key leakage in first server end can be avoided.

Description

Technical Field

[0001] This application relates to the field of smart device technology, and in particular to an authentication method, apparatus, and device based on a pre-shared key. Background Technology

[0002] The Internet of Things (IoT) is an internet that connects things, enabling interconnection between objects and between people and objects. Devices can interact with servers by connecting to the IoT. To ensure security, when a device initiates an access request, the server needs to authenticate the device before allowing it to access the IoT. Both the device and the server pre-store a shared pre-shared key (PSK). Authentication based on the PSK relies on time-varying parameters. During authentication, the PSK is used to perform cryptographic operations on a timestamp, sequence number, or random number and sent to the authenticator. The authenticator uses the same PSK to perform the same operations and uses the rules governing the timestamp, sequence number, and random number to verify that the authenticated party possesses the correct PSK, thus determining the legitimacy of the authenticated party's identity.

[0003] Pre-shared keys in devices cannot resist reverse analysis or dynamic hooking, so the use of pre-shared keys in devices may pose security problems, and the solutions provided by existing related technologies cannot solve the security problems of pre-shared keys in devices. Summary of the Invention

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

[0005] A first aspect provides an authentication method based on a pre-shared key, the method being executed by a device, comprising: sending a key acquisition request to a first server; receiving 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; decrypting the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key; and performing authentication or encryption / decryption services with the second server based on the plaintext of the pre-shared key.

[0006] In the aforementioned authentication method based on a pre-shared key, after the device sends a key acquisition request to the first server, it receives the ciphertext of the pre-shared key from the first server, decrypts the ciphertext to obtain the plaintext of the pre-shared key, and then uses the plaintext of the pre-shared key to perform authentication or encryption / decryption services with the second server. This allows the first server, with its secure authentication and authorization mechanisms, to store the ciphertext of the pre-shared key encrypted using the device's key, significantly improving the security of the pre-shared key and resisting reverse engineering or dynamic hooking. Furthermore, in this method, the key and ciphertext are separated (the key is on the device side, and the ciphertext is on the first server side), and the first server lacks decryption capabilities (because it does not possess the decryption key for the ciphertext of the pre-shared key), thus avoiding the risk of the pre-shared key being leaked on the first server side.

[0007] In one possible implementation, the step of performing authentication or encryption / decryption services with the second server based on the plaintext of the pre-shared key includes: using the plaintext of the pre-shared key, or a key derived from the plaintext of the pre-shared key, to perform 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 sending a key acquisition request to the first server after the two-way authentication is successful.

[0009] In one possible implementation, after decrypting the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key, the method further 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 a key in the secure hardware environment of the device and then storing it in the device.

[0010] In one possible implementation, the method further includes: using the plaintext of the pre-shared key stored in the secure hardware environment of the device to perform authentication or encryption / 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 plaintext of the pre-shared key, and using the plaintext of the pre-shared key to perform authentication or encryption / decryption services with the second server.

[0011] In one possible implementation, after performing authentication or encryption / decryption services with the second server, the method further includes: if authentication fails or 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 subsequent steps.

[0012] In one possible implementation, 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; and 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, 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 obtained by the device from the plaintext of the updated pre-shared key obtained from the second server, encrypted using the key on the device side, and then saved to 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 functionality to implement the device behavior of the first aspect and its possible implementations. The functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described functionality. For example, a sending module, a receiving module, an encryption / decryption module, and an authentication module, etc.

[0016] A third aspect provides an apparatus comprising: one or more processors; a memory; a plurality of application programs; and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs include instructions that, when executed by the apparatus, cause the apparatus to perform the method provided in the first aspect.

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

[0018] The fourth aspect provides a readable storage medium storing a program that, when run on a device, causes the device to perform the method provided in the first aspect.

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

[0020] In one possible design, the program in the fifth aspect can be stored wholly or partially on a storage medium packaged with the processor, or it can be stored wholly or partially on a memory not packaged with the processor. Attached Figure Description

[0021] Figure 1 A flowchart for one-way authentication using timestamps or serial numbers;

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

[0023] Figure 3 This is a schematic diagram of the structure of a device provided in one embodiment of this application;

[0024] Figure 4 A schematic diagram of a system architecture provided for one embodiment of this application;

[0025] Figure 5 An architecture diagram for automatically updating the ciphertext of a pre-shared key, provided in one embodiment of this application;

[0026] Figure 6 A flowchart illustrating an authentication method based on a pre-shared key provided in one embodiment of this application;

[0027] Figure 7 A flowchart illustrating a pre-shared key-based authentication method provided in another embodiment of this application;

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

[0029] Figure 9 A schematic diagram of the structure of a device provided in another embodiment of this application;

[0030] Figure 10 This is a schematic diagram of the device provided in another embodiment of this application. Detailed Implementation

[0031] The terminology used in the implementation section of this application is for the purpose of explaining specific embodiments of this application only, and is not intended to limit this application.

[0032] For identity authentication, existing technologies provide two one-way authentication schemes: "one-way authentication using timestamps or serial numbers" and "one-way authentication using random numbers".

[0033] Figure 1A flowchart for one-way authentication using timestamps or serial numbers. 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 timestamps or serial numbers.

[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 For timestamps, N A For the serial number, [T A |N A The symbol indicates that one of them is selected, and the specific choice depends on the technical capabilities and environment of authentication client A and authentication server B.

[0037] fK(X) is the password verification value calculated on data X using the password verification function f and the key K;

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

[0039] In the formula, "B" represents the identity identifier of the authentication server B, in the Token. AB Whether to include the identity identifier B is optional. Note: In the Token AB The inclusion of the identity identifier B is to prevent attackers from impersonating the authentication server B and reusing the token on the authentication client A. AB The inclusion of identifier B is optional because it can be omitted in environments where such attacks are unlikely.

[0040] Step 2, once the token is received AB Upon receiving the message, authentication server B verifies the timestamp or sequence number and calculates fK. AB ([T A |N A The token is verified by comparing the token with the password verification value in the received message and verifying the correctness of the identity identifier B (if any) and the timestamp or serial number. AB .

[0041] Figure 2 The flowchart for one-way authentication using random numbers is as follows. Figure 2 In the authentication scheme shown, authentication server B initiates the authentication process and authenticates client A. 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 password verification value calculated on data X using the password verification function f and the key K.

[0048] Note: In Token AB The inclusion of the identity identifier B is to prevent so-called reflection attacks, which are characterized by an intruder impersonating the authenticated client A and triggering a random number R. B The "reflection" is sent to authentication server B. (In the Token) AB Whether to include the identifier B is optional. The reason why including the identifier B is optional 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 based on the message. AB (R B ||B||Text2), and combine it with Token AB The password verification value is compared with 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 token is verified by matching the random number contained within it. AB .

[0050] Pre-shared keys in devices cannot resist reverse engineering or dynamic hooking, so using pre-shared key schemes in devices may not be very secure. However, general network devices are located in carrier data centers, inaccessible to users, making dynamic hooking very difficult, thus making pre-shared key-based authentication schemes more suitable. Nevertheless, in some third-party ecosystem applications, such as authentication between third-party software development kits (SDKs) and third-party cloud servers, or authentication between third-party Android application packages (APKs) and third-party cloud servers, pre-shared key authentication technology is still widely used. Therefore, how to securely pre-configure pre-shared keys in devices to resist reverse engineering or dynamic hooking and prevent theft of pre-shared keys is an urgent problem to be solved.

[0051] The most common solution to the above problems is encrypted storage. However, traditional cryptography was invented to ensure the security of information transmission through communication channels. What kind of attacks the people or devices at both ends of the communication are vulnerable to are not within the scope of cryptography's consideration and research. In other words, the implicit assumption in the security model of traditional cryptography is that both communicating parties and their devices are trustworthy. For an attacker, they can only intercept and / or modify the communication content on the communication channel. The two communicating parties are a black box to the attacker; the attacker can only see the input and output information of the black box, but has no knowledge of what happens inside. Cryptography works very well under this black-box model. However, in the scenario of devices, the user of the device can be an attacker. Furthermore, because the device is in the attacker's hands, the attacker can disassemble the device at any time and reverse-engineer the software to crack it. In this scenario, traditional cryptography is powerless.

[0052] Three solutions are provided to address this problem.

[0053] Option 1: Security Hardware Protection

[0054] In simple terms, secure hardware protection uses a difficult-to-disassemble piece of hardware to store the key, preventing (average-skilled) users from obtaining it. Common secure hardware environments can include:

[0055] Trusted execution environment (TEE), for example: TEE is the secure hardware environment in the Android system;

[0056] Software Guard Extensions (SGX) is a security hardware environment on Intel chips.

[0057] Secure enclave processor (SEP) is the secure hardware environment of the iPhone operating system (iOS).

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

[0059] However, proprietary security hardware environment protection is relatively expensive, and some cheaper or lightweight devices do not have the capability of security hardware environment protection. For most third-party applications in the ecosystem, it is not possible to pre-install their pre-shared keys in the security hardware environment of all devices before the devices leave the factory. In addition, in the security hardware protection scheme, the pre-shared keys are not convenient to update dynamically.

[0060] Option 2: White-box cryptography

[0061] White-box cryptography assumes that an attacker has complete control over and full visibility into the entire encryption process, presenting a serious threat. Hackers can observe the dynamic encryption process without restriction, and the details of the internal algorithm are fully visible and can be freely modified. Although the method of white-box cryptography is completely transparent, it combines pre-shared keys to make them difficult to extract. In short, white-box encryption is a technique resistant to white-box attacks. The plaintext of the pre-shared key is protected after white-box encryption; it does not appear directly in memory and therefore cannot be extracted.

[0062] However, while white-box cryptography can defend against key recovery attacks to some extent, it cannot defend against code extraction attacks. Even with code obfuscation, it only increases the workload of decompilation and makes some attacks more difficult, but it does not improve the overall technical difficulty. Furthermore, the pre-shared key after white-box encryption is not convenient to update dynamically.

[0063] Option 3: Root Key Management Scheme 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 distributed 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" the root key and can ensure the security of the root key to a certain extent.

[0065] However, this scheme is vulnerable to reverse engineering and may be exploited by decompilers to extract all key components and ultimately calculate the root key. Even with code obfuscation, it only increases the workload of decompilation and slightly raises the difficulty of attacks, without significantly improving the overall technical complexity. Similarly, the encrypted pre-shared key is not easily updated dynamically.

[0066] To address the above issues, this application provides an authentication method based on a pre-shared key, which can resist reverse analysis or dynamic hooking and improve the security of the pre-shared key.

[0067] The authentication method based on pre-shared keys provided in this application can be applied to devices, including but not limited to smartphones, tablets, wearable devices, smart robots, smart speakers, smart screen in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs). This application does not impose any restrictions on the specific type of device.

[0068] For example, Figure 3 This is a schematic diagram of the structure of a device provided in one embodiment of this application, as shown below. Figure 3 As shown, 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, 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.

[0069] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the device 100. In other embodiments of this application, the device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements.

[0070] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0071] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

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

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

[0074] 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 structural limitation on the device 100. In other embodiments of this application, the device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0075] 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 the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the device 100. While charging the battery 142, the charging management module 140 can also supply power to the device 100 via the power management module 141.

[0076] 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, 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.

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

[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 one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0079] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the device 100. 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 the antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to the 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 the 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.

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

[0081] The wireless communication module 160 can provide solutions for wireless communication applications on device 100, 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), 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.

[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, enabling device 100 to communicate with networks and other devices via wireless communication technology.

[0083] Device 100 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 for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

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

[0085] Device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0086] The ISP 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, converting it into an image visible to the naked eye.

[0087] Camera 193 is used to capture still images or videos. An object passes through the lens, generating an optical image that is projected onto a photosensitive element. The photosensitive element converts the light signal into an electrical signal, which is then passed to the ISP (Image Signal Processor) for conversion into a digital image signal. The ISP outputs the digital image signal to the DSP (Digital Signal Processor) for further processing. The DSP converts the digital image signal into standard image signals in formats such as RGB and YUV.

[0088] A digital signal processor is used to process digital signals. In addition to processing digital image signals, it can also process other digital signals.

[0089] Video codecs are used to compress or decompress digital video. Device 100 may support one or more video codecs. Thus, device 100 can play or record video in various encoded formats.

[0090] 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 can enable applications such as intelligent cognition in devices.

[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 perform data storage functions.

[0092] Internal memory 121 can be used to store executable program code, which includes instructions. 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 a sound playback function), etc. The data storage area may store data created during the use of device 100 (such as audio data), etc. In addition, 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. Processor 110 executes various functional applications and data processing of device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory disposed in the processor.

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

[0094] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, audio module 170 may be located in processor 110, or some functional modules of audio module 170 may be located in processor 110. Speaker 170A, also called a "loudspeaker," is used to convert audio electrical signals into sound signals. Receiver 170B, also called a "handpiece," is used to convert audio electrical signals into sound signals. Microphone 170C, also called a "microphone" or "microphone," is used to convert sound signals into electrical signals. Headphone jack 170D is used to connect wired headphones. Pressure sensor 180A is used to sense pressure signals and can convert pressure signals into electrical signals. Gyroscope sensor 180B can be used to determine the motion posture of device 100. Barometric pressure sensor 180C is used to measure barometric pressure. Magnetic sensor 180D includes a Hall effect sensor. Accelerometer 180E detects the magnitude of acceleration of device 100 in various directions (generally triaxial). Distance sensor 180F measures distance. Proximity sensor 180G may include, for example, a light-emitting diode (LED) and a photodetector, such as a photodiode. Ambient light sensor 180L senses ambient light intensity. Fingerprint sensor 180H collects fingerprints. Temperature sensor 180J detects temperature. Touch sensor 180K, also called a "touch device," can be placed on display screen 194, forming a touchscreen, also called a "touchscreen." Bone conduction sensor 180M acquires vibration signals. Buttons 190 include a power button, volume buttons, etc. Motor 191 generates vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 195 connects a SIM card. In some embodiments, device 100 uses eSIM, i.e., an embedded SIM card.

[0095] The authentication method based on a pre-shared key provided in this application can be applied to scenarios where device 100 authenticates with another device using a pre-shared key. The other device can be a server located in the cloud, or it can be a device other than device 100. Specifically, the authentication method based on a pre-shared key provided in this application can be applied to the pre-setting and updating of the pre-shared key in device 100 when another device authenticates device 100 using a pre-shared key.

[0096] Figure 4 A schematic diagram of the system architecture provided in one embodiment of this application, as shown below. Figure 4 As shown, the above system architecture includes a first server 401, a second server 402, and a device 100.

[0097] In this system, the second server 402 and device 100 perform authentication or encryption / decryption services based on a pre-shared key. To ensure the security of the pre-shared key used by device 100 and the second server 402, this pre-shared key is not directly stored in device 100. Instead, it is encrypted using white-box encryption or a root key management scheme based on a key component and then stored in the first server 401. Here, the first server 401 is a cloud device with a robust and secure authentication mechanism for device 100. This authentication mechanism can be any existing, mature, and secure mechanism, such as Public Key Infrastructure (PKI) certificate authentication, public-private key authentication, account authentication, and / or pre-shared key authentication.

[0098] The second server 402 is a cloud device that needs to authenticate with device 100 via a pre-shared key. It's necessary to consider how to securely pre-install the pre-shared key into device 100. The pre-shared key of the second server 402 is typically stored locally in its memory with encryption. When needed, it is retrieved and decrypted directly from the second server 402.

[0099] Of course, the embodiments of this 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 smartphones, set-top boxes, tablets, wearable devices, smart robots, smart speakers, smart screen in-vehicle devices, laptops, UMPCs, netbooks or PDAs, etc. This embodiment does not limit this, but in the following description of the embodiments of this 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 this application will be described using the following methods: Figure 3 Taking the device with the structure shown as an example, in conjunction with the attached drawings and... Figure 4 The system architecture shown illustrates the pre-shared key-based authentication method provided in this application embodiment.

[0101] The authentication method based on a pre-shared key provided in this application embodiment may include:

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

[0103] Step 01: The second server 402 is pre-configured with a pre-shared key for authentication with the device 100. This pre-shared key is generally stored locally in encrypted form on the second server 402.

[0104] Step 02: The ciphertext of the pre-shared key encrypted by the pre-configured device 100 in the first server 401 using an end-side key (such as white-box encryption or a root key management scheme based on key components).

[0105] It should be noted that steps 01 and 02 can be executed in parallel or sequentially. This embodiment does not limit the execution order of steps 01 and 02.

[0106] Step 1, Initial Authentication Process. Specifically, Step 1 may include:

[0107] Step 11: When device 100 needs to authenticate with the second server 402, device 100 first sends an authentication request to the first server 401, and the first server 401 and device 100 begin 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 and private key authentication mechanism, account authentication mechanism and / or pre-shared key authentication mechanism, etc.

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

[0110] Step 13, optionally, the first server 401 sends a security status detection request to the device 100 to check whether the device 100 is in a secure state, such as: checking whether the device 100 is in the root user state, whether the security level of the device 100 has reached the threshold, whether there is a secure hardware environment, whether antivirus software is installed, whether there are any abnormalities in traffic monitoring, and / or whether a lock screen password has been set, etc.

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

[0112] Step 15: 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 authentication or encryption / decryption services with the second server 402.

[0113] Step 16: If a secure hardware environment exists in device 100, the plaintext of the pre-shared key from step 15 can be stored in the secure hardware environment; or the plaintext of the pre-shared key can be encrypted and stored using a key in the secure hardware environment (e.g., using Android's keystore for encrypted storage) for later use. In subsequent authentication processes, device 100 will preferentially obtain the pre-shared key from its secure hardware environment; if device 100 does not have a secure hardware environment, after using the pre-shared key, device 100 will clear the pre-shared key stored in its internal memory (including both the plaintext and ciphertext of the pre-shared key), and will continue to obtain the pre-shared key from the first server 401 for the next use.

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

[0115] Step 21: If device 100 did not store the pre-shared key in the initial authentication process (e.g., device 100 has no secure hardware environment), the subsequent authentication process between device 100 and the second server 402 is the same as the initial authentication process, and will not be described again here.

[0116] Step 22: If a secure hardware environment exists in device 100 and a pre-shared key has been stored in the initial authentication process, then device 100 will use the locally stored pre-shared key to perform authentication or encryption / decryption services with the second server 402 in subsequent transactions.

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

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

[0119] Step 31: The second server 402 updates the pre-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 its internal memory.

[0120] Step 32: The first server 401 updates the ciphertext of the pre-stored pre-shared key to the ciphertext of the new pre-shared key encrypted using the end-side key of device 100. Specifically, device 100 can use white-box encryption or a root key management scheme based on key components to encrypt the new version of the pre-shared key.

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

[0122] Step 41: If device 100 did not store the pre-shared key in the initial authentication process or in the authentication process that has already been performed, the authentication process after the pre-shared key is updated is the same as the initial authentication process, and will not be described again here.

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

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

[0125] The authentication method based on pre-shared keys provided in this application embodiment can prevent the pre-shared key from being cracked if the device 100 does not have a secure hardware environment, thus improving the security of the pre-shared key. 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-install their 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 and ciphertext are separated (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 decryption capabilities (because the first server 401 does not have a decryption key for the ciphertext of the pre-shared key), thereby avoiding the risk of the pre-shared key being leaked on the first server 401 side.

[0127] The authentication method based on pre-shared keys provided in this application also solves the problem of inconvenient dynamic updating of pre-shared keys in the terminal. Furthermore, even if device 100 is completely controlled by an attacker (e.g., root privileges are obtained), the first server 401 will check whether device 100 is in a secure state. If a security risk is detected, the encrypted pre-shared key will not be sent to device 100, thus avoiding the risk of pre-shared keys being leaked on the terminal side.

[0128] In existing related technologies, devices generally lack a secure hardware environment, or manufacturers cannot pre-install the pre-shared key in the secure hardware environment of all devices before they leave the factory. The pre-shared key is typically pre-installed in the device using methods such as white-box encryption, root key management schemes based on key components, or direct plaintext storage. These methods are vulnerable to reverse engineering or dynamic hooking, making the pre-shared key easily cracked. However, this application's embodiment introduces a first server 401 with a security authentication and authorization mechanism with device 100 to store the ciphertext of the pre-shared key, thereby significantly improving the security of the pre-shared key and solving the aforementioned problems of pre-installation and updating of the pre-shared key.

[0129] Furthermore, in this embodiment of the 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. The key and the ciphertext are separated (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 the pre-shared key being leaked on the first server 401 side.

[0130] The first server 401 checks whether device 100 is in a secure state, such as whether device 100 is in root state, whether the device security level reaches the threshold (whether there is a secure hardware environment), whether antivirus software is installed, whether there are any abnormalities in traffic monitoring, and / or whether a lock screen password is set. If a security risk is detected, the encrypted pre-shared key will not be sent to 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 located in the cloud, the authentication between the first server 401 and device 100 is end-to-end authentication. End-to-end authentication is a common issue that devices frequently encounter. For security reasons, many scenarios involving cloud interaction currently require two-way authentication. That is, device 100 needs to verify the identity of the first server 401 to ensure it is not impersonating, and the first server 401 also needs to verify the identity of device 100 to ensure it is not impersonating. The most common way for the front-end to authenticate the cloud is through Hypertext Transfer Protocol Secure (HTTPS) communication using Secure Sockets Layer (SSL) / Transport Layer Security (TLS) certificates. There are many common methods for cloud-side to authenticate the end-side. Here, we introduce common public-private key authentication schemes, PKI certificate authentication schemes, and pre-shared key authentication schemes.

[0133] I. Public-Private Key Authentication Scheme

[0134] 1. Product manufacturing stage:

[0135] 1) The equipment is pre-loaded with a private key during the production stage;

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

[0137] 2. Identity Verification:

[0138] 1) The device uses the private key on the terminal side to sign the data and sends the signed data to the server.

[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 in order to complete the authentication of the device.

[0140] II. PKI Certificate Authentication Scheme

[0141] Two-way authentication:

[0142] The device trusts the cloud side, and the device has a pre-installed HTTPS certificate from the cloud side, which is authenticated via HTTPS.

[0143] The cloud-side trusted device has a pre-installed vendor certificate authority (CA) root certificate that is certified by PKI.

[0144] Authentication process:

[0145] 1. The manufacturer's CA server issues a unique certificate to each device (each device is different);

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

[0147] 3. Cloud services or third-party servers only need to have the root certificate pre-installed (device certificates for all devices do not need to be pre-installed);

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

[0149] 5. Cloud services or third-party servers use root certificates to verify the legitimacy of the certificate chain uploaded by the device, thereby verifying the device's identity.

[0150] III. Pre-shared key authentication scheme

[0151] Pre-shared key authentication schemes are widely used. Because the pre-shared key serves as the credential for authentication between the two parties, A and B, they should share a public secret authentication key K before commencing 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.

[0152] Authentication based on pre-shared keys relies 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 a timestamp, sequence 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 operations and uses the rules for judging the timestamp, sequence number, and / or random number to prove that the authenticated party possesses the correct pre-shared key, thereby determining the legitimacy of the authenticated party's identity.

[0153] Authentication methods based on pre-shared keys can be categorized into two types based on their encryption methods: symmetric encryption algorithms and cryptographic verification functions. Common symmetric encryption algorithms include Advanced Encryption Standard (AES) 128 and AES 256; common cryptographic verification functions include hash-based message authentication codes (HMAC) and cipher block chaining-message authentication codes (CMAC). The advantage of symmetric encryption algorithms is that, in addition to encrypting time-varying parameters for authentication, they can also encrypt the messages or commands to be executed along with these time-varying parameters, ensuring message confidentiality. However, when symmetric encryption algorithms are difficult to obtain or do not meet the product's computational performance requirements, cryptographic verification functions can be used.

[0154] For authentication methods using pre-shared keys with symmetric encryption and cryptographic verification, two categories and ten models of pre-shared key authentication are described, categorized according to different encryption methods, time-varying parameter selections, whether authentication is one-way or two-way, and / or whether a trusted third party is involved in the authentication process. When designing a pre-shared key-based authentication scheme, existing standard pre-shared key-based authentication protocols can be used directly, or these ten authentication models can be adopted.

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

[0156] The following describes the ciphertext of the pre-shared key preset in the first server 401 in step 02, and the scheme for updating the ciphertext of the pre-shared key in the first server 401 in step 32.

[0157] The pre-shared key is encrypted and stored in the first server 401 using a key from device 100 (such as white-box encryption or a root key management scheme based on key components). Encryption can be performed manually on device 100, and the ciphertext can be manually configured into the first server 401 via maintenance. Alternatively, a key management cloud server can be used to connect the first server 401 and the second server 402 to achieve automatic key configuration and updates. The basic concepts of white-box encryption technology and root key management schemes based on key components are introduced below:

[0158] White-box encryption technology (also known as white-box cryptography) assumes that the attacker has complete control over and full visibility into the entire encryption process. The attacker can observe the dynamic password generation process without restriction, and the details and procedures of the internal algorithm are fully visible and can be modified at will. Although the method of white-box cryptography is completely transparent, it tightly binds the algorithm and key together. An encryption table and a decryption table are generated from the algorithm and key, and encryption can be performed independently using the lookup table, and decryption can be performed using the decryption table, no longer relying on the original encryption and decryption algorithms and keys. One implementation approach for white-box encryption is to completely replace the algorithm with a lookup table. Because the algorithm and encryption key are known, the algorithm and key are solidified into a lookup table representation; this is the implementation process of white-box key generation. In short, white-box encryption is an encryption technology that can resist white-box attacks. The plaintext key does not appear directly in memory and therefore cannot be extracted.

[0159] White-box cryptography inherently possesses two security requirements: one is that it is extremely difficult for an attacker to recover the key from the pre-computation table; the other is that an attacker, upon obtaining the white-box encryption (decryption) function, cannot invert it to compute the decryption (encryption). In other words, white-box encryption and decryption algorithms are very difficult to invert. If an attacker can recover the key, then they can definitely invert it. Therefore, if an inversion attack can be prevented, a key recovery attack can definitely be prevented; however, conversely, if a key recovery attack can be prevented, an inversion attack may not be prevented. Therefore, the property of being able to prevent key recovery attacks is called weak white-box security, and the property of being able to prevent 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 distributed manner in the system. The root key is dynamically generated by the key components only when needed. This method effectively solves the problem of "hard-coding" the root key and ensures the security of the root key to a certain extent.

[0161] In a 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 dispersedly throughout the system; they can be stored in files or partially hard-coded into the code. When generating the root key, all key components are input into the key generation module, and the root key is obtained after calculation using a key derivation algorithm. Once generated, the root key is stored only in memory. All cryptographic operations using the root key are performed in the root key cryptographic operation module. Business logic modules cannot directly access the root key data; they can only input the plaintext (or ciphertext) of the key to be protected into the root key cryptographic module, which then uses the root key to perform operations and outputs the ciphertext (or plaintext) of the key.

[0162] The ciphertext pre-setting or update scheme for pre-shared keys can be implemented using either manual or automated methods.

[0163] I. Manual maintenance, which means that the ciphertext of the pre-shared key in the first server 401 is preset or updated manually, specifically including:

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

[0165] Step 2: Using a device 100, the plaintext of the pre-shared key is encrypted with the key on the device 100 to obtain the ciphertext. The encryption method can be a commonly used symmetric encryption method, such as the AES-Galoiscounter mode (GCM) encryption algorithm.

[0166] Step 3: Export the encrypted ciphertext and then manually install or update it on the first server 401. The storage method on the first server 401 can be various, such as configuration files and / or databases. This embodiment does not limit the method.

[0167] II. Automatic preset or update, specifically, Figure 5 This is an architecture diagram of automatically updating the ciphertext of the pre-shared key provided in one embodiment of this application. The following is in conjunction with... Figure 5 A scheme for automatically updating the ciphertext of the pre-shared key is introduced.

[0168] Step 1: The second server 402 sends the plaintext of the pre-shared key that needs to be preset or updated to the key management server 501 of the device 100 manufacturer via an encrypted channel (e.g., Transport Layer Security (TLS) protocol or HTTPS protocol) on a wired or wireless network. The key management server 501 can be located in the cloud.

[0169] Step 2: The key management server 501 is pre-configured with the same key as the key on the device 100, and the same encryption algorithm (such as white-box encryption or root key management scheme based on key components). The key management server 501 encrypts the plaintext 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 through a wired or wireless network encrypted channel (e.g., TLS or HTTPS protocol).

[0171] Step 4: The first server 401 presets or updates the ciphertext of the pre-shared key obtained from the key management server 501 onto the first server 401 to make it effective. The ciphertext of the pre-shared key can be stored on the first server 401 in various ways, such as through configuration files and / or databases, and is not limited here.

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

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

[0174] Step 7: If the second server 402 receives a notification that the pre-shared key has been pre-configured or successfully updated, the second server 402 will use the new pre-shared key for subsequent authentication processes.

[0175] As described above, this 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 on 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 in one embodiment of this application is shown below. Figure 6 As shown, the above authentication method based on pre-shared keys may include:

[0177] Step 601: Device 100 sends a key acquisition request to the first server 401. This key acquisition request is used to obtain a pre-shared key for authentication or encryption / decryption services with the second server 402.

[0178] Specifically, the process of device 100 sending a key acquisition request to the first server 401 may include: device 100 sending an authentication request to the first server 401 to perform two-way authentication with the first server 401; and after the two-way authentication is successful, device 100 sending a key acquisition request to the first server 401.

[0179] Step 602, 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 plaintext of the pre-shared key obtained by device 100 from the second server 402 may include: the pre-shared key being obtained by device 100 from the second server; or the pre-shared key being generated through negotiation between device 100 and the second server 402.

[0182] In this embodiment, the ciphertext of the pre-shared key sent by the first server 401 can be the ciphertext of the updated pre-shared key. The updated ciphertext is obtained by device 100 from the plaintext of the updated pre-shared key obtained from the second server 402, encrypted using the key on device 100's side, and then stored in the first server 401. As mentioned earlier, the update of the pre-shared key can be performed manually or automatically, which will not be elaborated further here.

[0183] Step 603: Device 100 decrypts the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key.

[0184] Step 604: Device 100 performs authentication or encryption / decryption services with the second server 402 based on the plaintext of the pre-shared key.

[0185] Specifically, based on the plaintext of the aforementioned pre-shared key, the authentication or encryption / decryption service with the second server can be performed by using the plaintext of the aforementioned pre-shared key or a key derived from the plaintext of the aforementioned pre-shared key to perform authentication or encryption / decryption service with the second server 402.

[0186] In the aforementioned authentication method based on a pre-shared key, after 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, decrypts the ciphertext to obtain the plaintext of the pre-shared key, and then performs authentication or encryption / decryption services with the second server 402 based on the plaintext of the pre-shared key. This allows the first server 401, with its secure authentication and authorization mechanisms, to store the ciphertext of the pre-shared key encrypted using the key on the device 100 side, significantly improving the security of the pre-shared key and resisting reverse engineering or dynamic hooking. Furthermore, in this method, the key and ciphertext are separated (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 decryption capabilities (because the first server 401 does not have the decryption key for the ciphertext of the pre-shared key), thus avoiding the risk of the pre-shared key being leaked on the first server 401 side.

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

[0188] Step 701: Device 100 stores the plaintext of the pre-shared key in the secure hardware environment of device 100; or it encrypts the plaintext of the pre-shared key using a key in the secure hardware environment of device 100 and then stores it in device 100.

[0189] Step 702: Device 100 uses the plaintext of the pre-shared key stored in the secure hardware environment of Device 100 to perform authentication or encryption / decryption services with the second server 402; or, it uses the key in the secure hardware environment of Device 100 to decrypt the pre-shared key stored in encrypted form in Device 100 to obtain the plaintext of the pre-shared key, and uses the plaintext of the pre-shared key to perform authentication or encryption / decryption services with the second server 402.

[0190] In other words, if a secure hardware environment exists in device 100 and a pre-shared key has been stored in the initial authentication process or the authentication process that has already been performed, then device 100 will prioritize using the locally stored pre-shared key to perform identity authentication or encryption / decryption services with the second server 402.

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

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

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

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

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

[0196] Thus, in step 602, the ciphertext of the pre-shared key sent by the first server 401 can 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, device 100 receives a security status detection request initiated by first server 401. The security status detection request is used to check whether device 100 is in a secure state, such as whether device 100 is in root state, whether the device security level reaches the threshold (whether a secure hardware environment exists), whether antivirus software is installed, whether traffic monitoring is abnormal, and / or whether a lock screen password is set, etc. Then, device 100 sends the security status data of device 100 to first server 401. After first server 401 determines that device 100 is in a secure state based on the security status data, first server 401 sends the encrypted pre-shared key to device 100. If first server 401 detects a security risk, it will not send the encrypted pre-shared key to device 100, thereby avoiding the risk of the pre-shared key being leaked on the device 100 side.

[0198] It is understood that some or all of the steps or operations in the above embodiments are merely examples, and other operations or variations thereof can be performed in the embodiments of this application. Furthermore, the steps may be performed in different orders as presented in the above embodiments, and it is not necessary to perform all the operations in the above embodiments.

[0199] It is understood that, in order to achieve the above-mentioned functions, the device includes hardware and / or software modules corresponding to the execution of each function. Based on the algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by 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 conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

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

[0201] Figure 9This is a schematic diagram of the structure of a device provided in another embodiment of this application, in which functional modules are divided according to their respective functions. Figure 9 A schematic diagram of a possible composition of the device 900 involved in the above embodiments is shown, such as... Figure 9 As shown, the device 900 may include: a sending module 901, a receiving module 902, an encryption / 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 / decryption module 903 is used to decrypt the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key.

[0205] The authentication module 904 is used to authenticate with the second server based on the plaintext of the aforementioned pre-shared key;

[0206] The encryption / decryption module 903 is also used to perform encryption / decryption services with the second server based on the plaintext of the aforementioned pre-shared key.

[0207] In this embodiment, the authentication module 904 is specifically used to authenticate with the second server using the plaintext of the pre-shared key or a key derived from the plaintext of the pre-shared key.

[0208] The encryption / decryption module 903 is specifically used to perform encryption / decryption services with the second server using the plaintext of the aforementioned pre-shared key, or a key derived from the plaintext of the aforementioned pre-shared key.

[0209] It should be noted that this application Figure 6 All relevant content of each step involved in the method embodiment shown can be referenced from 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 this application. Figure 6 The authentication method based on pre-shared keys provided in the illustrated embodiment can achieve the same effect as the method described above.

[0211] Figure 10 This is a schematic diagram of the structure of a device provided in another embodiment of this application, and... Figure 9 Compared to the equipment shown, Figure 10In the device 900 shown, the sending module 901 is also used to send an authentication request to the first server;

[0212] Authentication module 904 is also used for two-way authentication with the first server;

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

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

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

[0216] Thus, the authentication module 904 is specifically used to authenticate with the second server using the plaintext of the pre-shared key stored in the secure hardware environment of the aforementioned device; or, the encryption / decryption module 903 is specifically used to perform encryption / decryption services with the second server using the plaintext of the pre-shared key stored in the secure hardware environment of the aforementioned device.

[0217] or,

[0218] The encryption / decryption module 903 is also used to decrypt the pre-shared key encrypted and stored in the device using the key in the secure hardware environment of the aforementioned device, so as to obtain the plaintext of the pre-shared key.

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

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

[0221] The determination module 906 is used to determine that the pre-shared key has been updated if authentication or decryption fails after authentication or decryption services are performed with the second server.

[0222] In this embodiment, the receiving module 902 is further configured to receive the 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 also 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 secure state.

[0224] Thus, 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 aforementioned 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 obtained by the device from the plaintext of the updated pre-shared key obtained from the second server, encrypted using the key on the device side, and then saved to the first server.

[0226] It should be noted that this application Figures 6-8 All relevant content of each step involved in the method embodiment shown can be referenced from 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 this application. Figures 6-8 The authentication method based on pre-shared keys provided in the illustrated embodiment can achieve the same effect as the method described above.

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

[0229] When using integrated units, 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 device 900, for example, it can support device 900 in executing the steps performed by the aforementioned modules. The storage module can be used to support device 900 in storing program code and data. The communication module can be used to support communication between device 900 and other devices.

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

[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 can be a device having... Figure 3 The device with the structure shown.

[0233] This application also provides a readable storage medium storing a program that, when run on a device, causes the device to execute this application. Figures 6-8 The method provided in the illustrated embodiment.

[0234] This application also provides a program product, which includes a program that, when run on a device, causes the device to execute this application. Figures 6-8 The method provided in the illustrated embodiment.

[0235] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, A and B simultaneously, or B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related 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 singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

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

[0237] The above description is merely a specific embodiment of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application. The protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A pre-shared key based authentication method, characterized by, Comprising: sending a key obtaining 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 a plaintext of the pre-shared key using a key on a device side; the plaintext of the pre-shared key is obtained by the device from a second server; decrypting the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key; performing identity authentication or encryption and decryption service with the second server according to the plaintext of the pre-shared key.

2. The method of claim 1, wherein, The performing identity authentication or encryption and decryption service with the second server according to the plaintext of the pre-shared key comprises: performing identity authentication or encryption and decryption service with the second server using the plaintext of the pre-shared key or a key derived from the plaintext of the pre-shared key.

3. The method according to claim 1 or 2, characterized in that, The sending a key obtaining request to a first server comprises: sending an authentication request to the first server; performing mutual authentication with the first server; sending a key obtaining request to the first server after the mutual authentication is passed.

4. The method according to any one of claims 1 to 3, characterized in that, The decrypting the ciphertext of the pre-shared key to obtain the plaintext of the pre-shared key further comprises: storing the plaintext of the pre-shared key to a secure hardware environment of the device; or encrypting the plaintext of the pre-shared key using a key in the secure hardware environment of the device and then storing to the device.

5. The method of claim 4, wherein, Further comprising: performing identity authentication or encryption and decryption service with the second server using the plaintext of the pre-shared key stored in the secure hardware environment of the device; Or, decrypting the encrypted pre-shared key stored in the device using a key in the secure hardware environment of the device to obtain the plaintext of the pre-shared key, and performing identity authentication or encryption and decryption service with the second server using the plaintext of the pre-shared key.

6. The method of claim 5, wherein, The performing identity authentication or encryption and decryption service with the second server further comprises: if the identity authentication is failed or the decryption is failed, determining that the pre-shared key is updated; re-executing the sending a key obtaining request to a first server and subsequent steps.

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

8. The method of claim 7, wherein, The ciphertext of the pre-shared key sent by the first server comprises: 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 of claim 1, wherein, The ciphertext of the pre-shared key sent by the first server comprises: a ciphertext of an updated pre-shared key; wherein the ciphertext of the updated pre-shared key is obtained by the device from the second server to obtain a plaintext of an updated pre-shared key, and is encrypted using a key on the device side and then saved to the first server.

10. An apparatus, comprising: Comprising: one or more processors; a memory; a plurality of application programs; and one or more programs, wherein the one or more programs are stored in the memory that, when executed by the device, cause the device to perform the methods of any of claims 1-9.

Images