Data processing method

Abstract

This application discloses a data processing method belonging to the field of cryptography. The method is applied to a first end, which is communicatively connected to a second end. The method includes: receiving a second-end session random number returned by the second end; generating a first-end session random number and sending the first-end session random number to the second end; the second-end session random number is generated by the second end in response to a session authentication request for a target session sent by the first end; performing cryptographic operations on the interaction entropy, time counter, and shared seed key determined based on the first-end and second-end session random numbers to generate a first one-time password for the target session; the shared seed key corresponds to a first entity identifier; sending the first one-time password to the second end and receiving the authentication result returned by the second end. This data processing method enhances the security of identity authentication and service authorization between the two devices.

Description

Technical Field

[0001] This application belongs to the field of cryptography technology, and in particular relates to a data processing method. Background Technology

[0002] In related technologies, dynamic ciphers are typically generated by combining a seed key with time parameters (such as timestamps or count values). This generation mechanism is highly deterministic: within the same valid time window or count value period, the dynamic cipher output based on the same seed key remains unchanged. Due to this determinism, related technologies can only generate a single valid cipher within the same time window, making it difficult to distinguish concurrent communication sessions and susceptible to malicious reuse, posing a high risk of replay attacks. Summary of the Invention

[0003] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a data processing method that enhances the security of identity authentication and business authorization between two-end devices.

[0004] In a first aspect, this application provides a data processing method applied to a first end, wherein the first end is communicatively connected to a second end, the method comprising: The system receives a second-end session random number returned by the second end, generates a first-end session random number, and sends the first-end session random number to the second end. The second-end session random number is generated by the second end in response to a session authentication request for the target session sent by the first end. The session authentication request contains a first entity identifier corresponding to the first end. Cryptographic operations are performed on the interaction entropy, time counter, and shared seed key determined based on the first end session random number and the second end session random number to generate the first one-time password for the target session; the shared seed key corresponds to the first entity identifier; The first one-time password is sent to the second end, and the authentication result returned by the second end is received; the first one-time password is used by the second end to verify the legitimacy of the target session.

[0005] According to the data processing method of this application, in a single authentication process corresponding to the target session, the session-level interaction entropy is determined by the session random numbers generated by the interaction between the first and second ends. This interaction entropy, along with a time counter and a shared seed key, is then used in cryptographic operations to generate a one-time password. This mechanism enables different sessions to generate different passwords even within the same time counter period, improving the unpredictability of password generation for a single session. This effectively reduces the risk of malicious password replay and enhances the security of identity authentication and business authorization between the two devices.

[0006] According to one embodiment of this application, the step of performing cryptographic operations on the interaction entropy, time counter, and shared seed key determined based on the first end session random number and the second end session random number to generate the first one-time password for the target session includes: Based on the random number of the second-end session and the random number of the first-end session, a parameter fusion operation is performed to obtain the interaction entropy corresponding to the target session; Cryptographic operations are performed based on a time counter determined by the target time parameter, a shared seed key, and the interaction entropy to generate a first one-time password corresponding to the target session.

[0007] According to one embodiment of this application, the step of performing cryptographic operations based on a time counter determined by a target time parameter, a shared seed key, and the interaction entropy to generate a first one-time cipher corresponding to the target session includes: The shared seed key, the time counter, and the interaction entropy are concatenated to obtain the first target input data; Using the shared seed key as the key, the first target input data is authenticated and calculated based on the cryptographic message authentication code algorithm to obtain the first password string; The first password string is dynamically truncated to generate the first one-time password.

[0008] According to one embodiment of this application, after receiving the second-end session random number returned by the second end, the method includes: The validity of the random number generated by the second-end session is verified. If the random number of the second-end session meets the preset legality conditions, the random number of the first-end session is generated. If the random number generated by the second session does not meet the preset validity conditions, the authentication process of the target session is terminated.

[0009] According to one embodiment of this application, before receiving the second-end session random number returned by the second end, the method further includes: Obtain the pairing request information output by the second end; the pairing request information includes a second entity identifier corresponding to the second end, a pairing request identifier, and a random challenge code; Generate a first entity identifier and a first paired random number corresponding to the first end; Based on the first pairing random number and the random challenge code, pairing verification data is generated, and the first pairing random number, the first entity identifier, and the pairing verification data are sent to the second end; The system receives the second paired random number returned by the second end, and performs cryptographic operations based on the first paired random number and the second paired random number to generate the shared seed key.

[0010] In a first aspect, this application provides a data processing method applied to a second end, the second end being communicatively connected to the first end, the method comprising: Receive the session authentication request corresponding to the target session sent by the first end, and extract the corresponding shared seed key if the first entity identifier in the session authentication request is valid; Send the generated second-end session random number to the first end, receive the first-end session random number returned by the first end, and perform parameter fusion calculation based on the first-end session random number and the second-end session random number to obtain the interaction entropy corresponding to the target session; Receive the first one-time password sent by the first end, and generate a second one-time password based on the interaction entropy, the time counter, and the shared seed key; The first one-time password and the second one-time password are checked for consistency. Based on the check result, the authentication result for the target session is obtained and the authentication result is sent to the first end.

[0011] According to one embodiment of this application, generating a second one-time password based on the interaction entropy, the time counter, and the shared seed key includes: The shared seed key, the time counter, and the interaction entropy are concatenated to obtain the second target input data; Using the shared seed key as the key, the second target input data is authenticated and calculated based on the cryptographic message authentication code algorithm to obtain the second password string; The second password string is dynamically truncated to generate the second one-time password.

[0012] According to one embodiment of this application, the step of performing a consistency check on the first one-time password and the second one-time password, and obtaining an authentication result for the target session based on the check result, includes: If the first one-time password and the second one-time password are the same, the authentication result for the target session is successful. If the first one-time password and the second one-time password are inconsistent, the time counter is updated, and the second one-time password is regenerated based on the updated time counter. The consistency of the first one-time password and the regenerated second one-time password is verified to obtain the authentication result for the target session.

[0013] According to one embodiment of this application, receiving a session authentication request for a target session sent by the first end, and extracting the corresponding shared seed key if the first entity identifier in the session authentication request is determined to be valid, includes: If the first entity identifier matches a preset pairing record, the first entity identifier is determined to be valid, and the shared seed key corresponding to the first entity identifier is extracted. If the first entity identifier does not match the preset pairing record, an error message is returned to the first end, and the target session is terminated.

[0014] According to one embodiment of this application, before receiving the session authentication request for the target session sent by the first end, the method further includes: Generate a second entity identifier corresponding to the second end, and output pairing request information; the pairing request information includes the second entity identifier, pairing request identifier, and random challenge code; Receive the first entity identifier, the first pairing random number, and the pairing verification data returned by the first end based on the pairing request information; If the pairing verification data passes the verification, a second pairing random number is generated; The shared seed key is obtained by calculating based on the first and second paired random numbers, and the second paired random number is sent to the first end.

[0015] Thirdly, this application provides a data processing apparatus for a first end, wherein the first end is communicatively connected to a second end, the apparatus comprising: The first processing module is configured to receive a second-end session random number returned by the second end, generate a first-end session random number, and send the first-end session random number to the second end; the second-end session random number is generated by the second end in response to a session authentication request for a target session sent by the first end, and the session authentication request contains a first entity identifier corresponding to the first end; The second processing module is used to perform cryptographic operations on the interaction entropy, time counter, and shared seed key determined based on the first end session random number and the second end session random number to generate a first one-time password for the target session; the shared seed key corresponds to the first entity identifier; The third processing module is used to send the first one-time password to the second end and receive the authentication result returned by the second end; the first one-time password is used by the second end to verify the legitimacy of the target session.

[0016] According to the data processing apparatus of this application, during a single authentication process corresponding to a target session, the session-level interaction entropy is determined by the session random numbers generated by the interaction between the first and second ends. This interaction entropy, along with a time counter and a shared seed key, is then used in cryptographic operations to generate a one-time password. This mechanism enables different sessions to generate different passwords even within the same time counter period, improving the unpredictability of password generation for a single session. This effectively reduces the risk of malicious password replay and enhances the security of identity authentication and business authorization between the two devices.

[0017] Fourthly, this application provides a data processing apparatus applied to a second end, the second end being communicatively connected to the first end, the apparatus comprising: The fourth processing module is used to receive the session authentication request corresponding to the target session sent by the first end, and extract the corresponding shared seed key if it is determined that the first entity identifier in the session authentication request is valid. The fifth processing module is used to send the generated second-end session random number to the first end, and receive the first-end session random number returned by the first end, and perform parameter fusion calculation based on the first-end session random number and the second-end session random number to obtain the interaction entropy corresponding to the target session; The sixth processing module is used to receive the first one-time password sent by the first end, and generate a second one-time password based on the interaction entropy, the time counter and the shared seed key; The seventh processing module is used to perform consistency verification between the first one-time password and the second one-time password, obtain the authentication result for the target session based on the verification result, and send the authentication result to the first end.

[0018] Fifthly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the data processing method as described in the first and second aspects above.

[0019] In a sixth aspect, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data processing methods described in the first and second aspects above.

[0020] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the data processing methods described in the first and second aspects above.

[0021] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects: In a single authentication process corresponding to the target session, the session-level interaction entropy is determined by the session random numbers generated by the interaction between the first and second ends. This interaction entropy, along with a time counter and a shared seed key, is then used in cryptographic operations to generate a one-time password. This mechanism allows different sessions to generate different passwords even within the same time counter period, increasing the unpredictability of password generation for a single session. This effectively reduces the risk of malicious password replay and enhances the security of identity authentication and business authorization between the two devices.

[0022] Furthermore, by utilizing the random entropy source generated by the interaction between the two devices, the characteristic data belonging to a single session is calculated as the interaction entropy. This interaction entropy is then used to generate a one-time password, ensuring that the password generation result is jointly determined by the time parameter and the state of the single session, thus eliminating the sole dependence of the authentication password on the time synchronization mechanism. When the system is within the same time counting step, it can output differentiated authentication passwords based on the uniqueness of the interaction entropy in a single session, thereby ensuring that passwords generated by different sessions within the same time window are different. Since intercepted passwords cannot be verified in other sessions, the risk of replay attacks within the same time window is reduced, enhancing the overall security of identity authentication and business authorization between the two devices.

[0023] Furthermore, by concatenating the interaction entropy, time counter, and shared seed key generated from real-time interaction between the two devices as input data, a one-time password is generated through cryptographic operations and dynamic truncation. This generation mechanism utilizes a random entropy source, ensuring that the password generated for each session authentication is globally unique. Even within the same time counter period, the password is only valid for the current session, effectively reducing the risk of password replay or derivation and enhancing the security of identity authentication and business authorization between the two devices.

[0024] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0025] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is one of the flowcharts illustrating the data processing method provided in the embodiments of this application; Figure 2 This is a second schematic flowchart of the data processing method provided in the embodiments of this application; Figure 3 This is one of the structural schematic diagrams of the data processing apparatus provided in the embodiments of this application; Figure 4This is a second schematic diagram of the structure of the data processing device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0027] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0028] The data processing method, apparatus, electronic device, and readable storage medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0029] The data processing method can be applied to the terminal, and can be executed by the hardware or software in the terminal.

[0030] The terminal includes, but is not limited to, portable communication devices such as mobile phones or tablets. It should also be understood that, in some embodiments, the terminal may not be a portable communication device, but rather a desktop computer.

[0031] It should be understood that a terminal may include one or more other physical user interface devices such as a physical keyboard, mouse, and joystick.

[0032] The data processing method provided in this application embodiment can be executed by an electronic device or a functional module or entity in an electronic device that can implement the data processing method. The electronic devices mentioned in this application embodiment include, but are not limited to, mobile phones, tablet computers and computers. The data processing method provided in this application embodiment is described below using an electronic device as the execution subject.

[0033] During the research and development process, the inventors discovered that mainstream dynamic password technologies mainly include Time-Based One-Time Password (TOTP) and HMAC-based One-Time Password (HOTP). These technologies typically rely on combining a static seed key with dynamic time parameters (such as timestamps or counter values) to generate a password for authentication. Because the same seed key generates a consistent dynamic password under the same time parameters or counter period, these technologies can only output a single valid credential within the same valid time window, making it difficult to distinguish between concurrent authentication requests. Since the dynamic passwords generated by these technologies only possess time-dimensional uniqueness and lack a binding mechanism with a single specific communication session, they are vulnerable to network eavesdropping. If the password is illegally intercepted during network transmission, attackers can maliciously reuse it within the current valid time window. In this case, the verification end can usually only passively verify the time validity of the password, making it difficult to effectively identify and intercept such password theft and replay attacks. Furthermore, the security of these technologies is highly dependent on the confidentiality of the underlying seed key. In the absence of other dynamic security factors involved in cross-validation, once the seed key is leaked, attackers can deduce the generation pattern of dynamic passwords, causing historical verification data associated with that key and future generated passwords to be at risk of becoming invalid.

[0034] To address the problem in related technologies where dynamic passwords remain fixed within the same time window, making it difficult to distinguish concurrent requests and vulnerable to replay attacks, the inventors, after in-depth research, designed a data processing method applied to a first end, which communicates with a second end. The method includes: receiving a second-end session random number returned by the second end, and generating a first-end session random number; the second-end session random number is generated by the second end in response to a session authentication request for the target session sent by the first end, the session authentication request containing a first entity identifier corresponding to the first end, and sending the first-end session random number to the second end; performing cryptographic operations on the interaction entropy, time counter, and shared seed key determined based on the first-end and second-end session random numbers to generate a first one-time password for the target session; the shared seed key is the key corresponding to the first entity identifier; sending the first one-time password to the second end and receiving the authentication result returned by the second end; the first one-time password is used by the second end to verify the legitimacy of the target session.

[0035] According to the data processing method provided in the embodiments of this application, during a single authentication process corresponding to the target session, the session-level interaction entropy is determined by the session random numbers generated by the interaction between the first and second ends. This interaction entropy, along with a time counter and a shared seed key, is then used in cryptographic operations to generate a one-time password. This mechanism enables different sessions to generate different passwords even within the same time counter period, improving the unpredictability of password generation for a single session. This effectively reduces the risk of malicious password replay and enhances the security of identity authentication and business authorization between the two devices.

[0036] In some embodiments, the first end is the authentication requester (i.e., the device that initiates the authentication request), which is typically a mobile terminal device held by the user, including but not limited to smartphones, tablets, smartwatches or other embedded mobile devices.

[0037] The second end is the authentication and verification party (i.e., the device or service that verifies the validity of the password), which is usually the target device / business system that requires login authentication or access control, including but not limited to personal computers, routers, access control devices, servers, safes, and combination locks.

[0038] In a typical wide area network architecture, the first end can run as a client, and the second end can run as a server.

[0039] It should be noted that, when offline authentication is supported and no third-party cloud server is required, the first and second ends can be two entities communicating locally. In this case, the first and second ends can establish a point-to-point direct communication channel through near field communication (NFC), Bluetooth, infrared, or local area network, and the second end can directly verify the legitimacy of the first end locally.

[0040] In addition, the first and second ends can be pre-paired securely and share a long-term seed key; the relevant implementation details will be explained in detail later.

[0041] It should be noted that although the embodiments in this application are illustrated using the interaction between a first end and a second end as an example, in practical application scenarios, the data processing method provided in this application can also be extended to authentication interactions between three or more device nodes (e.g., a multi-level architecture including clients, edge gateways, and cloud servers). In this scenario, the interaction of session random numbers, the generation of one-time passwords, or the verification of legitimacy can be securely routed or distributed collaboratively processed through network intermediate nodes to achieve communication authentication and service authorization between multiple nodes. This application does not impose specific limitations on this.

[0042] In some embodiments, the data processing method of this application can be referred to as the IOTP algorithm, namely, a one-time password algorithm based on dual-device interaction entropy. The key parameters and related attributes involved in the data processing method of this application are described in Table 1.

[0043]

[0044] In some embodiments, the random numbers used in this application (such as session random numbers and pairing random numbers mentioned below) can be pseudo-random numbers or true random numbers.

[0045] In this embodiment, true random numbers can be generated by a True Random Number Generator (TRNG) at the device hardware level, including but not limited to ARM TrustZone TRNG, Intel RDRAND, or Apple Secure Enclave TRNG.

[0046] Pseudo-random numbers are typically generated based on a preset mathematical algorithm (such as linear congruential algorithms, hash algorithms, etc.) and an initial seed. The generation process depends on software computation logic. Using pseudo-random numbers can reduce the system's dependence on specific security hardware, effectively reduce the manufacturing cost and computational overhead of terminal devices, and is suitable for application scenarios with high computational efficiency requirements or limited hardware resources.

[0047] In applications with high security requirements, true random numbers are preferred. Compared to software-level pseudo-random number generators, true random numbers generated based on hardware physical properties have higher unpredictability and can significantly improve the security of password generation.

[0048] For ease of understanding, the embodiments described below will use true random numbers as an example.

[0049] In this application, the interaction entropy (such as parameter E in the system parameter table) refers to characteristic data or derived parameters used to characterize the randomness of two-way interaction in the current session.

[0050] In some embodiments, the interaction entropy can be determined by the first and second ends participating in the communication, based on the session true random numbers (such as parameters R1 and R2) generated by each of them in the current session.

[0051] Since the lifecycle of the interaction entropy and the session true random number it depends on is limited to the current session, and the relevant data resides in the device's memory for a short time, the risk of dynamic parameters being exposed for a long time is reduced, thus enhancing the security of the authentication process.

[0052] In the one-time password generation logic, interaction entropy, as a dynamic perturbation parameter specific to a single session, participates in the calculation together with the long-term shared seed key and time counter. Introducing interaction entropy as a session-level dynamic parameter allows different sessions to generate different authentication passwords based on their respective interaction states within the same time counting period, thereby improving the system's ability to resist memory read attacks and cross-session replay attacks.

[0053] The specific calculation model for interaction entropy and other system parameter details will be explained in detail later with reference to specific implementation examples.

[0054] The underlying algorithm settings of this application embodiment will be further explained and described below with reference to the parameter configurations in Table 1.

[0055] For the truly random number R1 generated at the first end and the truly random number R2 generated at the second end in Table 1, the generation mechanism preferably relies on a device hardware-level true random number generator (TRNG, such as ARM TrustZone TRNG, Intel RDRAND, or Apple Secure Enclave TRNG). It is understood that this application does not strictly limit the specific method of random number generation, and in other embodiments, modules such as a secure pseudo-random number generator (CSPRNG) that meets cryptographic security strengths can also be used.

[0056] When generating the interaction entropy E in Table 1, the message authentication code algorithm used by the first and second ends can be HMAC-SHA256 (compliant with RFC 2104), which relies on the SHA-256 hash algorithm (compliant with NIST FIPS 180-4) with strong collision resistance. The above algorithm is only an example for illustration. In practical applications, HMAC-SHA512, message authentication codes based on the national cryptographic algorithm SM3, and other cryptographic algorithms with equal or higher security strength can also be used according to security requirements.

[0057] For the time step X used for time calculation in Table 1, its default value is 30 seconds to be compatible with the existing Time-Based One-Time Password (TOTP) specification; at the same time, this step parameter can be flexibly adjusted to 15 seconds, 60 seconds or other custom durations according to specific network latency or system configuration requirements.

[0058] The one-time password P generated based on the above core parameters has a default length of 6 digits. In specific implementation scenarios, those skilled in the art can extend it to 8 digits, a mixture of alphanumeric characters, or other lengths and character formats depending on the security level requirements.

[0059] Furthermore, to ensure data consistency between the first and second ends during interaction, the data format specifications for the aforementioned parameters are further explained: In the embodiments of this application, all binary data involved are preferably arranged in big-endian format during storage and network transmission; it is understood that little-endian format can also be used under certain underlying hardware architectures.

[0060] For the device unique identifiers (IDc and IDs) in Table 1, they can adopt the standard UUIDv4 format, or they can adopt the device's physical hardware address (MAC address), International Mobile Equipment Identity (IMEI) or a custom globally unique identifier (GUID) format, depending on the specific terminal type.

[0061] The timestamp (T) used for time counter calculations is preferably in a Unix timestamp format accurate to the second; in other feasible embodiments, this time parameter can also be flexibly replaced with the ISO8601 international standard date and time format or the Network Time Protocol (NTP) timestamp format.

[0062] The calculated one-time password (P) is typically displayed as a decimal numeric string. When the calculated number of significant digits is less than the preset length (e.g., less than 6 digits), alignment is performed by padding with leading zeros. Understandably, depending on the input and verification requirements of different business systems, this password can also be encoded as a hexadecimal string, Base32 encoded format, or Base64 encoded format, among other forms.

[0063] It should be noted that the complete authentication process, including device pairing, password generation, and legitimacy verification, involved in the embodiments of this application can be completed in an offline environment without a wide area network. In practical application scenarios, the first and second devices do not need to access the public internet, nor do they need to rely on cloud servers for data relay. Even in offline environments without cellular mobile networks (such as lack of mobile data) or external broadband networks, both devices only need to establish a point-to-point direct communication link based on near-field communication technologies (such as Bluetooth, NFC, etc.) to independently and in a closed loop complete all identity interaction and authentication processes.

[0064] like Figure 1 As shown, this application provides a data processing method applied to a first end, including steps 110, 120 and 130.

[0065] It should be noted that, Figure 1The illustrated method flow corresponds to the single-session authentication phase performed after the first and second ends have pre-completed secure pairing. Specific implementation details of the preceding device pairing process will be further elaborated later in conjunction with other embodiments. Furthermore, for security reasons, all temporary session data generated during this authentication phase can be stored in memory and destroyed immediately after the session ends.

[0066] Step 110: Receive the second-end session random number returned by the second end, generate the first-end session random number, and send the first-end session random number to the second end; In this step, the second-end session random number is generated by the second end in response to the session authentication request for the target session sent by the first end.

[0067] The session authentication request contains the first entity identifier corresponding to the first end.

[0068] A target session refers to the communication interaction process established between the first and second ends after pre-completing secure pairing, for the purpose of performing a single authentication. In actual execution, the first end initiates an authentication request to the second end, including its unique device identifier. Once the second end verifies the request, the target session is established. Establishing this target session defines a strict lifecycle boundary for subsequent parameter generation and data storage.

[0069] In actual execution, the target session can correspond to the "current session" lifecycle of each temporary parameter (such as random number, interaction entropy, etc.) in Table 1 above.

[0070] By establishing this target session, a strict lifecycle boundary is defined for subsequent password generation, ensuring that the interaction entropy and one-time password generated based on this session are only valid for this authentication, thereby preventing network eavesdropping and replay attacks to a certain extent.

[0071] The second-end session random number refers to the random parameters generated locally by the second end during the authentication session interaction, which can be represented as R2 according to Table 1. Its data length can be set to 256 bits, temporarily stored in memory, and its lifespan is limited to the duration of the target session (i.e., corresponding to "this session" in Table 1). In actual execution, this second-end session random number can be generated locally by the second end after receiving the session authentication request and verifying the legitimacy of the first end's identity, by calling the hardware-level random number generator (TRNG) at the underlying level of the second-end device. Its data length can be 256 bits, and it is temporarily stored in the memory context of this session.

[0072] The first-end session random number refers to the random parameters generated locally by the first end during the authentication session interaction, which can be represented as R1 according to Table 1. Its data length can be set to 256 bits, temporarily stored in memory, and its lifespan is limited to the duration of the target session (i.e., corresponding to "this session" in Table 1). The first-end session random number can be generated locally by calling the hardware-level random number generator (TRNG) at the bottom layer of the first-end device.

[0073] In some embodiments, the timing of generating the first-end session random number and the second-end session random number may include, but is not limited to, the following situations: Pre-generate (e.g., as a random number cache pool) before sending the session authentication request for the target session to the second end. Generation is triggered in real time after a session authentication request for the target session is sent to the second end; Generate periodically at preset intervals or based on preset timestamps.

[0074] It should be noted that the specific timing for generating the first-end session random number and the second-end session random number can be flexibly determined based on the computing power consumption, network latency requirements, and security level in the actual application scenario.

[0075] In particular, it is preferable to generate the first-end session random number in real time after sending the session authentication request for the target session to the second end. This can shorten the retention time of the random number in the device memory, reduce the risk of leakage caused by memory read or side-channel attacks, and thus improve the security and anti-interception capability of the entire authentication process.

[0076] It is understood that the generation timing of the first-end pairing random number and the second-end pairing random number in the following text also applies to the above rules. They can be generated immediately based on the pairing request, or they can be generated in advance and stored securely. This application embodiment does not impose specific restrictions on this.

[0077] The first entity identifier is data used to uniquely identify the identity of the first-end device, and can be represented as IDc in Table 1 for specific parameters. In actual execution, the length of the first entity identifier can be set to 128 bits, and it is stored in the ordinary storage area of ​​the first-end device as long-term valid data. The first entity identifier is usually generated by the first end in the pre-pairing stage and registered in the pairing device list of the second end.

[0078] As device identity data that is valid for a long lifecycle, the first entity identifier can be directly stored in the conventional non-volatile storage area of ​​the first-end device (such as Flash memory, EEPROM and other general storage media).

[0079] Through this first entity identifier, the second end can verify the legitimate pairing status of the first end, and thereby retrieve the corresponding shared seed key from local secure storage, thus smoothly advancing the subsequent authentication and password generation process.

[0080] In actual execution, the first end can proactively initiate an authentication request to the second end to start the session based on user operation commands, near-field sensing between devices, or authentication triggers from the business system, and attach the first entity identifier to the request to declare its device identity.

[0081] In some embodiments, a preset timeout threshold (e.g., 10 seconds) can be configured for the above authentication request to cope with abnormal situations such as near-field communication fluctuations or the device moving out of the communication range.

[0082] If no valid response is received from the second end or no subsequent interaction confirmation is completed within the timeout threshold, the session will be automatically terminated and all temporary memory data corresponding to the session will be cleared, thereby reducing the invalid suspension and occupation of resources.

[0083] In some embodiments, after receiving the second-end session random number returned by the second end, the method includes: Perform validity checks on the random numbers generated in the second-end session; If the random number of the second session meets the preset validity conditions, a random number of the first session is generated. If the random number generated by the second-end session does not meet the preset validity conditions, the authentication process of the target session will be terminated.

[0084] In this embodiment, the validity verification may include, but is not limited to, data compliance check methods such as length verification, format verification, data type verification, null value verification, or randomness detection (such as entropy value validity detection).

[0085] Taking length verification as an example, in some embodiments, after receiving the second-end session random number returned by the second end, the following steps are included: Length verification is performed by obtaining the data bit length of the random number from the second-end session. If the data bit length is equal to the preset data length, generate a random number for the first session. In this embodiment, the authentication process of the target session is terminated if the data bit length is not equal to the preset data length. The preset data length can be set to 256 bits with reference to Table 1.

[0086] In actual execution, when the first end sends an authentication request containing the first entity identifier (IDc), the second end first verifies whether the IDc exists in the list of paired devices. If it exists, it retrieves the shared seed key (such as K in Table 1) corresponding to the IDc from the secure execution environment, and simultaneously generates a second-end session random number and returns it to the first end. If the IDc does not exist in the list of paired devices, it returns a "device not paired" error message and terminates the session. The second end can store this second-end session random number (i.e., R2 in Table 1) in the session context and set its validity period (e.g., 2 minutes). The secure execution environment is a secure area on the first-end device independent of the operating system, used for storing sensitive data and performing cryptographic operations.

[0087] After receiving the random number from the second end, the first end performs the aforementioned length verification. If the random number does not meet the preset data length requirement of 256 bits, the first end determines that the parameter is abnormal and terminates the session process; if the length verification passes, the first end immediately generates the corresponding first-end session random number (i.e., R1 in Table 1) and sends it to the second end, and then enters the subsequent interaction entropy calculation stage based on the two random numbers.

[0088] According to the data processing method provided in this application embodiment, the introduction of this legality verification mechanism can filter abnormal data during communication and intercept malicious attacks targeting data formats, thereby maintaining the execution stability of subsequent parameter fusion calculations; based on the pre-emptive data compliance verification, the security of identity authentication and business authorization between the two-end devices is enhanced. In some embodiments, before step 110, the method further includes: Obtain the pairing request information output from the second end; Generate a first entity identifier and a first paired random number corresponding to the first end; Based on the first pairing random number and the random challenge code, pairing verification data is generated, and the first pairing random number, the first entity identifier, and the pairing verification data are sent to the second end; The system receives the second paired random number returned from the second end and performs cryptographic operations based on the first and second paired random numbers to generate a shared seed key.

[0089] In this embodiment, the pairing request information includes a second entity identifier corresponding to the second end, a pairing request identifier, and a random challenge code.

[0090] The second entity identifier is the data used to uniquely identify the second-end device, which can be represented as IDs as shown in Table 1. Its data length can be set to 128 bits, and it is recorded as a long-term valid data record in the conventional general-purpose storage medium of the second-end device.

[0091] The pairing request identifier is used to instruct the first end and the second end to pair.

[0092] The first and second paired random numbers are random parameters generated locally by the first and second ends during the pre-pairing phase using their respective hardware-level random number generators (TRNGs). They are used together for bidirectional negotiation to generate a shared seed key.

[0093] The random challenge code is a temporary parameter generated by the second end during pairing initialization. It is used by the first end to perform hash calculations with local random numbers and return the result, in order to verify the real-time nature of the interaction and reduce the risk of malicious replay.

[0094] The shared seed key refers to the core key parameter generated through bidirectional negotiation between the first and second ends during the pre-pairing phase, which can be represented as K as shown in Table 1. Its data length can be set to 256 bits and stored as long-term valid data in the device's Secure Execution Environment (TEE) or Secure Element (SE). This key will be retrieved during subsequent authentication sessions as a fundamental parameter for cryptographic operations to generate one-time passwords.

[0095] In practice, the pre-pairing phase typically needs to be conducted in a physically secure, controlled environment, using an out-of-band secure channel to transmit initial interaction data. The pre-pairing phase includes: pairing initialization, parameter exchange and verification, and bidirectional negotiation to generate a shared seed key. The specific interaction steps are as follows: Step 1: Pairing Initialization: The second end first enters the device pairing mode, generates a 128-bit unique identifier for the second end device, namely the second entity identifier IDs, and outputs pairing request information containing the second entity identifier, the pairing request identifier, and the random challenge code.

[0096] In addition, a preset timeout threshold (e.g., 5 minutes) can be configured for this pairing mode. If the timeout occurs, the pairing mode will be automatically exited and the relevant temporary data will be destroyed.

[0097] Step 2: Request Acquisition and Parameter Generation: The first end scans the QR code of the corresponding device of the second end to parse out the IDs and random challenge code, and generates the first entity identifier (e.g., IDc, data length set to 128 bits) and the first paired random number (Kc, data length set to 256 bits) corresponding to the first end.

[0098] In other embodiments, the second end may also output the pairing request information via out-of-band interaction methods such as Near Field Communication (NFC) touch, Bluetooth Low Energy (BLE) broadcast, or acoustic wave transmission. Subsequently, the first end generates pairing verification data based on the first pairing random number and the random challenge code.

[0099] In some embodiments, the calculation of pairing verification data can be expressed by the formula: Kc_hash = HMAC-SHA256(Kc, random challenge code).

[0100] Wherein, Kc_hash represents the pairing verification data calculated based on the hash message authentication code algorithm; HMAC-SHA256 represents the hash message authentication code calculation function based on the SHA-256 algorithm; and Kc represents the first pairing random number generated by the first end.

[0101] After the pairing verification data is calculated, the first end sends the first entity identifier, the pairing verification data, and the first pairing random number (i.e., IDc, Kc_hash, and Kc) to the second end.

[0102] Step 3: Second-end Response and Key Generation: After receiving the above data, the second end first verifies the format and correctness of the pairing verification data (Kc_hash). Upon successful verification, the second end generates a second pairing random number (Ks, 256 bits) and calculates the shared seed key based on the first and second pairing random numbers. Subsequently, the second end returns the generated second pairing random number (Ks) to the first end and records the binding relationship (IDc, K) between the first entity identifier and the shared seed key in its local list of paired devices.

[0103] In some embodiments, the calculation of the shared seed key by the second end based on the first paired random number and the second paired random number can be expressed by the following formula: K = HMAC-SHA256(Kc, Ks).

[0104] Where K represents the shared seed key generated at the second end; HMAC-SHA256 represents the hash message authentication code calculation function based on the SHA-256 algorithm; Kc represents the first pairing random number; and Ks represents the second pairing random number.

[0105] Step 4: First-end confirmation and completion: After receiving the second paired random number returned by the second end, the first end performs the same cryptographic operation based on the first paired random number and the second paired random number to generate a shared seed key.

[0106] In some embodiments, the calculation of the shared seed key at the first end can be expressed by the following formula: K = HMAC-SHA256(Kc, Ks).

[0107] Where K represents the shared seed key generated by the second end; HMAC-SHA256 represents the hash message authentication code calculation function based on the SHA-256 algorithm; Kc represents the first pairing random number; and Ks represents the second pairing random number returned by the second end.

[0108] Subsequently, the first end stores the binding relationship (IDs, K) between the second entity identifier and the shared seed key in its local Secure Execution Environment (TEE) or Secure Element (SE), and sends a pairing success confirmation command to the second end. After both parties complete the confirmation, they immediately clear the relevant temporary interaction data (such as the first / second pairing random numbers and random challenge codes), thus completing the entire pre-pairing process.

[0109] According to the data processing method provided in this application, the initial data is transmitted through a physically controlled environment and an out-of-band secure channel during the pre-pairing stage. Combined with random challenge code verification and a dynamic negotiation mechanism for independent random numbers at both ends, the risk of shared seed key exposure in the communication link is reduced. While achieving real-time interaction, this significantly reduces the risk of eavesdropping and replay attacks in open networks. Furthermore, by integrating the isolated storage mechanism of a secure execution environment (TEE or SE) and an immediate cleanup strategy for temporary interactive data, a complete security closed loop covering data transmission, computational negotiation, and storage destruction is constructed. This achieves security in initial trust establishment and enhances the shared seed key's resistance to reverse engineering and memory attacks.

[0110] It is understood that in the aforementioned embodiments, the initial data interaction during the pre-pairing phase mainly relies on out-of-band secure channels (such as QR code scanning, NFC touch, and other physical near-field interactions) to ensure the security of parameter transmission. To further adapt to device pairing scenarios under untrusted networks (such as public Wi-Fi, remote Internet, and other open networks), in some other embodiments, a cryptographic-based ciphertext transmission mechanism can also be introduced for the initial interaction data.

[0111] In some embodiments, before transmitting the first paired random number, the second paired random number, and the entity identifier, the first end and the second end may pre-acquire or exchange their respective asymmetric public keys (e.g., RSA public keys or SM2 public keys), and use the other end's public key to perform asymmetric encryption on the paired random number generated by their respective ends, before sending it to the other end, where the other end decrypts and extracts it using the corresponding private key. Alternatively, the two ends may pre-establish a secure encrypted transmission channel through a key negotiation protocol (e.g., ECDH protocol), and use the negotiated temporary transmission key to perform symmetric encryption (e.g., AES encryption) on the paired data before sending it. By introducing the above-mentioned ciphertext transmission mechanism, it is possible to effectively defend against man-in-the-middle eavesdropping and data tampering attacks in open network environments, further improving the applicability and security of the system in complex network architectures.

[0112] Step 120: Perform cryptographic operations on the interaction entropy, time counter, and shared seed key determined based on the first-end session random number and the second-end session random number to generate the first one-time password for the target session; In this step, the shared seed key is the key corresponding to the first entity identifier.

[0113] Interaction entropy refers to a session-level unique parameter calculated by the session random numbers generated by the first and second ends during the target session through their respective interactions (i.e., the session random number of the first end and the session random number of the second end).

[0114] Referring to Table 1, the interaction entropy can be represented as E, with a data length of 256 bits, calculated independently by the first and second ends. This parameter is temporarily stored in memory, and its lifespan is limited to the duration of the target session (i.e., corresponding to "this session" in Table 1). This parameter tightly binds the specific context of the target session with the password generation process, thereby ensuring the uniqueness of the password generated in a single target session.

[0115] A time counter is a dynamic reference parameter calculated based on time parameters (such as the current system time and the internal hardware clock (RTC)) and a preset time step. It is used to provide input variables that are updated over time for cryptographic operations, so that the generated one-time password has a specific effective time window.

[0116] Referring to Table 1, this time counter can be represented as C. Its data length can be set to 32 bits, generated independently by the first and second ends. This parameter is temporarily stored in memory, and its lifespan is limited to the duration of the target session (i.e., corresponding to "this session" in Table 1).

[0117] The first one-time password is a dynamic password generated by the first end through cryptographic operations based on interaction entropy, time counter, and shared seed key. It is used by the second end to verify the legitimacy of the target session.

[0118] In actual implementation, taking the electronic safe system in the field of intelligent security as an example, the first end can be specifically implemented as an electronic password key (client), and the second end can be specifically implemented as a password safe (server).

[0119] Initially, if the electronic key is not properly paired with the safe, the safe does not contain the corresponding shared seed key, thus preventing verification and maintaining the lock. After successful pairing and triggering the target session, the safe and electronic key exchange bidirectional session random numbers (i.e., exchanging R2 and R1). The client then calculates and generates a first one-time password, displaying the first six digits on the screen. The user reads this and enters the six-digit password into the safe's input panel. The safe then performs local synchronous verification. Upon successful verification, the unlocking mechanism is triggered, completing a highly secure dynamic password verification process.

[0120] In some embodiments, step 120 includes: The interaction entropy corresponding to the target session is obtained by performing parameter fusion calculation based on the random numbers of the second-end session and the random numbers of the first-end session. Cryptographic operations are performed based on a time counter determined by the target time parameter, a shared seed key, and interaction entropy to generate a first one-time cipher corresponding to the target session.

[0121] In this embodiment, the generation process of the first one-time password is performed in the secure execution environment (TEE) of the first end.

[0122] The parameter fusion operation can employ symmetric key-based authentication algorithms such as HMAC-SHA256, AES-CMAC, or HMAC-SM3, as well as standard one-way digest algorithms such as SHA-3 and the national cryptographic SM3 algorithm. In other embodiments, it can also be based on logical operations (such as XOR, bitwise concatenation, etc.), symmetric encryption operations (such as AES algorithm), or irreversible derivation operations performed on the random numbers of the second-end session and the random numbers of the first-end session, and other cryptographic parameter fusion operations with parameter fusion characteristics, to obtain the interaction entropy corresponding to the target session.

[0123] It is understood that the embodiments of this application do not limit the specific algorithm form for generating interaction entropy. Considering data security dimensions such as resistance to deduction, any suitable algorithm capable of fusing two-end random numbers and deriving data with unique characteristics of a single session is covered within the protection scope of the embodiments of this application. In some embodiments, taking the parameter fusion operation performed using the HMAC-SHA256 algorithm as an example, the calculation process of deriving interaction entropy based on the second-end session random number and the first-end session random number can be expressed by the formula: E = HMAC-SHA256(R1, R2).

[0124] Where E represents the calculated interaction entropy; HMAC-SHA256 represents the hash message authentication code calculation function based on the SHA-256 algorithm; R1 represents the first-end session random number; and R2 represents the second-end session random number.

[0125] In some embodiments, the time counter determined based on the target time parameter includes: The time counter is determined based on the target time parameters, preset time base, and preset time step size determined by the current timestamp.

[0126] In actual execution, the first end obtains the current timestamp as the target time parameter. Referring to Table 1, the time counter calculated by the first end can be expressed by the formula: C = floor((T - T0) / X).

[0127] Where C represents a time counter; floor() represents the floor function; T represents the target time parameter determined based on the current timestamp. Referring to Table 1, T can be a Unix timestamp in seconds, with a data length of 32 bits, which is independently obtained by the first and second ends and stored in memory as temporary parameters; T0 represents the preset time base. Referring to Table 1, it represents the starting point of the time step, with a data length of 32 bits. It is agreed upon by the first and second ends and stored in the configuration file. The default value can be set to 0 (corresponding to 1970-01-01 00:00:00UTC). X represents the preset time step. Referring to Table 1, its data length is 32 bits, which is also agreed upon by both parties and stored in the configuration file. The default value can be set to 30 seconds.

[0128] In addition, considering the possible underlying clock skew or network interaction delay between the first and second ends, this embodiment is also equipped with a time synchronization fault tolerance mechanism, which allows a deviation of ±1 time step.

[0129] According to the data processing method provided in this application, a random entropy source generated by the interaction between the two devices is used to calculate the characteristic data belonging to a single session as the interaction entropy. This interaction entropy is then used to generate a one-time password, ensuring that the password generation result is jointly determined by the time parameter and the state of the single session, thus eliminating the single dependence of the authentication password on the time synchronization mechanism. When the system is within the same time counting step, it can output differentiated authentication passwords based on the uniqueness of the interaction entropy in a single session, thereby ensuring that the passwords generated by different sessions within the same time window are different. Since the intercepted password cannot be verified in other sessions, the risk of replay attacks within the same time window is reduced, enhancing the overall security of identity authentication and business authorization between the two devices.

[0130] In some embodiments, cryptographic operations are performed based on a time counter determined by a target time parameter, a shared seed key, and interaction entropy to generate a first one-time cipher corresponding to the target session, including: The shared seed key, time counter, and interaction entropy are concatenated to obtain the first target input data; Using a shared seed key as the key, the first target input data is authenticated and calculated based on the cryptographic message authentication code algorithm to obtain the first password string; The first password string is dynamically truncated to generate the first one-time password.

[0131] In this embodiment, the password message authentication code algorithm can combine the original input data (such as the first target input data after concatenation) with a specific key to convert it into a fixed-length combined data, so that the content of the combined data is not tampered with and the source is legitimate and trustworthy.

[0132] In some embodiments, the cryptographic message authentication code algorithm may include, but is not limited to: HMAC-SHA256, HMAC-SHA512, block cipher-based CMAC (such as AES-CMAC), and national cryptographic standard algorithms (such as SM4-MAC).

[0133] In actual execution, the specific calculation steps for the first end (Client) are as follows: Step 1: Data concatenation: The first end concatenates the acquired shared seed key, time counter, and interaction entropy at the byte level to obtain the first target input data. The concatenation process can be expressed by the formula: Input = K || C || E.

[0134] Where Input represents the first target input number obtained by concatenation; || represents the byte concatenation operation; K represents the shared seed key; C represents the time counter; and E represents the interaction entropy.

[0135] Step 2: Authentication Calculation: The first end uses the shared seed key as the key and performs a hash operation on the first target input data based on the cryptographic message authentication code algorithm to obtain the first password string. This calculation process can be expressed by the formula: H = HMAC - SHA256(Input, K).

[0136] Where H represents the first generated password string (e.g., a hash result of 32 bytes); HMAC-SHA256 represents the hash message authentication code calculation function based on the SHA-256 algorithm; K represents the shared seed key used as the operation key; and Input represents the first target input data to be processed.

[0137] Step 3: Dynamic truncation to generate one-time password: The first end executes a dynamic truncation algorithm to process the first password string and generate the first one-time password.

[0138] The following example illustrates the process of generating the first one-time password based on the dynamic truncation algorithm DT(H).

[0139] Take the lower 4 bits of the last byte of the first password string H as the offset (0≤offset≤15).

[0140] Starting from the offset byte of the first password string H, extract 4 bytes consecutively and concatenate them to form a 32-bit unsigned integer binary.

[0141] Clear the highest bit of the unsigned integer binary to reduce data conversion errors caused by the sign bit. This operation can be represented as: binary = binary&0x7FFFFFFF.

[0142] Calculate the initial password value: code = binary % 10^digits. Where digits is the preset target password length (default value is 6).

[0143] Convert the initial password value 'code' into a decimal string format; if the string length is less than 'digits', pad it with 0s at its high bits.

[0144] The calculated decimal string is output as the first one-time password P.

[0145] According to the data processing method provided in this application, the interaction entropy, time counter, and shared seed key generated by real-time interaction between the two devices are concatenated as input data, and a one-time password is generated through cryptographic operations and dynamic truncation. This generation mechanism utilizes a random entropy source, ensuring that the password generated for each session authentication is globally unique. Even under the same time counter period, the password is only valid for the current session, effectively reducing the risk of password replay or derivation, and enhancing the security of identity authentication and business authorization between the two devices.

[0146] Step 130: Send the first one-time password to the second end and receive the authentication result returned by the second end.

[0147] In this step, the first one-time password is used by the second end to verify the legitimacy of the target session.

[0148] In actual execution, the first end generates a first one-time password and sends it to the second end. After receiving the first one-time password, the second end extracts the same shared seed key associated with the target session, the synchronized time counter, and the locally calculated interaction entropy, and performs the same cryptographic operations as the first end, thereby independently generating a second one-time password locally for comparison.

[0149] Subsequently, the second end performs a consistency comparison between the first one-time password and the second one-time password. If they match perfectly, the validity verification is deemed successful; if they do not match, based on the aforementioned time synchronization fault tolerance mechanism, the second end can update its local time counter within the allowed time step deviation range (e.g., by +1 or -1 time steps) and recalculate the corresponding second one-time password for comparison again.

[0150] Within the time tolerance window, if the second one-time password recalculated based on the updated time counter matches the first one-time password, the validity verification is considered successful; if, after traversing the time tolerance window, the second one-time password calculated based on the tolerance time step does not match the first one-time password, the verification is considered to have failed.

[0151] The first end finally receives the authentication result returned by the second end based on the above complete comparison process, and confirms the security verification status of the target session accordingly (for example, confirming whether the unlocking command of the corresponding password safe has been successfully authorized).

[0152] In some embodiments, after step 130, the data processing method further includes: Based on the termination status of the target session, destroy the temporary interactive data generated during the operation of the target session, clear the context of the target session, and close the connection corresponding to the target session.

[0153] In this embodiment, the temporary interaction data includes, but is not limited to, the first end session random number (R1), the second end session random number (R2), the interaction entropy (E), the time counter (C), the first password string (H), and the first one-time password (P).

[0154] In actual execution, under normal communication conditions, regardless of whether the authentication result of the target session is successful or unsuccessful, the first end triggers a data cleanup command upon receiving the authentication result. For example, the first and second ends respectively destroy all temporary interaction data (i.e., R1, R2, E, C, H, P, etc.) that the target session depends on from memory, clear the context records associated with the target session, and disconnect the current communication connection to reduce the security leakage risk caused by sensitive data residing in memory.

[0155] In the event of a communication interruption, if the first end experiences a communication interruption after obtaining the second end's session random number (R2), it still generates and outputs the first one-time password (P) locally. Since the authentication result cannot be received, the first end, based on the local time timeout mechanism, determines that the target session has timed out when the waiting time exceeds a preset time threshold, and performs the aforementioned data destruction, context clearing, and connection closing operations.

[0156] In some embodiments, to further enhance the security of authentication, this application also supports a two-way authentication mode after step 130. In this mode, the second end synchronously performs cryptographic calculations based on the same shared seed key, interaction entropy, and time counter to generate a baseline cipher string for verification, and sends it back to the first end. The first end confirms the legitimacy of the second end's identity by comparing it with locally stored verification information or by executing reverse signature verification logic. This mechanism effectively defends against server-forged attacks and enhances the mutual trust level between the two parties during the session by introducing cryptographic reverse confirmation from the server to the client.

[0157] During the anomaly handling and security enhancement process of the above data processing method, in response to potential time synchronization deviation issues, in addition to the time synchronization fault tolerance mechanism configured above, the second end can send the current accurate system timestamp to the first end after successful authentication, so that the first end can automatically calibrate the local time parameters; when the time difference between the two ends is detected to exceed the preset tolerance threshold (e.g., more than two time steps), the second end determines that the authentication has failed and can generate a prompt message to guide the user to synchronize the time; at the same time, the interaction between the first end and the second end also supports the configuration of a manually triggered time calibration function.

[0158] To defend against replay attacks, the calculated interaction entropy possesses session-level anti-spoofing characteristics (i.e., uniqueness) because each target session generates dynamically changing session random numbers. Combined with a temporary data destruction mechanism after session termination, this prevents the interaction entropy from being reused. Furthermore, the second end can maintain a list of used second session random numbers (R2) locally, with a validity period of two time steps to reduce the probability of R2 being replayed. Additionally, the interaction frequency of the first and second entity identifiers within a preset time window can be limited to prevent brute-force password attacks or malicious probing attacks. For example, the same IDc can be allowed a maximum of three authentication attempts per minute; exceeding this limit results in a 10-minute lockout.

[0159] To address the risk of interception and eavesdropping at the network link level, during the pre-pairing phase, according to the above embodiments, the first end and the second end can exchange parameters through an out-of-band secure channel (such as near-field communication NFC or QR code recognition), thereby reducing the risk of initial data being stolen. In other embodiments, to adapt to untrusted remote network environments, it supports the integration of asymmetric key exchange algorithms such as Elliptic Curve Diffie-Hellman (ECDH) to build a remote negotiation channel, thereby completing the shared seed key negotiation in remote scenarios.

[0160] In the security-enhanced embodiment involving remote interaction, the parameter interaction process in the pre-pairing phase, as well as various interaction data (such as session random numbers, one-time passwords, authentication results, etc.) in the subsequent session authentication phase, can be further loaded into an encrypted transmission channel constructed by communication protocols such as TLS 1.3, DTLS, IPsec, or custom payload encryption based on AES for ciphertext transmission. By introducing multiple layers of encryption encapsulation at the transport layer, security support for the core authentication logic of this application is provided at the transport layer.

[0161] To protect the security of the shared seed key, the aforementioned shared seed key K can be stored independently in the device's Secure Execution Environment (TEE) or Secure Element (SE), and it is prohibited to export it in plaintext to ordinary memory or conventional storage media. Furthermore, the key and its related sensitive information are prohibited from being recorded in the logs.

[0162] In addition, the key can be rotated periodically through a secure channel; when the device is detected to be performing initialization operations such as restoring factory settings, all stored seed keys will be automatically and completely destroyed.

[0163] Examples of error types, corresponding handling methods, and retry strategies that occur during the interaction between the first and second ends are shown in Table 2.

[0164]

[0165] like Figure 2 As shown, this application also provides a data processing method applied to a second end, including steps 210, 220, 230 and 240.

[0166] It should be noted that, Figure 2 The illustrated process flow corresponds to the single-session authentication phase performed after the first and second ends have completed secure pairing in advance. The specific implementation details of the preceding device pairing process have been explained in detail above and will not be repeated here.

[0167] Step 210: Receive the session authentication request corresponding to the target session sent by the first end, and extract the corresponding shared seed key if the first entity identifier in the session authentication request is valid. In this step, the target session is a temporary communication connection initiated and established by the first end.

[0168] The shared seed key is a symmetric key parameter that is negotiated and generated by the first end and the second end during the aforementioned pre-pairing phase and stored independently in the Secure Execution Environment (TEE).

[0169] In actual execution, the second end listens for and receives a session authentication request initiated by the first end, which includes a first entity identifier (IDc). Upon receiving the request, the second end verifies whether the first entity identifier exists in the list of paired devices.

[0170] In some embodiments, step 210 includes: If the first entity identifier matches a preset pairing record, the first entity identifier is determined to be valid, and the shared seed key corresponding to the first entity identifier is extracted. If the first entity identifier does not match the preset pairing record, return an error message to the first end and terminate the target session.

[0171] In actual execution, after receiving a request, the second end verifies whether the first entity identifier exists in the list of paired devices.

[0172] If the verification is in this list, the second end determines that the first entity identifier is valid and extracts the shared seed key (K) uniquely bound to the identifier from the local secure execution environment.

[0173] If the device is not found in the list, the second end returns an error message "Device not paired" to the first end and terminates the session.

[0174] In some embodiments, before receiving a session authentication request for the target session sent by the first end, the method further includes: Generate a second entity identifier corresponding to the second end, and output the pairing request information; Receive the first entity identifier, the first pairing random number, and the pairing verification data returned by the first end based on the pairing request information; If the pairing verification data passes the test, a second pairing random number is generated; The shared seed key is obtained by calculating based on the first and second paired random numbers, and the second paired random number is sent to the first end.

[0175] In this embodiment, the pairing request information includes a second entity identifier, a pairing request identifier, and a random challenge code.

[0176] During the pre-pairing phase, the interaction between the first and second ends can be conducted in a trusted physical environment based on out-of-band secure channels (such as visual QR code scanning, NFC near-field communication, etc.) to improve the security of initial data transmission.

[0177] When the second end enters pairing mode, a second entity identifier (e.g., configured as a 128-bit device unique identifier ID) is generated corresponding to the second end, and pairing request information containing the second entity identifier, pairing request identifier, and random challenge code is generated.

[0178] In some embodiments, the second end can output the pairing request information by displaying a pairing QR code on the interface.

[0179] In this embodiment, the second end can configure a preset timeout duration (e.g., 5 minutes) for the pairing mode. Once the timeout is reached, the mode will automatically exit and the corresponding temporary data will be destroyed.

[0180] Subsequently, the first end scans the aforementioned pairing QR code to parse and obtain the relevant parameters from the pairing request information. Then, the first end generates its own first entity identifier IDc and first pairing random number Kc, and performs a hash calculation based on the first pairing random number and the random challenge code to generate the corresponding pairing verification data Kc_hash. After the calculation is complete, the first end sends the first entity identifier IDc, the first pairing random number Kc, and the pairing verification data Kc_hash to the second end.

[0181] After receiving the returned data, the second end verifies the correctness of the Kc_hash format. If the Kc_hash verification passes, the second end locally generates a second paired random number Ks, and performs parameter fusion calculations based on the received first paired random number Kc and second paired random number Ks to obtain the shared seed key K. The process of calculating the shared seed key K has been explained in detail above and will not be repeated here.

[0182] Subsequently, the second end sends the generated second pairing random number Ks back to the first end, so that the first end can synchronously calculate a consistent shared seed key and bind the first entity identifier IDc to the shared seed key K, storing it in the local list of paired devices.

[0183] Step 220: Send the generated second-end session random number to the first end, receive the first-end session random number returned by the first end, and perform parameter fusion calculation based on the first-end session random number and the second-end session random number to obtain the interaction entropy corresponding to the target session; In actual execution, the second end sends the generated second-end session random number R2 to the first end. After receiving this data, the first end generates a first-end session random number R1 of the corresponding length and returns R1 to the second end.

[0184] The second end receives the first end's session random number R1 and performs a validity check on it. If the check finds an abnormal length, the second end will determine that the parameter is incorrect, return an error message to the first end, and terminate the current session directly. If the check passes, the second end extracts the second end's session random number R2 and performs a parameter fusion operation with the received first end session random number R1 to obtain the interaction entropy E corresponding to the target session. The aforementioned parameter fusion operation has been explained in detail above and will not be repeated here.

[0185] In some embodiments, taking the parameter fusion operation performed using the HMAC-SHA256 algorithm as an example, the calculation process of deriving the interaction entropy based on the random numbers of the second-end session and the random numbers of the first-end session can be expressed by the following formula: E = HMAC-SHA256(R1, R2).

[0186] Where E represents the calculated cross-entropy; HMAC-SHA256 represents the hash message authentication code calculation function based on the SHA-256 algorithm; R1 represents the random number of the first-end session; and R2 represents the random number of the second-end session. It should be noted that the cross-entropy calculation process in the second end is the same as that in the first end, to ensure data consistency between the two ends.

[0187] Step 230: Receive the first one-time password sent by the first end, and generate a second one-time password based on the interaction entropy, time counter and shared seed key; In this embodiment, the first one-time password is used by the second end to verify the legitimacy of the target session.

[0188] The second one-time password is a comparison password generated by the second end, used to compare its consistency with the received first one-time password to determine whether the validity verification has passed.

[0189] In some embodiments, step 230 includes: The shared seed key, time counter, and interaction entropy are concatenated to obtain the second target input data; Using the shared seed key as the key, the second target input data is authenticated and calculated based on the cryptographic message authentication code algorithm to obtain the second password string; The second password string is dynamically truncated to generate a second one-time password.

[0190] In this embodiment, the second target input data is the data constructed by the second end locally by concatenating the shared seed key, time counter, and interaction entropy at the byte level.

[0191] The second password string is a fixed-length data string generated by the second end after processing the second target input data using the password message authentication code algorithm.

[0192] In actual execution, after receiving the first one-time password P sent by the first end, the second end reuses the same algorithm rules as the first end, and independently performs data concatenation and password message authentication code calculation locally in sequence. Finally, it calls the same dynamic truncation algorithm to extract a specific number of characters, thereby calculating the expected matching password (i.e., the second one-time password P').

[0193] Step 240: Perform a consistency check on the first one-time password and the second one-time password, obtain the authentication result for the target session based on the check result, and send the authentication result to the first end.

[0194] In this embodiment, the consistency check is used to verify whether the password data submitted by the first end and the base password calculated by the second end meet the preset matching rules.

[0195] In some embodiments, step 240 includes: If the first one-time password and the second one-time password match, the authentication result for the target session is considered successful. If the first one-time password and the second one-time password are inconsistent, update the time counter and regenerate the second one-time password based on the updated time counter. Then, perform a consistency check between the first one-time password and the regenerated second one-time password to obtain the authentication result for the target session.

[0196] In actual execution, the second end receives the first one-time password P sent by the first end and compares the first one-time password P with the second one-time password P' generated at the second end. If they match, the authentication is successful; if the initial comparison does not match, the second end, based on a preset time synchronization fault tolerance mechanism, within the allowed step size deviation range (e.g., 1 time step), uses the updated time counters (C-1 and C+1) to re-execute the corresponding cryptographic calculation process, generate an appended second one-time password (P'' and P'''), and performs an append comparison.

[0197] If any of the additional one-time passwords matches the first one-time password, the authentication is still considered successful. If, after traversing the fault-tolerant window, all calculated second one-time passwords are inconsistent with the first one-time password, the authentication is considered to have failed and a corresponding error flag (such as "incorrect password") is generated. Finally, the second end returns the determined authentication result to the first end via the communication link.

[0198] According to the data processing method provided in this application embodiment, in the password verification stage, the one-time password sent by the first end is compared with the base password generated by the second end. If the initial comparison is inconsistent, a time synchronization fault tolerance mechanism is automatically triggered, and the verification is recalculated and supplemented based on the preset time deviation. This mechanism effectively reduces the dependence on time synchronization requirements and significantly improves the robustness of the verification process, thereby enhancing the security of identity authentication and business authorization between the two devices.

[0199] After in-depth research, the inventors have derived a comparison of the characteristics of related technologies TOTP and HOTP with the data processing method (i.e., the IOTP solution) provided in the embodiments of this application, as shown in Table 3.

[0200]

[0201] The data processing method provided in this application generates a globally unique password in each authentication interaction, possessing session-level independence. This enables the generation of dynamically changing password parameters even under the same timestamp or time window. Furthermore, this password is primarily valid for a single authentication session, significantly reducing security risks such as replay attacks. Logically, this method enhances forward security, increasing the computational difficulty of reverse-deriving subsequent passwords or the underlying shared seed key if a single password is intercepted. In addition, the data processing method provided in this application is compatible with existing TOTP and HOTP technologies and related infrastructure, and supports offline two-way authentication, thereby reducing reliance on third-party servers.

[0202] The data processing method provided in this application can be executed by a data processing device. This application uses an example of a data processing device executing the data processing method to illustrate the data processing device provided in this application.

[0203] This application also provides a data processing device applied to a first end.

[0204] like Figure 3 As shown, the data processing device includes: a first processing module 310, a second processing module 320 and a third processing module 330.

[0205] The first processing module 310 is used to receive a second-end session random number returned by the second end, generate a first-end session random number, and send the first-end session random number to the second end; the second-end session random number is generated by the second end in response to a session authentication request for the target session sent by the first end, and the session authentication request contains a first entity identifier corresponding to the first end; The second processing module 320 is used to perform cryptographic operations on the interaction entropy, time counter, and shared seed key determined based on the first-end session random number and the second-end session random number to generate a first one-time password for the target session; the shared seed key corresponds to the first entity identifier; the third processing module 330 is used to send the first one-time password to the second end and receive the authentication result returned by the second end; the first one-time password is used by the second end to verify the legitimacy of the target session.

[0206] According to the data processing apparatus provided in the embodiments of this application, during a single authentication process corresponding to a target session, the session-level interaction entropy is determined by the session random numbers generated by the interaction between the first and second ends. This interaction entropy, along with a time counter and a shared seed key, is then used in cryptographic operations to generate a one-time password. This mechanism enables different sessions to generate different passwords even within the same time counter period, improving the unpredictability of password generation for a single session. This effectively reduces the risk of malicious password replay and enhances the security of identity authentication and business authorization between the two devices.

[0207] In some embodiments, the second processing module 320 may also be used for: The interaction entropy corresponding to the target session is obtained by performing parameter fusion calculation based on the random numbers of the second-end session and the random numbers of the first-end session. Cryptographic operations are performed based on a time counter determined by the target time parameter, a shared seed key, and interaction entropy to generate a first one-time cipher corresponding to the target session.

[0208] In some embodiments, the third processing module 330 can also be used for: The shared seed key, time counter, and interaction entropy are concatenated to obtain the first target input data; Using a shared seed key as the key, the first target input data is authenticated and calculated based on the cryptographic message authentication code algorithm to obtain the first password string; The first password string is dynamically truncated to generate the first one-time password.

[0209] In some embodiments, the data processing apparatus may further include an eighth processing module for: Perform validity checks on the random numbers generated in the second-end session; If the random number of the second session meets the preset validity conditions, a random number of the first session is generated. If the random number generated by the second-end session does not meet the preset validity conditions, the authentication process of the target session will be terminated.

[0210] In some embodiments, the data processing apparatus may further include a ninth processing module for: Obtain the pairing request information output from the second end; the pairing request information includes the second entity identifier corresponding to the second end, the pairing request identifier, and the random challenge code; Generate a first entity identifier and a first paired random number corresponding to the first end; Based on the first pairing random number and the random challenge code, pairing verification data is generated, and the first pairing random number, the first entity identifier, and the pairing verification data are sent to the second end; The system receives the second paired random number returned from the second end and performs cryptographic operations based on the first and second paired random numbers to generate a shared seed key.

[0211] This application also provides a data processing device applied to a second terminal.

[0212] like Figure 4 As shown, the data processing device includes: a fourth processing module 410, a fifth processing module 420, a sixth processing module 430, and a seventh processing module 440.

[0213] The fourth processing module 410 is used to receive a session authentication request corresponding to the target session sent by the first end, and extract the corresponding shared seed key if it is determined that the first entity identifier in the session authentication request is valid. The fifth processing module 420 is used to send the generated second-end session random number to the first end, receive the first-end session random number returned by the first end, and perform parameter fusion calculation based on the first-end session random number and the second-end session random number to obtain the interaction entropy corresponding to the target session. The sixth processing module 430 is used to receive the first one-time password sent by the first end, and generate a second one-time password based on the interaction entropy, the time counter and the shared seed key; The seventh processing module 440 is used to perform consistency verification between the first one-time password and the second one-time password, obtain the authentication result for the target session based on the verification result, and send the authentication result to the first end.

[0214] In some embodiments, the sixth processing module 430 can also be used for: The shared seed key, time counter, and interaction entropy are concatenated to obtain the second target input data; Using the shared seed key as the key, the second target input data is authenticated and calculated based on the cryptographic message authentication code algorithm to obtain the second password string; The second password string is dynamically truncated to generate a second one-time password.

[0215] In some embodiments, the seventh processing module 440 can also be used for: If the first one-time password and the second one-time password match, the authentication result for the target session is considered successful. If the first one-time password and the second one-time password are inconsistent, update the time counter and regenerate the second one-time password based on the updated time counter. Then, perform a consistency check between the first one-time password and the regenerated second one-time password to obtain the authentication result for the target session.

[0216] In some embodiments, the fourth processing module 410 can also be used for: If the first entity identifier matches a preset pairing record, the first entity identifier is determined to be valid, and the shared seed key corresponding to the first entity identifier is extracted. If the first entity identifier does not match the preset pairing record, return an error message to the first end and terminate the target session.

[0217] In some embodiments, the data processing apparatus may further include a tenth processing module, configured to: Generate a second entity identifier corresponding to the second end, and output pairing request information; the pairing request information includes the second entity identifier, the pairing request identifier, and a random challenge code; Receive the first entity identifier, the first pairing random number, and the pairing verification data returned by the first end based on the pairing request information; If the pairing verification data passes the test, a second pairing random number is generated; The shared seed key is calculated based on the first and second paired random numbers, and the second paired random number is sent to the first end.

[0218] The data processing device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the device.

[0219] The data processing device in this application embodiment can be a device with an operating system. The operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0220] The data processing device provided in this application embodiment can achieve... Figures 1 to 2 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0221] In some embodiments, such as Figure 5 As shown, this application embodiment also provides an electronic device 500, including a processor 501, a memory 502, and a computer program stored in the memory 502 and executable on the processor 501. When the program is executed by the processor 501, it implements the various processes of the above-described data processing method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0222] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0223] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described data processing method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0224] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0225] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described data processing method.

[0226] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0227] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above data processing method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0228] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0229] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0230] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0231] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0232] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0233] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

Claims

1. A data processing method, characterized in that, Applied to a first end, which is communicatively connected to a second end, the method includes: The system receives a second-end session random number returned by the second end, generates a first-end session random number, and sends the first-end session random number to the second end. The second-end session random number is generated by the second end in response to a session authentication request for the target session sent by the first end. The session authentication request contains a first entity identifier corresponding to the first end. Cryptographic operations are performed on the interaction entropy, time counter, and shared seed key determined based on the first end session random number and the second end session random number to generate the first one-time password for the target session; the shared seed key corresponds to the first entity identifier; The first one-time password is sent to the second end, and the authentication result returned by the second end is received; the first one-time password is used by the second end to verify the legitimacy of the target session.

2. The data processing method according to claim 1, characterized in that, The step of performing cryptographic operations on the interaction entropy, time counter, and shared seed key determined based on the first-end session random number and the second-end session random number to generate the first one-time password for the target session includes: Based on the random number of the second-end session and the random number of the first-end session, a parameter fusion operation is performed to obtain the interaction entropy corresponding to the target session; Cryptographic operations are performed based on a time counter determined by the target time parameter, a shared seed key, and the interaction entropy to generate a first one-time password corresponding to the target session.

3. The data processing method according to claim 2, characterized in that, The process of performing cryptographic operations based on the time counter determined by the target time parameter, the shared seed key, and the interaction entropy to generate a first one-time cipher corresponding to the target session includes: The shared seed key, the time counter, and the interaction entropy are concatenated to obtain the first target input data; Using the shared seed key as the key, the first target input data is authenticated and calculated based on the cryptographic message authentication code algorithm to obtain the first password string; The first password string is dynamically truncated to generate the first one-time password.

4. The data processing method according to any one of claims 1-3, characterized in that, After receiving the second-end session random number returned by the second end, the method includes: The validity of the random number generated by the second-end session is verified. If the random number of the second-end session meets the preset legality conditions, the random number of the first-end session is generated. If the random number generated by the second session does not meet the preset validity conditions, the authentication process of the target session is terminated.

5. The data processing method according to any one of claims 1-3, characterized in that, Before receiving the second-end session random number returned by the second end, the method further includes: Obtain the pairing request information output by the second end; the pairing request information includes a second entity identifier corresponding to the second end, a pairing request identifier, and a random challenge code; Generate a first entity identifier and a first paired random number corresponding to the first end; Based on the first pairing random number and the random challenge code, pairing verification data is generated, and the first pairing random number, the first entity identifier, and the pairing verification data are sent to the second end; The system receives the second paired random number returned by the second end, and performs cryptographic operations based on the first paired random number and the second paired random number to generate the shared seed key.

6. A data processing method, characterized in that, Applied to a second end, which is communicatively connected to the first end, the method includes: Receive the session authentication request corresponding to the target session sent by the first end, and extract the corresponding shared seed key if the first entity identifier in the session authentication request is valid; Send the generated second-end session random number to the first end and receive the first-end session random number returned by the first end, and perform parameter fusion calculation based on the first-end session random number and the second-end session random number to obtain the interaction entropy corresponding to the target session; Receive the first one-time password sent by the first end, and generate a second one-time password based on the interaction entropy, the time counter, and the shared seed key; The first one-time password and the second one-time password are checked for consistency. Based on the check result, the authentication result for the target session is obtained and the authentication result is sent to the first end.

7. The data processing method according to claim 6, characterized in that, The step of generating a second one-time password based on the interaction entropy, the time counter, and the shared seed key includes: The shared seed key, the time counter, and the interaction entropy are concatenated to obtain the second target input data; Using the shared seed key as the key, the second target input data is authenticated and calculated based on the cryptographic message authentication code algorithm to obtain the second password string; The second password string is dynamically truncated to generate the second one-time password.

8. The data processing method according to claim 6, characterized in that, The step of verifying the consistency between the first one-time password and the second one-time password, and obtaining the authentication result for the target session based on the verification result, includes: If the first one-time password and the second one-time password are the same, the authentication result for the target session is successful. If the first one-time password and the second one-time password are inconsistent, the time counter is updated, and the second one-time password is regenerated based on the updated time counter. The consistency of the first one-time password and the regenerated second one-time password is verified to obtain the authentication result for the target session.

9. The data processing method according to any one of claims 6-8, characterized in that, The step of receiving the session authentication request for the target session sent by the first end, and extracting the corresponding shared seed key if the first entity identifier in the session authentication request is valid, includes: If the first entity identifier matches a preset pairing record, the first entity identifier is determined to be valid, and the shared seed key corresponding to the first entity identifier is extracted. If the first entity identifier does not match the preset pairing record, an error message is returned to the first end, and the target session is terminated.

10. The data processing method according to any one of claims 6-8, characterized in that, Before receiving the session authentication request for the target session sent by the first end, the method further includes: Generate a second entity identifier corresponding to the second end, and output pairing request information; the pairing request information includes the second entity identifier, pairing request identifier, and random challenge code; Receive the first entity identifier, the first pairing random number, and the pairing verification data returned by the first end based on the pairing request information; If the pairing verification data passes the verification, a second pairing random number is generated; The shared seed key is obtained by calculating based on the first and second paired random numbers, and the second paired random number is sent to the first end.

Images