Two-way authentication communication security connection system and authentication method

Abstract

The application discloses a two-way authentication communication security connection system and an authentication method, and relates to the technical field of communication security connection systems.The system comprises a client and a device end.The client is configured with a client digital certificate generated by signing a root private key, and the client digital certificate contains a client public key.The client determines a target device, obtains a device end public key of the target device, sends a connection request and the client digital certificate to the target device, receives a random number ciphertext sent back by the device end, decrypts the random number by using the client private key, encrypts the digest of the random number by using the device end public key, and sends the encrypted digest back.The device end receives the connection request, first verifies the client digital certificate by using the root public key, generates a random number after verification, encrypts the random number by using the extracted client public key, and sends the encrypted random number to the client, finally decrypts the ciphertext sent back by the client to obtain a digest, and compares the digest with the digest of the random number generated by the device end to complete two-way authentication.The application realizes two-way authentication with high security, and effectively prevents denial of service attacks and man-in-the-middle attacks.

Description

Technical Field

[0001] This invention belongs to the field of wireless communication security technology, specifically relating to a two-way authentication secure communication connection system and authentication method. Background Technology

[0002] Currently, mainstream Bluetooth devices (especially BLE devices) typically use standard pairing protocols to establish connections, such as PIN code (Personal Identification Number) pairing or temporary key exchange (Just Works, Passkey Entry, etc.). These traditional methods have the following significant drawbacks:

[0003] Weak authentication mechanism: Traditional pairing process lacks strong authentication based on client digital certificates, allowing attackers to impersonate legitimate clients and initiate connections;

[0004] One-way authentication is the most common: Most systems only verify the device's identity to the client, and the client cannot confirm the device's identity, making it vulnerable to attacks by spoofed devices;

[0005] Vulnerable key management: Pairing keys are often temporarily generated or simply pre-set, making them easy to intercept or crack;

[0006] Lack of end-to-end encryption: Command transmission lacks application-layer encryption and integrity protection, posing a risk of data leakage and tampering.

[0007] Existing technologies are no longer sufficient to meet the needs of device control scenarios with high security requirements, and there is an urgent need for a secure connection solution with strong identity authentication, two-way verification and end-to-end encryption. Summary of the Invention

[0008] The technical objective of this invention is to address the lack of secure connection solutions with strong authentication, two-way verification, and end-to-end encryption in existing technologies by providing a two-way authentication secure connection system and method.

[0009] To achieve the above-mentioned technical objectives, the present invention adopts the following technical solution.

[0010] In a first aspect, embodiments of the present invention provide a secure communication connection system with two-way authentication, comprising:

[0011] The client is configured with a client digital certificate generated by signing with the root private key and a client asymmetric key pair, wherein the client asymmetric key pair includes a client public key and a client private key, and the client digital certificate contains the client public key; the client is used to determine a target device, obtain the device-side public key of the target device; initiate a connection request to the target device and send the client digital certificate; and is also used to receive a random number ciphertext sent back by the target device, decrypt it using its own client private key to obtain a random number, encrypt the digest of the random number using the device-side public key, and send the obtained encrypted digest back to the device.

[0012] On the device side, a root public key and a device-side asymmetric key pair are configured. The device-side asymmetric key pair includes a device-side public key and a device-side private key. Upon receiving a connection request, the device first uses the root public key to verify the legitimacy of the client's digital certificate. After successful verification, it triggers the generation of a random number and encrypts the random number using the client's public key extracted from the client's digital certificate. The device then sends the encrypted random number to the client. Finally, it uses its own device-side private key to decrypt the encrypted digest returned by the client to obtain a digest of the random number. This digest is then compared with the digest generated by the device for the random number to complete two-way authentication.

[0013] Furthermore, the system also includes a key management system for issuing client digital certificates to legitimate clients using a root private key.

[0014] Secondly, embodiments of the present invention provide a device-side two-way authentication method for secure communication connections. The device-side two-way authentication method is applied to a device, which is configured with a root public key and a device-side asymmetric key pair. The device-side asymmetric key pair includes a device-side public key and a device-side private key. The method includes:

[0015] Receive connection requests and client digital certificates initiated by the client;

[0016] The root public key is used to verify the legitimacy of the client's digital certificate.

[0017] After the signature verification is successful, a random number is generated. The random number is then encrypted using the client public key extracted from the client's digital certificate. The resulting ciphertext of the random number is sent to the client, which then uses its own client private key to decrypt the ciphertext of the random number to obtain the random number. The client then uses a pre-obtained device public key to encrypt the digest of the random number and sends the encrypted digest back.

[0018] The device receives the encrypted digest sent back by the client and decrypts it using its own device-side private key to obtain a digest of the random number. This digest is then compared with the digest generated by the device itself for the random number, thereby completing two-way authentication.

[0019] Furthermore, before receiving the connection request initiated by the client and the client's digital certificate, the method further includes: during the device manufacturing stage, generating the device-side private key and the device-side public key within the security chip on the device side, wherein the device-side private key is restricted to operation within the security chip and cannot be exported.

[0020] Furthermore, the method also includes: the device starts a timer while sending the random number ciphertext; if two-way authentication is not completed within a preset valid window period, the random number is automatically determined to have expired and discarded.

[0021] Furthermore, the method also includes: after determining that the two-way authentication is successful, both the device and the client negotiate and generate a session key based on the random number through a key derivation function;

[0022] The system receives a ciphertext data packet of instructions generated using its own session key from the client, decrypts it using the local session key, and restores the instruction data, timestamp, communication sequence number, and first instruction digest value; it also verifies whether the deviation between the timestamp and its current time is within a preset time window.

[0023] Verify whether the communication sequence number is unique in the usage history within a preset time period;

[0024] The second instruction digest value is recalculated based on the decrypted instruction data, timestamp, and communication sequence number, and the second instruction digest value is compared with the first instruction digest value to see if they are consistent.

[0025] The instruction data will only be executed if the timestamp verification, serial number verification, and instruction digest value comparison all pass; if any verification fails, the device will discard the instruction data.

[0026] Thirdly, embodiments of the present invention provide a client-side two-way authentication method for secure communication connections. The client-side two-way authentication method is applied to a client configured with a client digital certificate generated by signing a root private key, and the client digital certificate contains a client public key. The method includes the following steps:

[0027] Identify the target device and obtain the device-side public key of the target device;

[0028] A connection request is initiated to the target device and the client digital certificate is sent so that the target device can use its internally pre-installed root public key to verify the certificate signature.

[0029] The system receives a random number ciphertext sent back by the target device after the certificate verification is successful. The random number ciphertext is generated by the target device encrypting the random number using the client public key extracted from the client digital certificate.

[0030] The random number is obtained by decrypting the ciphertext using the client's own private key.

[0031] The device uses its public key to encrypt the digest of the random number, and sends the encrypted digest back to the target device. The target device then uses its private key to decrypt the encrypted digest to obtain the digest of the random number, and compares it with its own digest generated for the random number to complete two-way authentication.

[0032] Furthermore, the method also includes: after determining that the two-way authentication is successful, both the device and the client negotiate and generate a session key based on the random number through a key derivation function;

[0033] The system encrypts and generates a ciphertext data packet using its own generated session key and sends it to the target device. The target device then decrypts the packet using its local session key to recover the instruction data, timestamp, communication sequence number, and a first instruction digest value. The system then verifies whether the deviation between the timestamp and its current time is within a preset time window; verifies whether the communication sequence number is unique within a preset time period's usage history; recalculates a second instruction digest value based on the decrypted instruction data, timestamp, and communication sequence number, and compares the second instruction digest value with the first instruction digest value; the instruction data is executed only if the timestamp verification, sequence number verification, and instruction digest value comparison all pass; if any verification fails, the device discards the instruction data.

[0034] Furthermore, the method also includes obtaining the unique identifier of the target device; after the session key negotiation is successful, caching the current session key, communication sequence number and session identifier, and setting the session validity period, wherein the session identifier is generated by both the client and the device based on the random number and the unique identifier;

[0035] When the communication link is unexpectedly disconnected and reconnected, the client sends a fast reconnection request and the session identifier to the device.

[0036] If the device verifies that the session identifier exists and has not expired, and the device retrieves the session key and communication sequence number bound to the session identifier, then both parties skip the asymmetric encryption two-way authentication process, directly resume encrypted communication, and synchronously use the next communication sequence number; otherwise, the two-way authentication process is initiated.

[0037] Furthermore, the client digital certificate also includes the application identity information, which includes at least the package name and application version number of the client application;

[0038] When the device verifies the signature of the client's digital certificate using the root public key, it also verifies the validity of the package name and version number to ensure that the client application is a preset officially authorized version.

[0039] Compared with existing technologies, the two-way authentication secure connection system and authentication method provided by this invention have the following beneficial technical effects: This invention significantly improves the connection robustness and user experience of IoT devices in mobile scenarios without reducing security levels, reflecting the optimized design of this solution for practical application environments. Firstly, verifying the client's digital certificate establishes a mandatory and unique trust starting point for the entire session. Only clients confirmed as legitimate are allowed to engage in subsequent interactions that may consume device resources, emphasizing the priority of "verifying the identity of the visitor." If device authentication is performed first (i.e., the device sends an encrypted random number R1 first), attackers can exhaust the limited computing and storage resources of IoT devices by forging a massive number of connection requests. This solution's sequential approach effectively filters out all unauthorized requests, protecting resources. In this invention, the device's public key (PK_Device) and random number (R1) are only used after the client's legitimacy is confirmed, avoiding premature exposure of this sensitive information on unverified channels.

[0040] It should be understood that the summary section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0041] The accompanying drawings described herein are for illustrative purposes only and are not intended to limit the scope of this application in any way. In the drawings:

[0042] Figure 1 A schematic diagram of the framework structure of a two-way authenticated secure communication connection system provided for an embodiment;

[0043] Figure 2 A flowchart illustrating the process of pre-setting a key in a two-way authentication secure communication connection system provided for an embodiment;

[0044] Figure 3 This is a schematic diagram of the client two-way authentication method for secure communication connections in the embodiment;

[0045] Figure 4 This is a schematic diagram of the device-side two-way authentication method for secure communication connections in the embodiment.

[0046] Figure 5 This is a schematic diagram of the sending end process in the embodiment;

[0047] Figure 6 This is a schematic diagram of the receiving end process in the embodiment. Detailed Implementation

[0048] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0049] A two-way authentication secure communication connection system includes a key management system, a client, and a device.

[0050] The client is configured with a client digital certificate generated by signing with the root private key and a client asymmetric key pair. The client asymmetric key pair includes the client public key and the client private key, and the client digital certificate contains the client public key. The client is used to identify the target device, obtain the target device's device-side public key, initiate a connection request to the target device and send the client digital certificate, and also to receive the random number ciphertext sent back by the target device, decrypt it using its own client private key to obtain the random number, encrypt the digest of the random number using the device-side public key, and send the obtained encrypted digest back to the device.

[0051] On the device side, a root public key and a device-side asymmetric key pair are configured. The device-side asymmetric key pair includes a device-side public key and a device-side private key. After receiving a connection request, the device first uses the root public key to verify the legitimacy of the client's digital certificate. After successful verification, it triggers the generation of a random number and encrypts the random number using the client's public key extracted from the client's digital certificate. The encrypted random number is then sent to the client. Finally, the device uses its own device-side private key to decrypt the encrypted digest sent back by the client to obtain the digest of the random number. This digest is then compared with the digest generated by the device for the random number to complete two-way authentication.

[0052] In some embodiments, such as Figure 1 As shown, the system also includes a key management system for issuing client digital certificates to legitimate clients using the root private key.

[0053] In some embodiments, keys can be pre-configured on both the client and device sides. As an example, a schematic diagram of the key pre-configuration process is shown below. Figure 2As shown, during this stage of device production, the key generation function of the internal security chip on the device / client side is invoked. As an example, a globally unique asymmetric key pair (device-side private key SK_Device, device-side public key PK_Device) is generated within the security chip on the device side, for instance, generating a pair of asymmetric keys based on ECC-256 elliptic curves. Security chips such as SE (Secure Element) or TEE (Trusted Execution Environment) are used.

[0054] In this embodiment, the device-side private key SK_Device and the client-side private key SK_Client are permanently locked in the chip's anti-readout secure area, while the device-side public key PK_Device and the client-side public key PK_Client can be read. The private keys are permanently locked within the chip, eliminating the possibility of obtaining them from external sources.

[0055] In some embodiments, a unique identifier for the device is also generated, such as a product serial number (SN) or an encrypted serial number. The device's public key PK_Device can be bound to this unique identifier, and this binding relationship (e.g., {SN, PK_Device}) can be securely uploaded and stored in a trusted database on the device management server for record-keeping. A key management system can be deployed on the device management server.

[0056] In other embodiments, the key management system can uniformly generate device-side public keys, device-side private keys, client-side public keys, and client-side private keys in a secure environment (such as an offline encryption machine), and store the device-side public keys locally in association with the device's unique identifier. During production, the device-side private and public keys are injected into the device's security chip via a production line secure channel (such as an encrypted JTAG / SWD interface or a dedicated programming tool), and the client-side private and public keys are injected into the client-side security chip via the same channel. After writing, the production line key management system destroys the local copy of the private key, retaining only the binding relationship between the device-side public key and the unique identifier, and the client-side public key. This method facilitates unified management and auditing of the device key generation and distribution process.

[0057] In some embodiments, a key management system issues a client digital certificate for each legitimate client. This certificate contains the client's public key PK_Client and is signed using the root private key. The client digital certificate may be pre-installed in the distribution package of the client application (APP).

[0058] As an example, the key management system uses the root private key PK_Root (which can be pre-installed in the client application APP) to issue an X.509 v3 format client digital certificate for the official client application (application package name: com.company.app). The client digital certificate mainly includes: application package name, validity period, and client public key PK_Client (also an ECC-256 public key). The entire client digital certificate content is signed with the root private key.

[0059] In some embodiments, the root public key PK_Root and the aforementioned signed client digital certificate can be compiled together into the installation package of the client application APP. The client private key SK_Client is generated and securely stored in the mobile client's secure environment (such as the keystore / key management module KeyStore, or the secure enclave) when the APP is first installed.

[0060] In some embodiments, the client digital certificate also includes application identity information of the application, such as the application's (APP) release package name and version number, for verifying the client.

[0061] Please combine Figure 1 As shown in the embodiment, the two-way authentication process of the two-way authentication secure communication connection system includes:

[0062] 1.1: The client initiates the device discovery process, scans for nearby devices (such as Bluetooth devices, but not limited to this communication method), and filters out target devices based on preset device characteristics (such as names containing the prefix "ExoBrace-") or product serial numbers, and obtains the target device's device public key PK_Device.

[0063] 1.2: The client initiates a connection request to the selected target device and simultaneously sends its pre-installed client digital certificate.

[0064] 1.3: After receiving the connection request and the client's digital certificate, the device verifies the signature of the client's digital certificate using its own pre-configured root public key PK_Root. If the verification fails, it indicates that the client's identity is illegitimate, and the device immediately refuses the connection and may issue an alarm via indicator lights or other means. If the verification succeeds, the device proceeds to the next step of the device authentication process.

[0065] 1.4: The device generates a random number R1, encrypts the random number R1 using the client public key PK_Client obtained from the client's digital certificate, and sends the encrypted random number ciphertext to the client.

[0066] 1.5: The client uses its own client private key (SK_Client) to decrypt the random number ciphertext to obtain the random number R1, calculates its hash value H1 = Hash(R1) (for example, using the SHA-256 algorithm), which is the digest of the random number R1; then it uses the device's public key PK_Device to encrypt H1 to obtain the encrypted digest, and sends the encrypted digest back to the device.

[0067] In this embodiment, the client can connect to the key management system (which can be deployed on the device management server) and query the key management system for the corresponding device public key PK_Device based on the device's unique identifier (SN); or in some embodiments, the device sends the device public key PK_Device via broadcast, and the client receives, obtains, and parses it.

[0068] 1.6: The device uses its own private key SK_Device to decrypt the encrypted digest to obtain the digest H1' of the random number R1, and calculates the value of the digest Hash(R1) of the local random number R1. It then compares the digest H1' of the decrypted random number R1 with the locally calculated digest Hash(R1) value to see if they match. If they do not match, the authentication is deemed to have failed, the security log is recorded, and temporary locking and other protective measures may be taken. If they match, it means that the two-way authentication between the client and the device is successful.

[0069] In some embodiments, the device can use a true random number generator (TRNG) within the security chip to temporarily generate keys for each authentication session. These keys are discarded after use and are never reused in different authentication rounds, thus ensuring the independence of each session key.

[0070] In the embodiment, a high-quality random number R1 that meets cryptographic security requirements can be generated. It has the characteristics of high entropy, unpredictability and resistance to random attacks, and is guaranteed by a hardware true random number source, which is different from software pseudo random numbers.

[0071] The two-way authentication mechanism provided by this invention completes the verification of "the device proving to the client that it owns the device's private key SK_Device" in just one round of interaction (ciphertext of random number R1 goes, cryptographic digest of random number R1 returns H1). Compared with the complex multi-round handshake and cipher suite negotiation of Transport Layer Security (TLS) protocols, it greatly reduces communication latency and computational load, making it particularly suitable for low-power Bluetooth scenarios.

[0072] In some embodiments, the random number R1 has a session-level expiration time. It is only used for the current two-way authentication and session key derivation. If the entire authentication process is not completed within a set time (e.g., 5 seconds), the device will automatically determine that the random number R1 has expired and is discarded, requiring the client to re-initiate authentication. This enhances the protocol's resistance to attacks.

[0073] In some embodiments, a key management system issues a device digital certificate for each legitimate device. This certificate may contain the device's public key PK_Device, a unique identifier for the device, and be signed and sealed using the root private key PK_Root. The device digital certificate may be pre-installed on the device. After verifying the client's legitimacy, the device sends its digital certificate to the client before sending the random number ciphertext. The client verifies the signature of its digital certificate using its own pre-installed root public key PK_Root to obtain the device's public key PK_Device and unique identifier. Only after successful verification does the device send the random number ciphertext.

[0074] In some embodiments, after successful two-way authentication, the two communicating parties negotiate and generate a temporary session key based on a shared random number R1 through a key derivation function (such as HKDF), which is used for the encryption and decryption of all subsequent communication data.

[0075] The process of establishing encrypted communication and securely transmitting commands can be referred to Figure 5 and Figure 6 ,include:

[0076] 2.1: When control commands need to be sent, the sending end (such as the client) appends the current precise timestamp and the communication sequence number that increments with each transmission after constructing the original command data;

[0077] 2.2: The sending end (such as the client) calculates the hash value of the instruction data as the first instruction digest value: H_CMD = Hash(original instruction data + timestamp + communication sequence number).

[0078] 2.3: The client uses the session key negotiated by both parties to encrypt the entire "original instruction data + timestamp + communication sequence number + first instruction digest value H_CMD" and send it to the device as an instruction ciphertext data packet.

[0079] 2.4: After receiving the encrypted instruction data packet, the receiving end (such as the device end) decrypts it using the session key negotiated with the client to restore the original instruction data, timestamp, communication sequence number and first instruction digest value H_CMD.

[0080] 2.5: Perform multiple core verifications on the device side:

[0081] 2.5.1 Timestamp Verification: Verify the validity of the timestamp and check whether its deviation from the current device time is within the allowable window (e.g., ±5 seconds) to prevent replaying old instructions.

[0082] 2.5.2 Communication Sequence Number Verification: Verify the uniqueness of the communication sequence number to ensure that the communication sequence number has not been used recently, further defending against replay attacks.

[0083] 2.5.3 Command Digest Value Comparison and Verification: Based on the decrypted command data, timestamp, and communication sequence number, recalculate the hash value, i.e., the second command digest value H_CMD', and compare it with the decrypted H_CMD to ensure that the command has not been tampered with during transmission.

[0084] Only if the timestamp verification, communication sequence number verification, and instruction digest value comparison verification all pass—that is, the deviation is within the allowable window, the communication sequence number is unique, and the calculated hash value H_CMD' matches the decrypted H_CMD—will the receiving end (such as the device) execute the corresponding control instruction and return the execution result (also encrypted and protected for integrity) to the sending end. If any verification fails, the device will securely discard the instruction.

[0085] As an example, the secure instruction transmission process includes:

[0086] (1) The user presses the “Start Continuous Passive Motion (CPM)” button on the control interface of the client application (APP), sets the angle to 30 degrees and the speed to “slow”.

[0087] (2) The APP business layer generates raw instruction data in JSON format: {"func": "start_cpm", "angle":30, "speed_level": 1}.

[0088] (3) The APP's security module appends the current Unix timestamp (accurate to the second) 1717542000 and a monotonically increasing communication sequence number 1025 to this instruction.

[0089] (4) The security module concatenates the string "start_cpm30\*1\*1717542000\*1025" and calculates its SHA-256 hash value. The first instruction digest value is H_CMD.

[0090] (5) The security module uses the current session key (AES-128-GCM mode) to encrypt and protect the integrity of the complete data consisting of instruction JSON, timestamp, serial number, and H_CMD (GCM mode provides both encryption and authentication tags) and generate instruction ciphertext data packets.

[0091] (6) The instruction encrypted data packet is written with a characteristic dedicated to instruction transmission via Bluetooth GATT.

[0092] (7) After the receiving end (such as the device) reads the encrypted instruction data packet from this feature, it transmits it to the security chip. The chip uses the session key for GCM decryption and authentication verification. If the GCM authentication tag verification fails, the encrypted instruction data packet is discarded directly, and a "Instruction integrity verification failed" log is recorded. If successful, the chip outputs the decrypted plaintext data: instruction data JSON, timestamp 1717542000, communication sequence number 1025, and the received H_CMD.

[0093] (8) The device-side main control software performs logical verification: It checks that the current device timestamp is 1717542002, which is 2 seconds different from 1717542000 in the instruction. This is within the allowed 5-second window, so it passes. It checks that the serial number 1025 does not appear in the 100 most recently cached executed instruction serial numbers, so it passes. It recalculates SHA-256 according to the same rules as the client ("start_cpm30\*1\*1717542000\*1025") to obtain H_CMD', and compares it with the received H_CMD. They match, so it passes.

[0094] (9) Once all verifications are successful, the device's main control software parses the JSON instruction and executes the action of "starting CPM motion at a slow angle of 30 degrees". After execution, the device generates a response data containing the "execution successful" status, which is also encrypted with an additional timestamp, serial number, calculated hash, and session key, and then sent to the APP.

[0095] The two-way authentication secure communication connection system provided by this invention can achieve the following beneficial effects: Preventing unauthorized client access: Ensuring that the device only accepts connections from authorized clients (such as official apps) that have passed strict identity authentication, blocking connection attempts from unauthorized terminals such as general Bluetooth debugging tools. Achieving true two-way identity authentication: While ensuring the legitimacy of the client, preventing counterfeit devices from deceiving users, and establishing a foundation of mutual trust for communication. Establishing an end-to-end encrypted communication channel: After successful authentication, a dynamic session key is established to achieve encrypted transmission and integrity verification of commands, resisting data eavesdropping and tampering. Maintaining compatibility and low latency: Without changing the hardware architecture or modifying the Bluetooth protocol stack, security enhancement is achieved through software-level measures, ensuring that connection establishment is completed within 1 second. Providing an anti-replay attack mechanism: Preventing commands from being executed repeatedly through dual verification of timestamps and serial numbers. Providing communication robustness guarantees: A well-designed anomaly handling and session recovery mechanism ensures that communication can be quickly and securely restored in the event of unstable wireless environments or unexpected communication interruptions, improving the user experience.

[0096] Based on the same inventive concept as the two-way authentication secure communication connection system provided in the above embodiments, the present invention also provides a device-side two-way authentication method for secure communication connections, such as... Figure 4 As shown, the device-side two-way authentication method is applied to the device side, which is configured with a root public key and a device-side asymmetric key pair. The device-side asymmetric key pair includes the device-side public key and the device-side private key. The method includes the following steps:

[0097] Receive connection requests and client digital certificates initiated by the client;

[0098] Use the root public key to verify the legitimacy of the client's digital certificate;

[0099] After the signature verification is successful, a random number is generated. The random number is then encrypted using the client's public key extracted from the client's digital certificate. The resulting ciphertext of the random number is sent to the client, allowing the client to decrypt the ciphertext using its own client private key. The client then encrypts the digest of the random number using the pre-obtained device-side public key of the target device and sends the encrypted digest back.

[0100] The device receives the encrypted digest sent back by the client and decrypts it using its own device-side private key to obtain the digest of the random number. It then compares the digest of the random number with its own digest generated for the random number to complete the two-way authentication.

[0101] Based on the same inventive concept as the above embodiments, the present invention also provides a client-side two-way authentication method for secure communication connections, such as... Figure 3 As shown, the client-side two-way authentication method is applied to the client, which is configured with a client digital certificate generated by signing the root private key. The client digital certificate contains the client public key. The method includes the following steps:

[0102] Initiate the device discovery process, filter out the target device from the scanned peripheral devices based on the preset device name characteristics or unique identifier, and obtain the device's public key;

[0103] Initiate a connection request to the target device and send the client digital certificate so that the target device can use its internally pre-installed root public key to verify the certificate signature.

[0104] Receive the encrypted random number sent back by the target device after the certificate verification is successful;

[0105] The client's own private key is used to decrypt the random number ciphertext, which is generated by the target device using the client's public key extracted from the client's digital certificate to encrypt the random number.

[0106] The random number is obtained by decrypting the ciphertext using the client's own private key.

[0107] The digest of the random number is encrypted using the pre-obtained public key of the target device. The encrypted digest is then sent back to the target device, which uses its private key to decrypt the digest to obtain the digest of the random number. This digest is then compared with the digest generated by the target device for the random number, thus completing the two-way authentication.

[0108] As an example, the process of a client connecting to the device and performing mutual authentication is as follows:

[0109] (1) The user opens the client (such as the official application APP on mobile phone, tablet, portable computer, etc.), enters the "My Devices" page, and clicks "Add Device".

[0110] (2) The application starts Bluetooth scanning and filters all Bluetooth devices whose broadcast name (Bluetooth Local Name) starts with "ExoBrace-" and displays them in the list.

[0111] (3) The user selects the device named “ExoBrace-A1B2” from the list.

[0112] (4) The user initiates a Bluetooth GATT connection to the MAC address of the device through the client application APP, and after the basic link is established, sends an "authentication request" command through a custom security authentication service characteristic. The payload of the command contains the client digital certificate of the APP.

[0113] (5) After receiving the client's digital certificate, the Bluetooth service program on the device side calls the cryptographic function in the security chip to verify the certificate signature using the preset root public key PK_Root. If the verification fails (e.g., certificate forgery), the device replies with an "authentication failed" code via GATT connection and actively disconnects the Bluetooth connection, while simultaneously controlling its blue LED to flash three times rapidly as an alarm. If the verification is successful, the device's security chip generates a 128-bit true random number R1.

[0114] (6) The device uses the client public key PK_Client parsed from the client digital certificate to encrypt the random number R1 using the ECC encryption algorithm, and sends the random number ciphertext to the APP via Bluetooth.

[0115] (7) After receiving the ciphertext of the random number, the client application APP calls the client private key SK_Client in the mobile device security environment to decrypt it and obtain the random number R1. Then, it calculates H1 = SHA256(R1).

[0116] (8) The APP obtains the device's public key PK_Device (or caches it from the server after querying the device's broadcast information or previous interactions) by querying the device's broadcast information or previous interactions, encrypts H1 with PK_Device, and sends the result back to the device.

[0117] (9) The device uses the device-side private key SK_Device in its security chip to decrypt and obtain H1'. At the same time, the chip calculates SHA256(R1) to obtain the local hash value.

[0118] (10) The chip compares the two hash values: if they do not match, the chip records a "two-way authentication failure" security log to its internal non-volatile memory and notifies the main controller to put the device into a "security lockout" state for 10 minutes, during which all connection attempts are rejected. If they match, the chip outputs an "authentication successful" signal. The main controller then establishes an encrypted channel and controls the green LED to stay lit, indicating that the device has been securely connected and is ready to go. At the same time, the device and the APP negotiate the AES-128 session key for subsequent communication based on R1 and the public keys of both parties using a standard algorithm.

[0119] In some embodiments, a session state preservation mechanism is employed: after successful two-way authentication, both parties cache the session key, the last used sequence number, and the derived session identifier (Session ID) in secure memory, and set a session validity period (e.g., 30 minutes).

[0120] In some embodiments, connection interruption detection is performed. If either party detects an unexpected disconnection of the communication link, a fast reconnection process is initiated, including: When the client reconnects, it carries the Session ID of the previous valid session in the initial handshake message; the device verifies that the Session ID exists, is valid, and has not expired, and retrieves the session key and communication sequence number bound to the session ID. If the verification is successful, both parties skip the complete asymmetric encryption two-way authentication process and directly use the original session key (or a new key derived from it) to resume encrypted communication, and synchronize the communication sequence number update status. This process can reduce the reconnection time from seconds to milliseconds, greatly improving the user experience; if the verification fails (the Session ID is invalid or expired), the client must re-execute the complete two-way authentication process in steps 1.1 to 1.6 above.

[0121] As an example, after the client and device establish a secure connection using the above two-way authentication communication method (the user has successfully completed two-way authentication between the APP and the device "ExoBrace-A1B2"), the two parties establish an initial secure session:

[0122] 1) The device and the APP have negotiated the AES-128 session key K_session for this session;

[0123] 2) The APP's security module records the current command serial number as 1025;

[0124] 3) Based on the random number R1 and the device serial number SN obtained during this authentication, both parties generate a short session identifier: SessionID = SHA256(R1 || SN).substr(0, 8) (i.e., take the first 8 bytes of the hash value as a hexadecimal string, such as "A3F19B2C").

[0125] 4) Both the device and the client APP cache the {SessionID, K_session, latest serial number} triple in secure memory and set the validity period of this session state to 30 minutes.

[0126] If the connection is unexpectedly interrupted, for example, if the user is walking and the phone is too far away from the device, the Bluetooth link layer connection will be lost:

[0127] 1) Both the client app and the device detected that the GATT connection had been lost.

[0128] 2) Both parties retain the cached security session state from the initial security session establishment phase and do not actively clear K_session and SessionID.

[0129] As an example, both the client and device can attempt a quick reconnection using the following steps:

[0130] When the user returns to the vicinity of the device, Bluetooth re-enters the connection range.

[0131] 1) The APP will automatically attempt to re-establish the Bluetooth GATT connection.

[0132] 2) After establishing a basic connection, the APP does not immediately perform full two-way authentication. Instead, it sends a "fast reconnection request" command through a custom security authentication feature. The command payload carries the previously cached SessionID (i.e., "A3F19B2C").

[0133] Device-side session authentication and recovery: The device-side security service receives a "fast reconnection request" and a SessionID.

[0134] The device searches its secure memory for the session identifier SessionID, along with the session key K_session and communication sequence number bound to the session identifier SessionID:

[0135] Scenario A: Found and not expired (within 30 minutes):

[0136] 1) The device retrieves the session key K_session bound to the SessionID and the last sequence number of the record (e.g., 1025).

[0137] 2) The device responds with a "Quick Reconnection Permission" via security features, along with the next serial number 1026 to be used.

[0138] 3) Both parties skip all asymmetric encryption operations (i.e. skip steps (5)-(10) of the client connection device and two-way authentication process in the example above) and directly enable K_session to restore the encrypted communication channel.

[0139] 4) The APP will reset the serial number to 1026, and the serial number that the device expects to receive will also start from 1026. This process is completed within 100 milliseconds.

[0140] Scenario B: Not found or expired:

[0141] 1) The device responded with "Full authentication required" via security features.

[0142] 2) After receiving this response, the APP will automatically switch to and execute the complete two-way authentication process (1)-(10) of the client connection device and two-way authentication process in the above example to establish a new secure session.

[0143] In this embodiment, the transmission of commands after recovery includes: after a successful fast reconnection, the user clicks the "CPM" button again. The subsequent command generation, encryption, transmission, and verification process is exactly the same as in the previous example, except that the session key used is the recovered K_session, and the sequence number increments from 1026.

[0144] The recovery mechanism used in the embodiments of the present invention reduces the reconnection waiting time caused by brief disconnections from the full "second-level" authentication to the "millisecond-level" without reducing the security level (the session key is still in secure memory and the SessionID itself has no secrets), which significantly improves the connection robustness and user experience of wearable devices in mobile usage scenarios.

[0145] The two-way authentication secure communication connection system and authentication method provided in this invention have the following beneficial technical effects:

[0146] 1. Strong authentication mechanism: Employs pre-set asymmetric keys and client digital certificates to achieve dual authentication between the client and the device, completely blocking unauthorized access.

[0147] 2. Resist multiple attacks:

[0148] Preventing man-in-the-middle attacks: Two-way authentication ensures that both parties in the communication are legitimate entities.

[0149] Anti-replay attack: Timestamp and sequence number mechanisms prevent commands from being reused.

[0150] Anti-forgery attack: The private key does not leave the secure storage area, so attackers cannot forge legitimate keys.

[0151] 3. End-to-end encryption protection: In addition to Bluetooth link layer encryption, application layer encryption and integrity verification are added to provide dual security protection.

[0152] 4. High compatibility and low latency: Fully compatible with standard Bluetooth protocols, the authentication process is optimized to be completed within 1 second, providing a good user experience.

[0153] 5. High scalability: This solution is compatible with a variety of wireless communication protocols (such as Wi-Fi, ZigBee, etc.) and is suitable for various IoT security scenarios.

[0154] The above provides a detailed description of the two-way authentication secure communication connection system and authentication method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the concept of this application and should not be construed as limiting the scope of protection of this application.

Claims

1. A two-way authenticated secure communication connection system, characterized in that, include: The client is configured with a client digital certificate generated by signing the root private key and a client asymmetric key pair, wherein the client asymmetric key pair includes a client public key and a client private key, and the client digital certificate contains the client public key; the client is used to determine the target device and obtain the device-side public key of the target device. Initiate a connection request to the target device and send the client's digital certificate; It is also used to receive the random number ciphertext sent back by the target device, decrypt it using its own client private key to obtain the random number, encrypt the digest of the random number using the device's public key, and send the obtained encrypted digest back to the device. On the device side, a root public key and a device-side asymmetric key pair are configured. The device-side asymmetric key pair includes a device-side public key and a device-side private key. Upon receiving a connection request, the device first uses the root public key to verify the legitimacy of the client's digital certificate. After successful verification, it triggers the generation of a random number and encrypts the random number using the client's public key extracted from the client's digital certificate. The device then sends the encrypted random number to the client. Finally, it uses its own device-side private key to decrypt the encrypted digest returned by the client to obtain the digest of the random number. This digest is then compared with the digest generated by the device for the random number to complete two-way authentication.

2. The two-way authentication secure communication connection system according to claim 1, characterized in that, The system also includes a key management system for issuing digital certificates for legitimate clients using a root private key.

3. A device-side two-way authentication method for secure communication connections, characterized in that, The device-side two-way authentication method is applied to the device, which is configured with a root public key and a device-side asymmetric key pair. The device-side asymmetric key pair includes a device-side public key and a device-side private key. The method includes: Receive connection requests and client digital certificates initiated by the client; The root public key is used to verify the legitimacy of the client's digital certificate. After the signature verification is successful, a random number is generated. The random number is then encrypted using the client public key extracted from the client's digital certificate. The resulting ciphertext of the random number is sent to the client, which then uses its own client private key to decrypt the ciphertext of the random number to obtain the random number. The client then uses a pre-obtained device public key to encrypt the digest of the random number and sends the encrypted digest back. The device receives the encrypted digest sent back by the client and decrypts it using its own device-side private key to obtain a digest of the random number. This digest is then compared with the digest generated by the device itself for the random number, thereby completing two-way authentication.

4. The device-side two-way authentication method according to claim 3, characterized in that, Before receiving the connection request initiated by the client and the client's digital certificate, the method further includes: during the device manufacturing stage, generating the device-side private key and the device-side public key within the security chip on the device side, wherein the device-side private key is restricted to operation within the security chip and cannot be exported.

5. The device-side two-way authentication method according to claim 3, characterized in that, The method further includes: the device starts a timer while sending the random number ciphertext; if two-way authentication is not completed within a preset valid window period, the random number is automatically determined to have expired and discarded.

6. The device-side two-way authentication method according to claim 3, characterized in that, The method further includes: after determining that the two-way authentication is successful, both the device and the client negotiate and generate a session key based on the random number through a key derivation function; The system receives a ciphertext data packet of instructions generated using its own session key from the client, decrypts it using the local session key, and restores the instruction data, timestamp, communication sequence number, and first instruction digest value; it also verifies whether the deviation between the timestamp and its current time is within a preset time window. Verify whether the communication sequence number is unique in its usage history within a preset time period; The second instruction digest value is recalculated based on the decrypted instruction data, timestamp, and communication sequence number, and the second instruction digest value is compared with the first instruction digest value to see if they are consistent. The instruction data will only be executed if the timestamp verification, communication sequence number verification, and instruction digest value comparison verification all pass; if any one of the verifications fails, the device will discard the instruction data.

7. A client-side two-way authentication method for secure communication connections, characterized in that, The client-side two-way authentication method is applied to the client, which is configured with a client digital certificate generated by signing the root private key, and the client digital certificate contains the client public key; The method includes the following steps: Identify the target device and obtain the device-side public key of the target device; A connection request is initiated to the target device and the client digital certificate is sent so that the target device can use its internally pre-installed root public key to verify the certificate signature. The system receives a random number ciphertext sent back by the target device after the certificate verification is successful. The random number ciphertext is generated by the target device encrypting the random number using the client public key extracted from the client digital certificate. The random number is obtained by decrypting the ciphertext using the client's own private key. The device uses its public key to encrypt the digest of the random number, and sends the encrypted digest back to the target device. The target device then uses its private key to decrypt the encrypted digest to obtain the digest of the random number, and compares it with its own digest generated for the random number to complete two-way authentication.

8. The client-side two-way authentication method according to claim 7, characterized in that, The method further includes: after determining that the two-way authentication is successful, both the device and the client negotiate and generate a session key based on the random number through a key derivation function; The system encrypts and generates a ciphertext data packet using its own generated session key and sends it to the target device. The target device then decrypts the packet using its local session key to recover the instruction data, timestamp, communication sequence number, and a first instruction digest value. The system then verifies whether the deviation between the timestamp and its current time is within a preset time window; verifies whether the communication sequence number is unique within the usage history of a preset time period; recalculates a second instruction digest value based on the decrypted instruction data, timestamp, and communication sequence number, and compares the second instruction digest value with the first instruction digest value; the system executes the instruction data only if the timestamp verification, sequence number verification, and instruction digest value comparison all pass; if any verification fails, the device discards the instruction data.

9. The client-side two-way authentication method according to claim 8, characterized in that, The method further includes obtaining the unique identifier of the target device; after the session key negotiation is successful, caching the current session key, communication sequence number and session identifier, and setting the session validity period, wherein the session identifier is generated by both the client and the device based on the random number and the unique identifier; When the communication link is unexpectedly disconnected and reconnected, the client sends a fast reconnection request and the session identifier to the device. If the device verifies that the session identifier exists and has not expired, and the device retrieves the session key and communication sequence number bound to the session identifier, then both parties skip the asymmetric encryption two-way authentication process, directly resume encrypted communication, and synchronously use the next communication sequence number; otherwise, the two-way authentication process is initiated.

10. The client-side two-way authentication method according to claim 7, characterized in that: The client digital certificate also includes the application identity information, which includes at least the package name and application version number of the client application. When the device verifies the signature of the client's digital certificate using the root public key, it also verifies the validity of the package name and version number to ensure that the client application is a preset officially authorized version.

Images