End-to-end encryption authentication method based on network and device characteristics

Abstract

The application discloses an end-to-end encryption authentication method based on network and device features, and relates to the field of encryption authentication. Communication parties (a client and a server) first collect their own network and device features and calculate their cryptographic commitments. The commitments are exchanged through combined messages at the initial stage of handshaking. Then, on the basis of the initial shared key, the parties encrypt and reveal their real feature information. The receiving party verifies the cryptographic commitment of the other party based on the revealed feature information. In this way, the establishment of the session key is closely bound to the real-time network and device features of the communication parties. Only when the feature commitments of the parties are consistent with the revealed information and pass the verification, the whole authentication process is successful, thereby significantly improving the security and reliability of the authentication.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of encryption authentication, and more specifically, to an end-to-end encryption authentication method based on network and device features. BACKGROUND

[0002] In today's highly interconnected digital environment, end-to-end encryption (E2EE) technology is a key means to protect communication privacy and data security. Traditional E2EE protocols such as TLS and SSH mainly rely on digital certificates or long-term keys to verify the identity of both parties to ensure the confidentiality and integrity of data transmission. However, with the increasing complexity of network attacks, relying solely on key identity authentication has been difficult to address all security risks. Attackers may use legitimate identities to initiate communication from unauthorized environments, such as using legitimate keys in untrusted devices or networks, without obtaining long-term keys, through supply chain intrusion, internal threats, or controlling legitimate terminal devices. Such behavior, although not involving key leakage, can still cause serious security risks. Therefore, it is urgent to build a trust model beyond traditional identity authentication, which incorporates dynamic features such as real-time device status and network environment into the authentication mechanism, forming a more comprehensive and resilient end-to-end encryption scheme to improve overall communication security.

[0003] Although some existing security practices attempt to enhance security through pre-posed device posture checks or network access controls, these mechanisms are usually independent of the core end-to-end encryption key negotiation process. That is, even if a device passes strict compliance checks before connecting, subsequent end-to-end encryption handshakes are still mainly based on key identity, without inherently binding previously verified device and network features to the session key. This separation poses significant security risks. Just as traditional end-to-end encryption key negotiation protocols focus on the mathematical relationship between the public and private keys of both parties to generate a shared secret, their design does not directly consider or integrate real-time network and device environment features of both parties. This separation makes it difficult to be confident that the other party is the device based solely on the key negotiation process, even if the key itself is secure. Attackers may use the short window between passing independent pre-posed feature verification and establishing an end-to-end encryption key to perform a man-in-the-middle attack, or perform session hijacking by forging features after the end-to-end encryption key is established, as the session key is not strongly bound to these features.

[0004] Therefore, a key technical challenge is how to organically integrate the verification process of network and device features into the key negotiation protocol of end-to-end encryption, rather than simply as a pre- or post-check to achieve the core mechanism of end-to-end encryption authentication. SUMMARY

[0005] In view of the above limitations of the existing methods, according to an aspect of the present application, a network and device feature based end-to-end encryption authentication method is provided, which comprises:

[0006] The client and the server respectively collect their own network and device features to obtain client network and device features and server network and device features;

[0007] The client initiates a handshake and feature commitment to the server through a first combined message after calculating a client cryptographic commitment of the client network and device features, wherein the first combined message comprises the client cryptographic commitment;

[0008] After receiving the first combined message and passing the validity verification, the server stores the client cryptographic commitment and initiates a feature commitment to the client through a second combined message after calculating a server cryptographic commitment of the server network and device features, wherein the second combined message comprises the server cryptographic commitment;

[0009] After receiving the second combined message and passing the validity verification, the client stores the server cryptographic commitment and sends a client encryption revelation information to the server after constructing the client encryption revelation information based on the client network and device features;

[0010] After receiving the client encryption revelation information, the server obtains revealed client network and device features from the client encryption revelation information, verifies the client cryptographic commitment based on the revealed client network and device features, and sends a server encryption revelation information to the client after constructing the server encryption revelation information based on the server network and device features;

[0011] After receiving the server encryption revelation information, the client obtains revealed server network and device features from the server encryption revelation information, and verifies the server cryptographic commitment based on the revealed server network and device features.

[0012] Compared with the prior art, the end-to-end encryption authentication method based on network and device features provided in the application solves the problem of separation of feature verification and key binding in the traditional scheme by endogenously integrating the verification process of network and device features into the key negotiation protocol of end-to-end encryption. Specifically, the communication parties (client and server) first collect their own network and device features and calculate their cryptographic commitments. These commitments are exchanged through a combined message at the initial stage of the handshake. Subsequently, based on the initial shared key, the parties encrypt and reveal their real feature information. The receiving party then verifies the cryptographic commitment of the other party based on the revealed feature information. In this way, the establishment of the session key is closely bound to the real-time network and device features of the communication parties. Only when the feature commitments of the parties are consistent with the revealed information and pass the verification, the entire authentication process is successful, thereby effectively preventing attackers from communicating in non-expected environments using a legitimate identity, significantly improving the security and reliability of authentication. BRIEF DESCRIPTION OF DRAWINGS

[0013] The above and other objects, features and advantages of the present application will become more apparent from the following detailed description of embodiments of the present application, when taken in conjunction with the accompanying drawings. The drawings provided in the present application are used to provide further understanding of embodiments of the present application, and constitute a part of the specification, and are used to explain the present application together with the embodiments of the present application, and do not constitute a limitation of the present application. In the drawings, the same reference numerals generally represent the same components or steps.

[0014] Figure 1 A flowchart of the end-to-end encryption authentication method based on network and device features according to the embodiments of the present application.

[0015] Figure 2 A data flow diagram of the end-to-end encryption authentication method based on network and device features according to the embodiments of the present application.

[0016] Figure 3 A flowchart of step S2 in the end-to-end encryption authentication method based on network and device features according to the embodiments of the present application.

[0017] Figure 4 A flowchart of step S4 in the end-to-end encryption authentication method based on network and device features according to the embodiments of the present application.

[0018] Figure 5 A flowchart of step S5 in the end-to-end encryption authentication method based on network and device features according to the embodiments of the present application. DETAILED DESCRIPTION

[0019] Embodiments of the present disclosure will be described below in greater detail with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be construed as being limited to the embodiments set forth herein, but rather, these embodiments are provided so as to more completely and thoroughly understand the present disclosure. It is understood that the drawings and embodiments of the present disclosure are for exemplary purposes only and are not intended to limit the scope of protection of the present disclosure.

[0020] To solve the problems in the background art, the present application proposes an end-to-end encryption authentication method based on network and device features. Figure 1 A flowchart of the end-to-end encryption authentication method based on network and device features according to an embodiment of the present application. Figure 2 A data flowchart of the end-to-end encryption authentication method based on network and device features according to an embodiment of the present application. As shown in Figure 1 and Figure 2 The end-to-end encryption authentication method based on network and device features according to an embodiment of the present application includes: S1, a client and a server respectively collect their own network and device features to obtain client network and device features and server network and device features; S2, after calculating a client cryptographic commitment of the client network and device features, the client initiates a handshake and feature commitment to the server through a first combined message, and the first combined message includes the client cryptographic commitment; S3, after receiving the first combined message and passing the validity verification, the server stores the client cryptographic commitment and initiates a feature commitment to the client through a second combined message after calculating a server cryptographic commitment of the server network and device features, and the second combined message includes the server cryptographic commitment; S4, after receiving the second combined message and passing the validity verification, the client stores the server cryptographic commitment and, after constructing a client encryption revelation information based on the client network and device features, sends it to the server; S5, after receiving the client encryption revelation information, the server obtains revealed client network and device features from the client encryption revelation information, verifies the client cryptographic commitment based on the revealed client network and device features, and, after verifying successfully, constructs a server encryption revelation information based on the server network and device features and sends it to the client; S6, after receiving the server encryption revelation information, the client obtains revealed server network and device features from the server encryption revelation information, and verifies the server cryptographic commitment based on the revealed server network and device features.

[0021] In step S1, the client and the server respectively collect their own network and device features to obtain client network and device features and server network and device features. It should be understood that in traditional end-to-end encryption authentication, only relying on key identity authentication is not enough to cope with the increasingly complex security threats, and an attacker may initiate communication in an unexpected or compromised environment without leaking the legal key. Therefore, the present method aims to build a more comprehensive trust model by taking into account the real-time network and device features of both parties in communication. In one possible implementation, the client network and device features include operating system information, hardware information, network interface information, software and application information, and user and session information; the server network and device features include operating system information, hardware information, network interface information, software and service information, and certificate information. It is worth mentioning that these features represent the specific running environment of the communication entity, including operating system, hardware, network interface, software application and user session, etc. By obtaining these dynamic and unique environment fingerprints, it is possible to go beyond static key identity authentication and provide real and verifiable input data for subsequent cryptographic commitment and revelation processes. This is the first and necessary step to organically integrate feature verification into the end-to-end encryption key negotiation process, ensuring that the final established encryption session is not only based on key security, but also closely bound to the actual environment state of both parties in communication, thereby effectively resisting communication attempts in unauthorized environments.

[0022] Step S1 is implemented as follows: First, the client performs a feature collection operation. The feature collection module of the client actively probes and extracts various information of its current running environment. This includes obtaining operating system information such as type, version number, and kernel version by calling application programming interfaces (APIs) provided by the operating system or reading specific files. At the same time, the module collects hardware information such as central processing unit (CPU) model, core count, memory capacity, hard disk serial number, and device manufacturer and model, as well as network interface information, covering the media access control (MAC) address of all active network interfaces, the currently assigned IP address including IPv4 and IPv6, the network connection type such as Wi-Fi, cellular network, Ethernet, and the currently connected domain name resolution service (DNS) server address, for example, MAC address 00:1A:2B:3C:4D:5E and IP address 192.168.1.100. In addition, installed key applications and their version numbers, such as browser type and version, security software status such as antivirus software status, firewall enabled status, and other software and application information are scanned and recorded. Finally, user and session information such as the current login user's identity, session ID, and session establishment time are obtained, for example, username user_alice and session ID ABCDEF123456. All collected client feature information is structured and combined into a unified client network and device feature data, for example, it can be a string in a specific format or an ordered key-value pair list, ensuring consistency in subsequent processing.

[0023] Secondly, the server performs a feature collection operation. The server's feature collection module also probes and extracts various information of its current running environment. This includes obtaining the server's operating system information such as type, version number, and kernel version, as well as its hardware information such as CPU model, memory capacity, and storage device information. Network interface information is also collected, covering the MAC address, IP address, and network connection type of all active network interfaces. In addition, the software and service information of key services running on the server, such as the Web server Nginx 1.20.1, the database MySQL 8.0.30, the middleware version, and the version information of other core application software, are listed in detail. Finally, the detailed information of the digital certificate used for identity authentication by the server, including the certificate issuer, subject, validity period, public key fingerprint, and other certificate information, is also obtained, such as the SHA256 fingerprint of the certificate A1B2C3D4E5F6.... All the collected server feature information is structured and combined into a unified server network and device feature, also represented in a standardized format. During the collection process, to ensure the determinacy and repeatability of subsequent cryptographic commitments, all feature values are standardized before being combined, such as converting strings to lowercase and sorting lists in alphabetical order. Finally, the client obtains its client network and device feature, and the server obtains its server network and device feature.

[0024] In step S2, the client initiates a handshake and feature commitment to the server through a first combined message after calculating the client's cryptographic commitment of the client network and device feature, and the first combined message includes the client's cryptographic commitment. Accordingly, by calculating the cryptographic commitment of the client network and device feature at the initial stage of the handshake, the client can lock its current environment state in a tamper-proof manner, ensuring that these features cannot be maliciously tampered with or forged during the subsequent authentication process. Including this commitment in the first combined message and initiating the handshake achieves the organic integration of feature verification with the traditional key agreement process, rather than as an independent pre-check or post-check. This directly addresses the problem pointed out in the background art that an attacker may perform a man-in-the-middle attack or session hijacking by forging features during the short window after passing the independent feature verification. This ensures the authenticity and non-repudiation of the environment features of both parties when establishing a secure channel, thereby improving the overall resilience of end-to-end encrypted authentication.

[0025] In one possible implementation manner, Figure 3 The flowchart of step S2 in the network and device feature-based end-to-end encrypted authentication method according to the embodiments of the present application. As Figure 3As shown, at step S2, the client initiates a handshake and feature commitment to the server by sending a first combined message including the client cryptographic commitment after computing the client cryptographic commitment of the client network and device features, including: S21, generating a client ephemeral key pair including a client ephemeral key public key and a client ephemeral key private key; S22, selecting a random number and inputting the random number and the client network and device features into a hash function to obtain the client cryptographic commitment; S23, combining the client ephemeral key public key and the client cryptographic commitment to obtain first combined message content; S24, digitally signing the first combined message content based on a client long-term identity private key to obtain a client digital signature; and S25, packing the client digital signature and the first combined message content to obtain the first combined message.

[0026] The following is a specific implementation process of step S2: first, S21 is performed. The key generation module of the client uses a cryptographically secure pseudo-random number generator to generate a client ephemeral key pair based on pre-set elliptic curve cryptography parameters, for example, based on the secp256r1 curve. The key pair includes a client ephemeral key public key and a client ephemeral key private key. For example, the generated client ephemeral key public key can be a 32-byte elliptic curve point representation, and the client ephemeral key private key is a 32-byte random integer.

[0027] Next, S22 is performed. The commitment calculation module of the client first selects a random number, for example, a 32-byte random bit string, from a cryptographically secure pseudo-random number generator, denoted as random number_client. This random number is secret and only held by the client, and is used to ensure the uniqueness and concealment of the commitment. Then, the random number_client is concatenated with the client network and device features, for example, a normalized data exchange format string such as JSON or XML. The concatenated data string is input into a cryptographic hash function, for example, the Secure Hash Algorithm-256-bit version, SHA-256. The output of the hash function is the client cryptographic commitment, for example, a 32-byte hash value.

[0028] Subsequently, S23 is performed. The message combination module of the client sequentially combines the client ephemeral key public key and the client cryptographic commitment. This combination adopts an explicit structured format, for example, the two can be simply concatenated as byte strings, or encapsulated in a Type-Length-Value (TLV) encoding format to ensure that the server can correctly parse it. For example, a structure can be defined, which includes a field for storing the public key and another field for storing the cryptographic commitment. The final single data block is the first combined message content.

[0029] Next, S24 is performed. The signature module of the client uses its pre-configured client long-term identity private key, for example, a private key based on RSA digital signature algorithm or elliptic curve digital signature algorithm, to digitally sign the first combined message content. The process of signing includes two main steps: first, the client uses the same cryptographic hash function as in S22, for example, SHA-256, to calculate the hash value of the first combined message content. Second, the client uses its client long-term identity private key to encrypt the hash value or perform a signature operation. For example, if the RSA digital signature algorithm is used, the client uses its RSA private key to encrypt the hash value; if the elliptic curve digital signature algorithm (ECDSA) is used, the client performs the ECDSA signature algorithm, inputs its ECDSA private key and the message hash value. The generated output is the client digital signature.

[0030] Finally, S25 is performed. This is done by encapsulating both in a pre-defined communication protocol message structure, for example, a protocol data unit containing an explicit signature field and a content field. The protocol data unit can be a simple byte sequence, with the signature field in front and the message content field behind, or a more complex protocol header and payload structure. The complete message formed in the end is the first combined message.

[0031] In step S3, after receiving the first combined message and passing the validity verification, the server stores the client cryptographic commitment and initiates a feature commitment to the client through a second combined message after calculating the server cryptographic commitment of the server network and device features, wherein the second combined message includes the server cryptographic commitment. It should be understood that after receiving the feature commitment of the client, the server needs to respond in a reciprocal manner to establish mutual trust of the communication parties on each other's environment features. To this end, the present application stores the cryptographic commitment of the client, so that the server provides an unforgeable reference point for subsequent verification of the real network and device features disclosed by the client, ensuring the authenticity of the client environment information. At the same time, the server calculates and sends its own cryptographic commitment, ensuring the authenticity and non-repudiation of its own environment information, which is symmetrical with the commitment of the client, and organically integrates the dynamic features of the real-time device and network environment into the end-to-end encryption handshake process. This two-way commitment mechanism effectively solves the problem that the traditional authentication in the background art only relies on key identity and cannot confirm the trustworthiness of the device environment of the other party, lays a foundation for subsequent feature disclosure and verification, and thus improves the security of the overall communication.

[0032] In a possible implementation mode, after receiving the first combined message and the validity verification is passed, the service end stores the client cryptographic commitment and initiates the feature commitment to the client through the second combined message after calculating the service end network and device feature cryptographic commitment, the second combined message includes the service end cryptographic commitment, including: S31, verifying the validity of the client digital signature for the first combined message content using the client long-term identity public key; S32, after the validity verification is passed, storing the client cryptographic commitment and the client temporary key public key; S33, generating a service end temporary key pair, the service end temporary key pair includes a service end temporary key public key and a service end temporary key private key; S34, selecting a random number, and inputting the random number and the service end network and device feature into a hash function to obtain the service end cryptographic commitment; S35, combining the service end temporary key public key and the service end cryptographic commitment to obtain the second combined message content; S36, based on the service end long-term identity private key, the second combined message content is digitally signed to obtain the service end digital signature; S37, packing the service end digital signature and the second combined message content to obtain the second combined message; S38, based on the client temporary key public key and the service end temporary key private key, calculating the preliminary shared key.

[0033] The following is a specific implementation process of step S3: first, S31 is performed. After the service end receives the first combined message sent by the client, the message parsing module of the service end will first perform structured parsing on the message to extract the client digital signature and the first combined message content. The signature verification module of the service end will then use the pre-acquired client long-term identity public key to perform verification. The client long-term identity public key is obtained through pre-configuration, certificate authority (CA) trust chain verification or out-of-band manner. The verification process includes two main parts: first, the service end uses the same cryptographic hash function as the client when generating the signature, such as SHA-256, to calculate the hash value of the received first combined message content. Second, the service end uses the client long-term identity public key to decrypt or verify the received client digital signature. For example, if the RSA digital signature algorithm is used, the service end will use the client long-term identity public key to perform RSA decryption on the digital signature to obtain a hash value; if the elliptic curve digital signature algorithm (ECDSA) is used, the service end will perform the ECDSA verification algorithm, inputting the client long-term identity public key, the message hash value and the digital signature. Finally, the service end compares the hash value obtained by public key decryption or verification with the message content hash value calculated in the first step. If they match exactly, the digital signature is considered valid, indicating that the first combined message content was indeed sent by the legitimate client that owns the client long-term identity private key and has not been tampered with during transmission. If the verification fails, the service end will terminate the connection and report an error.

[0034] Next, S32 is performed. Once the digital signature verification is successful, the service end will accurately extract the client cryptographic commitment and the client temporary key public key from the verified first combined message content. These extracted data will be securely stored in the memory of the service end as context information for the current session. Storing the client cryptographic commitment is to verify the consistency between the features revealed by the client and its initial commitment in subsequent steps. Storing the client temporary key public key is to perform Diffie-Hellman key exchange with the service end's own temporary key private key to calculate the preliminary shared key. The storage of these data is temporary and limited to the lifetime of the current session.

[0035] Subsequently, S33 is performed. The key generation module of the service end will use a cryptographic secure pseudo-random number generator to generate a brand new service end temporary key pair based on pre-set elliptic curve cryptographic parameters, such as the secp256r1 curve negotiated or pre-set with the client. The key pair includes a service end temporary key public key and a service end temporary key private key. For example, the generated service end temporary key public key may be a 32-byte elliptic curve point representation, and the service end temporary key private key is a 32-byte random integer.

[0036] Next, S34 is performed. The commitment computing module of the server first selects a brand new random number from a cryptographically secure pseudo-random number generator, for example, a 32-byte random bit string, denoted as random number_server. This random number is secret and only held by the server. Then, the server concatenates this random number_server with the network and device features at the server. The concatenated data string is fed into a cryptographic hash function as input. The output of the hash function is the server cryptographic commitment, for example, a 32-byte hash value. This commitment value is a non-forgeable digest of the server's network and device features, and since it contains the random number, each commitment is unique and prevents pre-computation attacks on the features, while also ensuring the privacy of the feature information, as the commitment itself does not directly expose the original features.

[0037] Then, S35 is performed. The combining module of the server sequentially combines the server ephemeral key public key and the server cryptographic commitment. This combination adopts an explicit structured format, for example, it can simply concatenate the two as byte strings, or encapsulate them using the Type-Length-Value (TLV) encoding format to ensure that the client can correctly parse them. For example, a structure can be defined, which contains a field for storing the public key and another field for storing the cryptographic commitment. The final single data block formed by the second combined message content ensures that the ephemeral public key and the feature commitment are authenticated as a whole in subsequent signing.

[0038] After that, S36 is performed. The signing module of the server uses its pre-configured server long-term identity private key, for example, a private key based on RSA or ECDSA algorithm, to digitally sign the second combined message content. The signing process is similar to the operation of the client in S24: first, the server uses the same hash function as the client to calculate the hash value of the second combined message content. Then, the server uses its server long-term identity private key to perform encryption transformation or signature operation on the hash value, and the generated output is the server digital signature, providing integrity protection for the second combined message content and server identity authentication, proving that the message is indeed sent by the legitimate server that owns the long-term identity private key.

[0039] Next, S37 is performed. The packaging module of the server packages the server digital signature and the second combined message content. This is done by encapsulating the two in a pre-defined communication protocol message structure, for example, a protocol data unit containing an explicit signature field and a content field. This protocol data unit can be a simple byte sequence, with the signature field first and the message content field second, or a more complex protocol header and payload structure. The final complete message formed by the second combined message.

[0040] Finally, S38 is performed. The key calculation module of the server uses the client temporary key public key stored in S32 and the server temporary key private key generated in S33 to perform the Diffie-Hellman key exchange algorithm. The mathematical basis of this algorithm is the discrete logarithm problem, which allows the two parties of communication to jointly calculate a shared secret without directly exchanging the secret. Specifically, the server performs elliptic curve point multiplication operation on the client temporary key public key, for example, an elliptic curve point, and the server temporary key private key, for example, a random integer. The result of this operation is the preliminary shared key, for example, a 32-byte symmetric key. This preliminary shared key is the first shared secret established by the two parties in the current session, which will be used in the subsequent encryption disclosure process to ensure that the transmission of the feature information is confidential and is based on the result of the temporary key negotiation between the two parties, thereby providing a secure channel for the subsequent feature disclosure and verification.

[0041] In step S4, after receiving the second combined message and passing the validity verification, the client stores the server cryptographic commitment and constructs the client encryption disclosure information based on the client network and device features, and then sends it to the server. Accordingly, after the exchange of cryptographic commitments by the two parties of communication, the actual feature disclosure and verification phase needs to be entered to ensure the authenticity of the commitment. The client stores the server cryptographic commitment in order to be able to perform validity check on the server disclosure information received subsequently, thereby establishing trust in the server environment. More importantly, the client constructs the encryption disclosure information based on its own network and device features at this time and sends it to the server, which marks the beginning of the client's performance of the feature commitment made at the initial stage of the handshake. Through encryption disclosure, the confidentiality of these sensitive environmental features in the transmission process is ensured, preventing eavesdropping or tampering. This is the core link of realizing the organic binding of feature and key negotiation, enabling the server to verify the previous commitment of the client according to these encrypted real features, thereby building an end-to-end trust chain based on real-time environmental features.

[0042] In one possible implementation manner, Figure 4 The flowchart of step S4 in the end-to-end encryption authentication method based on network and device features according to the embodiment of the present application is shown in FIG. 4. As shown in FIG. 4, the client receives the second combined message from the server, and then performs validity verification on the second combined message. If the validity verification fails, the client will not send the encryption disclosure information to the server. If the validity verification passes, the client will send the encryption disclosure information to the server. Figure 4As shown, after receiving the second combined message and passing the validity verification, the client stores the server cryptographic commitment and sends the client encrypted reveal information to the server based on the client network and device features, including: S41, verifying the validity of the server digital signature with respect to the second combined message content using the server long-term identity public key; S42, after passing the validity verification, storing the server temporary key public key and the server cryptographic commitment; S43, calculating the preliminary shared key based on the server temporary key public key and the client temporary key private key; S44, constructing the to-be-revealed information based on the client network and device features, and encrypting the to-be-revealed information using the preliminary shared key to obtain the client encrypted reveal information.

[0043] The following is a specific implementation process of step S4: first, S41 is performed. After the client receives the second combined message sent by the server, the message parsing module of the client will first perform structural parsing on the message to extract the server digital signature and the second combined message content. The signature verification module of the client will then use the pre-acquired server long-term identity public key to perform verification. The server long-term identity public key is obtained through pre-configuration, certificate authority (CA) trust chain verification or out-of-band manner. The verification process includes two main parts: first, the client calculates the hash value of the received second combined message content using the same cryptographic hash function as the server when generating the signature. Second, the client decrypts or verifies the received server digital signature using the server long-term identity public key. For example, if the RSA digital signature algorithm is used, the client will use the server long-term identity public key to perform RSA decryption on the digital signature to obtain a hash value; if the elliptic curve digital signature algorithm (ECDSA) is used, the client will perform the ECDSA verification algorithm, inputting the server long-term identity public key, the message hash value and the digital signature. Finally, the client compares the hash value obtained by public key decryption or verification with the message content hash value calculated in the first step. If they match exactly, the digital signature is considered valid, indicating that the second combined message content was indeed sent by the legitimate server that owns the server long-term identity private key, and that it has not been tampered with during transmission. If the verification fails, the client will terminate the connection and report an error.

[0044] Next, S42 is performed. After the digital signature verification is successful, the client extracts the server temporary key public key and the server cryptographic commitment from the verified second combined message content. These extracted data are securely stored in the memory of the client as context information for the current session.

[0045] Subsequently, S43 is performed. The key computation module of the client uses the stored server ephemeral key public key and the client ephemeral key private key to perform a Diffie-Hellman key exchange algorithm. The mathematical basis of this algorithm is the discrete logarithm problem, which allows the two parties of communication to jointly compute a shared secret without directly exchanging the secret. Specifically, the client performs an elliptic curve point multiplication operation on the server ephemeral key public key, for example, an elliptic curve point, and the client ephemeral key private key, for example, a random integer. The result of this operation is a preliminary shared key, for example, a 32-byte symmetric key. This preliminary shared key is the first shared secret established by the two parties in the current session.

[0046] Finally, S44 is performed. The reveal information construction module of the client first concatenates the client network and device features with the random number_client selected in S22 to form the to-be-revealed information. This random number_client is a key component of the client cryptographic commitment, and it is included in the to-be-revealed information so that the server can recompute the hash value after receiving it and compare it with the client cryptographic commitment received earlier to verify the authenticity of the commitment. Subsequently, the encryption module of the client uses the preliminary shared key calculated in S43 to symmetrically encrypt the to-be-revealed information. The encryption algorithm can use the Galois / Counter Mode (GCM) of the Advanced Encryption Standard (AES), for example, AES-256-GCM, which provides data confidentiality, integrity, and authentication. The encryption process generates client encrypted reveal information, as well as an authentication tag and an initialization vector (IV).

[0047] In step S5, after receiving the client encrypted reveal information, the server obtains the revealed client network and device features from the client encrypted reveal information, verifies the client cryptographic commitment based on the revealed client network and device features, and after successful verification, constructs server encrypted reveal information based on the server network and device features and sends it to the client. It should be understood that after receiving the client encrypted reveal information, the primary task of the server is to decrypt to obtain the real network and device features of the client. Subsequently, the server compares and verifies these revealed features with the previously stored client cryptographic commitment. This verification process is crucial, as it ensures that the environmental features promised by the client at the initial stage of the handshake are consistent with the current actual revealed features, thereby confirming the authenticity and integrity of the client's communication environment. Only after the client's feature commitment is successfully verified, does the server construct encrypted reveal information based on its own network and device features and send it to the client to complete the two-way feature authentication. This effectively solves the problem in the background art that traditional authentication cannot inherently bind real-time environmental features with session keys, significantly improving the overall security of end-to-end communication.

[0048] In one possible implementation method Figure 5 This is a flowchart of step S5 in the end-to-end encrypted authentication method based on network and device characteristics according to an embodiment of this application. Figure 5 As shown, in step S5, after receiving the client's encrypted disclosure information, the server obtains the client's network and device characteristics from the client's encrypted disclosure information, verifies the client's cryptographic commitment based on the client's network and device characteristics, and after successful verification, constructs server-side encrypted disclosure information based on the server's network and device characteristics and sends it to the client, including: S51, decrypting the client's encrypted disclosure information based on the preliminary shared key to obtain the client's network and device characteristics and the disclosure random number; S52, verifying the client's cryptographic commitment based on the client's network and device characteristics and the disclosure random number; S53, after successful verification, constructing information to be disclosed based on the server's network and device characteristics and the server's corresponding random number; S54, encrypting the information to be disclosed using the preliminary shared key to obtain server-side encrypted disclosure information.

[0049] The following is a specific implementation process of step S5: First, proceed to S51. After receiving the client-encrypted reveal information sent by the client, the server's decryption module uses the preliminary shared key calculated in S38 to symmetrically decrypt the encrypted information. For example, if the client used Galois / Counter Mode (GCM) of Advanced Encryption Standard (AES) for encryption in S44, the server will use the same AES-GCM algorithm, using the preliminary shared key as the symmetric key, and combining the initialization vector (IV) and authentication tag used during encryption for decryption and integrity verification. After successful decryption, the server will obtain the original reveal information. This reveal information is a concatenated data string containing the random number_client selected by the client in S22 and the client's network and device characteristics collected in S1. The server's parsing module will further parse this decrypted data string, separating the reveal client's network and device characteristics, i.e., the client's real, unencrypted network and device characteristics, and the reveal random number, i.e., the random number_client used by the client in S22. If decryption or integrity verification fails, the server will terminate the connection and report an error, as this may mean that the data has been tampered with during transmission or that the key does not match.

[0050] Next, S52 is performed. The commitment verification module of the server uses the revealed client network and device features and the revealed random number to re-compute a hash value. Specifically, the server concatenates the revealed random number with the revealed client network and device features to form a data string that is identical to the one used by the client to compute the commitment in S22. Then, the server computes a hash value of this newly constructed data string using the same cryptographic hash function (e.g., SHA-256) as the client did in S22. This newly computed hash value is compared exactly with the client cryptographic commitment stored by the server in S32. If the two hash values are identical, it means that the revealed true network and device features of the client match exactly with the features it committed at the beginning of the handshake, and the client indeed possesses the secret random number used to generate the commitment. This successfully verifies the authenticity of the features of the client and confirms the binding of its identity and environment. If the comparison is not identical, the verification fails, and the server will terminate the connection, as it can mean that the features of the client have changed or there is fraudulent behavior.

[0051] Subsequently, S53. After the client commitment verification is successful, the server begins to prepare to reveal its true features to the client. The reveal information construction module of the server uses the server network and device features collected in S1 and the random number_server, i.e., random number, selected in S34. The server concatenates this random number with the server network and device features to form a single data string, i.e., the to-be-revealed information. This to-be-revealed information contains the true, unencrypted network and device feature data of the server and the secret random number used for subsequent client verification of the server commitment.

[0052] Finally, S54 is performed. The encryption module of the server uses the preliminary shared key computed in S38 to symmetrically encrypt the to-be-revealed information constructed in S53. The encryption algorithm can use the Galois / Counter Mode (GCM) of the Advanced Encryption Standard (AES), e.g., AES-256-GCM, which provides data confidentiality, integrity, and authentication. The encryption process generates server encrypted reveal information, as well as an authentication tag and an initialization vector (IV). These encrypted data are then sent to the client. By using the preliminary shared key for encryption, the confidentiality and integrity of the feature information revealed by the server during transmission are ensured, and only the client with the same preliminary shared key can decrypt and verify these information, thereby completing the two-way, secure feature revelation process.

[0053] In step S6, after receiving the server encryption revelation information, the client obtains the revealed server network and device features from the server encryption revelation information, and verifies the server cryptographic commitment based on the revealed server network and device features. It can be understood that after receiving the server encryption revelation information, the client needs to decrypt it to obtain the real and current network and device features of the server. Then, the client strictly compares and verifies the revealed server features with the previously stored server cryptographic commitment. This verification process is crucial, as it ensures that the environment feature commitment made by the server at the initial stage of the handshake is completely consistent with the current actual revealed features, thereby establishing the client's trust in the server's communication environment. Only by passing this step can the real-time device and network environment of both parties be finally confirmed to meet their respective commitments, thereby tightly binding these dynamic features with the subsequently established end-to-end encryption session key, effectively addressing the security risks of communicating in unauthorized environments mentioned in the background technology, and building a more resilient secure channel.

[0054] In one possible implementation, step S6, after receiving the server encryption revelation information, the client obtains the revealed server network and device features from the server encryption revelation information, and verifies the server cryptographic commitment based on the revealed server network and device features, including: S61, decrypting the server encryption revelation information based on the preliminary shared key to obtain the revealed server network and device features and the revealed random number; S62, verifying the server cryptographic commitment based on the revealed server network and device features and the revealed random number.

[0055] The following is a specific implementation process of step S6: first, S61 is performed. After the client receives the server-encrypted disclosure information sent by the server, its decryption module will use the preliminary shared key calculated in S43 to perform symmetric decryption on the encrypted information. For example, if the server uses the Galois / Counter Mode (GCM) of the Advanced Encryption Standard (AES) for encryption in S54, the client will use the same AES-GCM algorithm, using the preliminary shared key as the symmetric key, and combining the initialization vector (IV) and authentication tag used during encryption to perform decryption and integrity verification. After successful decryption, the client will obtain the original disclosure information. This disclosure information is a spliced data string that contains the random number_server selected by the server in S34 and the server network and device features collected in S1. The parsing module of the client will further parse this decrypted data string to separate out the disclosed server network and device features, i.e., the server's real, unencrypted network and device features, and the disclosed random number, i.e., the random number_server used by the server in S34. If decryption or integrity verification fails, the client will terminate the connection and report an error, as this may mean that the data was tampered with during transmission or that the key does not match.

[0056] Next, S62 is performed. The commitment verification module of the client will use the disclosed server network and device features and the disclosed random number obtained by decryption in S61 to recalculate a hash value. Specifically, the client will splice the disclosed random number with the disclosed server network and device features to form a data string that is exactly the same as the commitment calculated by the server in S34. Then, the client will use the same cryptographic hash function as the server in S34 to calculate the hash value of this newly constructed data string. This newly calculated hash value will be exactly compared with the server's cryptographic commitment stored by the client in S42. If the two hash values are exactly the same, it means that the real network and device features disclosed by the server match exactly with the features it promised at the beginning of the handshake, and the server indeed possesses the secret random number that generates the commitment. This successfully verifies the authenticity of the server's features and confirms the binding of its identity and environment. If the comparison is inconsistent, the verification fails, and the client will terminate the connection, as this may mean that the server's features have changed or there is fraudulent behavior. At this point, the client has completed double verification of the server's identity and environmental features, and the entire network and device feature-based end-to-end encryption authentication process is declared successful, and the two parties can communicate securely based on the established trust relationship and shared key.

[0057] In particular, in actual applications, in order to achieve fault tolerance, the consistency probability higher than the predetermined threshold is taken as a verification pass in the process of verifying the client cryptographic commitment by the server and then verifying the server cryptographic commitment by the client. Therefore, assuming that the consistency probability when the server verifies the client cryptographic commitment is p1, and the consistency probability when the client verifies the server cryptographic commitment is p2, there is obviously a probability generalization judgment relationship of causal probability distribution between p2 and p1, that is, there is a commitment event between the server verification and the client verification. In particular, p1 and p2 are a statistical description of a large amount of historical data or system expectations, or are obtained in a more complex model based on causal inference. For example, the system records the success rate of the client cryptographic commitment verification in the S52 step when the server handles a large number of client connections in the past. For example, among 10,000 connections, 9,950 client commitment verifications are successful, and p1 can be set to 0.995. Similarly, the system records the success rate of the server cryptographic commitment verification in the S62 step when the client handles a large number of server responses in the past. For example, among 10,000 connections, 9,900 server commitment verifications are successful, and p2 can be set to 0.990. That is, the original S52 and S62 steps are deterministic results (match or mismatch) of single verification of the hash value. And p1 and p2 are statistical probabilities representing the possibility of successful verification of such hash verification under a large number or specific conditions. That is, this embodiment performs higher-level evaluation and decision optimization on the result of hash verification or the success rate or consistency of hash verification.

[0058] Based on this, in an optimized embodiment, the consistency probability when verifying is balanced based on causal probability distribution in the process of verifying the client cryptographic commitment by the server and verifying the server cryptographic commitment by the client, comprising:

[0059] First, the server-client verification consistency probability and the client-server verification consistency probability are calculated to obtain a causal probability offset value. In order to reflect the causal chain probability of the commitment event, first set p1 > p2, then the causal probability judgment is:

[0060]

[0061] Where p1 is the server-client verification consistency probability, p2 is the client-server verification consistency probability, and p is the causal probability offset value. θis a causal probability offset value, that is, the determination probability of the center offset of the consistent-based causal probability distribution is embodied by the determination of the significant offset between the causal probabilities;

[0062] reconstruct the probability determination based on the causal information space to obtain a causal probability reconstruction offset value, that is, further have a causal probability dynamic information generalization representation, to reconstruct the probability determination by constructing the causal information space, to embody the verification information balance in the causal probability distribution space:

[0063] p ∈ =-log2p θ

[0064] wherein, p ∈ is the causal probability reconstruction offset value, and log2 is the logarithm function value with base 2;

[0065] Based on the causal probability reconstruction offset value, the server-client verification consistency probability and the client-server verification consistency probability are balanced in causal probability to obtain the server-client verification consistency causal balance probability and the client-server verification consistency causal balance probability, that is, the probability distribution dynamic balance based on priori-posteriori in the causal probability distribution space is embodied, that is:

[0066]

[0067] wherein, p ' 1 is the server-client verification consistency causal balance probability, and p ' 2 is the client-server verification consistency causal balance probability;

[0068] Based on the server-client verification consistency causal balance probability and the client-server verification consistency causal balance probability, the client cryptography commitment and the server cryptography commitment are verified respectively. In this way, the commitment verification strategy with causal relationship based on consistent probability can be converted into information generalization balance reconstruction in the causal probability distribution space, thereby constructing the causal probability distribution inference relationship between the server verification and the client verification in the commitment event, and improving the accuracy of commitment verification based on the predetermined server-client interaction process. It is worth mentioning that the verification here refers to making a final trust decision based on these balance probabilities. For example, the system can set a threshold: if the balanced p ' 1 or p '2Below a certain preset trust threshold, e.g. 0.95, even if the current hash check passes, the system can consider the trustworthiness of the connection insufficient, thus triggering additional security measures (such as requiring re-authentication, limiting session functionality, issuing a security warning, logging an exception, etc.) instead of directly establishing a fully trusted session. This makes the verification process more resilient, able to handle cases where the hash check technically passes, but there is an anomaly from a probabilistic perspective.

[0069] In summary, the network and device feature based end-to-end encryption authentication method based on the embodiments of the present application is illustrated, which solves the problem of separation of feature verification and key binding in the traditional scheme by endogenously integrating the verification process of network and device features into the key agreement protocol of end-to-end encryption. Specifically, the communication parties (client and server) first collect their own network and device features and calculate their cryptographic commitments. These commitments are exchanged through a combined message at the beginning of the handshake. Subsequently, based on the preliminary shared key, both parties encrypt and reveal their real feature information. The receiving party then verifies the cryptographic commitment of the other party based on the revealed feature information. In this way, it is ensured that the establishment of the session key is closely bound to the real-time network and device features of the communication parties. Only when the feature commitments of both parties are consistent with the revealed information and pass the verification, the entire authentication process is considered successful, thus effectively preventing attackers from communicating in non-expected environments using a legitimate identity, significantly improving the security and reliability of authentication.

[0070] The above has described various embodiments of the present disclosure, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those skilled in the art without departing from the scope and spirit of the described embodiments. The choice of terms used herein is intended to best explain the principles, practical applications, or improvements to the technology in the market of the embodiments, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

1. A network and device feature based end-to-end encryption authentication method, characterized by, The method comprises: The client and the server respectively collect their own network and device features to obtain client network and device features and server network and device features; After the client calculates a client cryptographic commitment of the client network and device features, the client initiates a handshake and feature commitment to the server through a first combined message, wherein the first combined message comprises the client cryptographic commitment; After receiving the first combined message and passing the validity verification, the server stores the client cryptographic commitment and initiates a feature commitment to the client through a second combined message after calculating a server cryptographic commitment of the server network and device features, wherein the second combined message comprises the server cryptographic commitment; After receiving the second combined message and passing the validity verification, the client stores the server cryptographic commitment and sends client encrypted revelation information to the server after constructing the client encrypted revelation information based on the client network and device features; After receiving the client encrypted revelation information, the server obtains revealed client network and device features from the client encrypted revelation information, verifies the client cryptographic commitment based on the revealed client network and device features, and sends server encrypted revelation information to the client after constructing the server encrypted revelation information based on the server network and device features; After receiving the server encrypted revelation information, the client obtains revealed server network and device features from the server encrypted revelation information and verifies the server cryptographic commitment based on the revealed server network and device features. 2.The network and device feature based end-to-end encryption authentication method of claim 1, wherein, The client network and device features comprise operating system information, hardware information, network interface information, software and application information, and user and session information; and the server network and device features comprise operating system information, hardware information, network interface information, software and service information, and certificate information. 3.The network and device feature based end-to-end encryption authentication method of claim 1, wherein, After the client calculates a client cryptographic commitment of the client network and device features, the client initiates a handshake and feature commitment to the server through a first combined message, wherein the first combined message comprises the client cryptographic commitment, comprising: Generating a client temporary key pair, wherein the client temporary key pair comprises a client temporary key public key and a client temporary key private key; Selecting a random number and inputting the random number and the client network and device features into a hash function to obtain the client cryptographic commitment; Combining the client temporary key public key and the client cryptographic commitment to obtain first combined message content; Digitally signing the first combined message content based on a client long-term identity private key to obtain a client digital signature; Packing the client digital signature and the first combined message content to obtain the first combined message. 4.The network and device feature based end-to-end encryption authentication method of claim 3, wherein, After receiving the first combined message and passing the validity verification, the server stores the client cryptographic commitment and initiates a feature commitment to the client through a second combined message after calculating a server cryptographic commitment of the server network and device features, wherein the second combined message comprises the server cryptographic commitment, comprising: validating the client digital signature using the client long-term identity public key for the first combined message content; storing the client cryptographic commitment and the client ephemeral key public key upon successful validation; generating a server ephemeral key pair, the server ephemeral key pair comprising a server ephemeral key public key and a server ephemeral key private key; selecting a random number and inputting the random number and the server network and device features into a hash function to obtain the server cryptographic commitment; combining the server ephemeral key public key and the server cryptographic commitment to obtain a second combined message content; digitally signing the second combined message content based on a server long-term identity private key to obtain a server digital signature; packaging the server digital signature and the second combined message content to obtain the second combined message; computing a preliminary shared key based on the client ephemeral key public key and the server ephemeral key private key. 5.The network and device feature based end-to-end encryption authentication method of claim 4, wherein, Upon receiving the second combined message and upon successful validation, the client stores the server cryptographic commitment and sends to the server a client encrypted revelation information based on the client network and device features, comprising: validating the server digital signature using the server long-term identity public key for the second combined message content; storing the server ephemeral key public key and the server cryptographic commitment upon successful validation; computing a preliminary shared key based on the server ephemeral key public key and the client ephemeral key private key; constructing a to-be-revealed information based on the client network and device features and encrypting the to-be-revealed information using the preliminary shared key to obtain the client encrypted revelation information. 6.The network and device feature based end-to-end encryption authentication method of claim 5, wherein, Upon receiving the client encrypted revelation information, the server obtains a revealed client network and device features from the client encrypted revelation information and verifies the client cryptographic commitment based on the revealed client network and device features, and sends to the client a server encrypted revelation information based on the server network and device features upon successful verification, comprising: decrypting the client encrypted revelation information using the preliminary shared key to obtain a revealed client network and device features and a revealed random number; verifying the client cryptographic commitment based on the revealed client network and device features and the revealed random number; upon successful verification, constructing a to-be-revealed information based on the server network and device features and the server corresponding random number; encrypting the to-be-revealed information using the preliminary shared key to obtain the server encrypted revelation information. 7.The network and device feature based end-to-end encryption authentication method of claim 6, wherein, Upon receiving the server encrypted revelation information, the client obtains a revealed server network and device features from the server encrypted revelation information and verifies the server cryptographic commitment based on the revealed server network and device features, comprising: decrypting the server encrypted revelation information using the preliminary shared key to obtain a revealed server network and device features and a revealed random number; Based on the revealed server network and device features and the revealed random number, the server cryptographic commitment is checked. 8.The network and device feature based end-to-end encryption authentication method of claim 7, wherein, Also included are: In the process of verifying the client cryptographic commitment at the server and the server cryptographic commitment at the client, the consistency probability at the time of verification is balanced based on a causal probability distribution, including: Causal probability offset calculation is performed on the server-client verification consistency probability and the client-server verification consistency probability to obtain a causal probability offset value; The causal probability offset value is reconstructed based on a causal information space to obtain a causal probability reconstruction offset value; Based on the causal probability reconstruction offset value, the server-client verification consistency probability and the client-server verification consistency probability are balanced in terms of causal probability to obtain a server-client verification consistency causal balance probability and a client-server verification consistency causal balance probability; Based on the server-client verification consistency causal balance probability and the client-server verification consistency causal balance probability, the client cryptographic commitment and the server cryptographic commitment are verified respectively.

Images