Communication verification method of insulin infusion system and electronic equipment

Abstract

The invention provides a communication verification method of an insulin infusion system and electronic equipment. According to the communication verification method of the insulin infusion system, the safety and reliability of the system are ensured through reasonable steps. Firstly, a control end receives broadcast information sent by a controlled end and sends a connection request to the controlled end based on the information, and a preliminary communication link is established. And then, the system ensures safe binding of the control end and the controlled end by executing a preset binding defense mechanism, and prevents access of unauthorized equipment. Finally, after binding is completed, an identity verification strategy is executed, and the legality of the identities of the devices of the two parties is further ensured. Through the series of steps, the safety of the insulin infusion system is effectively improved, man-in-the-middle attack and illegal access are prevented, and the safety and stability of a patient in the medication process are guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of insulin pumps, and in particular to a communication verification method and electronic equipment for an insulin infusion system. Background Art

[0002] Insulin pumps, an effective means of controlling blood sugar, have been used clinically for over four decades. In the Chinese market, they have also been in use for over two decades, with nearly 60,000 long-term users, approximately 3,000 hospitals implementing insulin pump therapy, and over one million short-term users. As the number of diabetes patients increases, demand for insulin pump therapy continues to grow.

[0003] Traditional tube-based insulin pumps (non-patch-type) lack any wireless communication capabilities. The few wireless models that do feature this functionality are limited to viewing basic information (such as remaining medication level and battery level) and cannot be used to wirelessly control infusion. Patch-type pumps, with their small size, light weight, high reliability, and high discreetness, significantly enhance the patient experience. Due to physical design limitations (no physical buttons or only an emergency button), patch-type pumps must rely on wireless control channels for full infusion functionality.

[0004] Patches are generally categorized as fully disposable or semi-disposable. Semi-disposable pumps, while offering limited button input and sound / light output, have lower water resistance ratings. Fully disposable pumps typically lack input devices, providing only simple outputs such as buzzers and / or indicator lights. Patches also have limitations in securely transmitting information, particularly complex information, outside of wireless communication channels.

[0005] In the communication scenario between the insulin pump and the control end, there is a technical problem of low security. Summary of the Invention

[0006] The purpose of the present invention is to overcome the above technical deficiencies and provide a communication verification method and electronic device for an insulin infusion system to solve the technical problem of low security in the communication scenario between the insulin pump and the control terminal in the related art.

[0007] In order to achieve the above technical objectives, the present invention adopts the following technical solutions: In a first aspect, the present invention provides a communication verification method for an insulin infusion system, the method being applied to a control terminal in the insulin infusion system, the method comprising: Receiving broadcast information; wherein the broadcast information is broadcast information sent by the controlled end of the insulin infusion system at a target power; Sending a connection request to the controlled terminal based on the broadcast information; wherein the connection request is used to establish an initial communication link between the control terminal and the controlled terminal; When the initial communication link is established, the preset binding defense mechanism is executed to achieve the binding between the control terminal and the controlled terminal; After the binding is completed, the preset authentication strategy is executed.

[0008] Furthermore, the broadcast information does not include sensitive data and includes at least one custom target field; wherein, the target field is encrypted or hashed for device identification; the target power represents a preset low transmission power to limit the signal coverage range, thereby preventing the broadcast information from being intercepted by non-related devices.

[0009] Furthermore, the preset binding defense mechanism is a man-in-the-middle attack defense mechanism; and the step of executing the preset binding defense mechanism to achieve binding between the control terminal and the controlled terminal after the initial communication link is established includes: Exchange verification information with the controlled end through out-of-band verification via the initial communication link; performing verification of the authentication information; If the authentication information is verified, it will negotiate with the controlled end to generate a pairing key and establish a secure communication link to achieve pairing; After pairing is completed, a binding operation is performed to store the pairing key and device identification information to form a binding relationship.

[0010] Furthermore, the preset binding defense mechanism is a man-in-the-middle attack defense mechanism; and the step of executing the preset binding defense mechanism to achieve binding between the control terminal and the controlled terminal after the initial communication link is established includes: Perform digital input comparison and verification with the controlled end through the initial communication link; If the input comparison and verification pass, negotiate with the controlled end to generate a pairing key, and establish a secure communication link based on the pairing key to complete the pairing; After pairing is completed, a binding operation is performed to store the pairing key and device identification information to form a binding relationship.

[0011] Furthermore, the step of performing digital input comparison and verification with the controlled terminal through the initial communication link includes: receiving a first random verification code sent by the controlled terminal through the initial communication link; Generate a second random verification code and compare and verify it with the received first random verification code.

[0012] Furthermore, the preset identity authentication strategy is a two-way identity authentication strategy; and after the binding is completed, the step of executing the preset identity authentication strategy includes: Sending first identity authentication information to the controlled terminal so that the controlled terminal verifies the legitimacy of the first identity authentication information; wherein the first identity authentication information is pre-encrypted data and pre-stored in the control terminal; wherein the controlled terminal pre-stores a first decryption key, and the first decryption key is capable of decrypting the first identity authentication information; Receiving second identity authentication information sent by the controlled terminal; wherein the second identity authentication information is pre-encrypted data and is pre-selected and stored in the controlled terminal; The second identity authentication information is decrypted using a pre-stored second decryption key and its legitimacy is verified; wherein the second decryption key is pre-stored in the control terminal.

[0013] Furthermore, the step of executing the preset identity authentication strategy also includes: Receive security verification request information sent by the controlled end; wherein the security verification request information is generated by the controlled end, and the security verification request information includes device identification information and session parameters generated in the binding phase; Forwarding the security verification request information to the server, so that the server performs security policy verification on the security verification request information; wherein the security policy verification includes verifying the legitimacy of the device identification information and session parameters; Receive a response data packet sent by the server; wherein the response data packet is generated by the server, includes a verification result and a control instruction, and is encrypted by the server using a server key; wherein the response data packet is also sent to the controlled terminal; Decrypting using the pre-stored first server decryption key to obtain the verification result and the control instruction; wherein the controlled terminal is pre-stored with the second server decryption key, and the second server decryption key can be used to decrypt the response data packet received by the controlled terminal; Execute preset operations based on the verification results and control instructions; wherein, the preset operations include: allowing infusion instruction interaction when the verification result indicates pass; terminating the current connection when the verification result indicates fail; restricting device behavior or prompting device upgrade according to the control instructions.

[0014] Furthermore, after the binding is completed, the step of executing the preset identity authentication strategy includes: Receiving second identity authentication information sent by the controlled terminal; wherein the second identity authentication information is pre-encrypted data and is pre-selected and stored in the controlled terminal; The second identity authentication information and the first identity authentication information are sent together to the server, so that the server decrypts the second identity authentication information and the first identity authentication information respectively and verifies their legitimacy; wherein the first identity authentication information is pre-encrypted data and is pre-selected and stored in the control terminal; wherein the server pre-stores a corresponding decryption key.

[0015] In a third aspect, the present invention provides a communication verification method for an insulin infusion system, the method being applied to a controlled end in the insulin infusion system, the method comprising: Sending broadcast information; wherein the broadcast information is broadcast information sent by the controlled end at the target power; wherein the broadcast information is used to cause the control end to send a connection request to the controlled end; Receiving a connection request sent by the control terminal; wherein the connection request is used to establish an initial communication link between the control terminal and the controlled terminal; When the initial communication link is established, the control end executes the preset binding defense mechanism to achieve the binding between the control end and the controlled end; After the binding is completed, cooperate with the control end to execute the preset authentication strategy.

[0016] Furthermore, the preset binding defense mechanism is a man-in-the-middle attack defense mechanism; the step of cooperating with the control terminal to execute the preset binding defense mechanism includes: Receive the out-of-band authentication request sent by the control end through the initial communication link: In response to the out-of-band verification request, generating encrypted verification information and outputting the information through a physical interaction interface; receiving a pairing negotiation request generated by the control end based on the encrypted verification information; Negotiate with the control end to generate a pairing key and establish a secure communication link to achieve pairing; After pairing is completed, a binding operation is performed to store the pairing key and the control terminal device identification information to form a binding relationship. In a third aspect, the present invention provides an electronic device comprising: a memory, and one or more processors communicatively connected to the memory; the memory stores instructions executable by the one or more processors, and the instructions are executed by the one or more processors so that the one or more processors implement the above-mentioned method.

[0017] Beneficial effects: The communication verification method for the insulin infusion system provided by the present invention ensures the security and reliability of the system through reasonable steps. First, the control end receives the broadcast information sent by the controlled end, and based on the information, sends a connection request to the controlled end to establish a preliminary communication link. Then, the system ensures the secure binding of the control end and the controlled end by executing a preset binding defense mechanism to prevent unauthorized device access. Finally, after the binding is completed, the identity authentication strategy is executed to further ensure the legitimacy of the device identities of both parties. Through this series of steps, the method effectively improves the security of the insulin infusion system, prevents man-in-the-middle attacks and illegal access, and ensures the safety and stability of patients during medication. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 1 is a flow chart of a communication verification method for an insulin infusion system provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of an example scenario of a communication verification method for an insulin infusion system provided by an embodiment of the present invention; Figure 3 1 is a flow chart of a communication verification method for an insulin infusion system provided by an embodiment of the present invention; Figure 4 This is a block diagram of an electronic device used in an embodiment of the present invention. DETAILED DESCRIPTION

[0019] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0020] Existing wireless communication technologies, such as Bluetooth, can establish stable connections and exchange data within a range of several meters or even tens of meters in an open, interference-free environment. However, many devices include sensitive information such as device control instructions and user data in their Bluetooth broadcast packets. This practice poses serious security risks: wireless signals are easily detected, monitored, and interfered with, potentially leaking user privacy or causing device loss of control, threatening the user's life. This is particularly true for wirelessly controlled insulin pumps. If the wireless communication protocol is cracked, attackers could tamper with the infusion regimen, creating unacceptable medical risks.

[0021] Current wirelessly controlled infusion devices, especially in the medical field where safety is paramount, have the following major flaws in wireless communication security: 1. Broadcast information security risks: Some devices directly include sensitive information (such as device control data and user data) in Bluetooth broadcast information (including the device name). This openness of broadcast information makes sensitive data easily monitored, detected, and exploited, potentially leading to information leakage, device misoperation, and even malicious control. This risk is particularly prominent for life-critical infusion devices.

[0022] 2. The Bluetooth binding mechanism is fragile: Before device binding, Bluetooth broadcasts are typically open. Many devices use the less secure traditional Bluetooth binding method or low-security Bluetooth secure connection modes (such as work-only mode or digital comparison mode with no actual device output). These lack effective protection against man-in-the-middle and replay attacks. This makes it difficult for users to verify the identity of the bound device, making it vulnerable to man-in-the-middle attacks. This can lead to binding information leakage or illegal device binding and control, potentially causing insulin dosage errors and endangering patient safety.

[0023] 3. Poor device identifier recognizability: Existing technologies typically use the device's MAC address as the device identifier during binding. MAC addresses are difficult for ordinary users to identify and are automatically generated by the device, making it difficult for users to confirm device ownership through the MAC address. The binding process is unreliable and prone to misuse.

[0024] 4. Whitelisting mechanisms are easily bypassed: Some devices use MAC address whitelisting as a security measure, but do not combine it with a long-term key (LTK) and / or identity resolution key (IRK). MAC addresses are easily forged, and simply using a MAC address whitelist is unlikely to effectively reduce the attack surface or substantially improve security.

[0025] 5. The Bluetooth binding process lacks user controllability and security auditability: The key exchange and passphrase transmission during the Bluetooth binding process are automatically performed by internal programs, which are not user-viewable or user-controllable, lacking transparency and auditability. Once a device is illegally bound, it is difficult for users to detect and remedy the situation. Furthermore, the Bluetooth binding process may lack mandatory security level checks, posing the risk of downgrade attacks.

[0026] 6. Lack of link-layer encryption and replay attack protection during data transmission: After Bluetooth binding, some devices do not enable link-layer encryption for data transmission or lack an effective timestamp mechanism. This makes data vulnerable to replay attacks. Even with a timestamp, the operation content can be deciphered, leading to the leakage of sensitive information or abnormal control of the device.

[0027] 7. Lack of bidirectional authentication and continuous identity verification: Some devices assume the user's identity is legitimate upon binding, lacking continuous identity verification mechanisms, particularly bidirectional authentication. One-way or insecure authentication mechanisms can be easily bypassed by counterfeit devices, leading to illegal devices establishing connections and exchanging data with infusion pumps, creating the risk of data leakage or malicious device manipulation.

[0028] 8. The security design is not universal enough and lacks special considerations for medical scenarios: The existing wireless insulin pump security design lacks special considerations for medical application scenarios, such as in-depth analysis of data sensitivity, equipment reliability, user operating habits, etc., resulting in insufficient pertinence and effectiveness of security measures.

[0029] Based on the above-mentioned shortcomings of the existing technology, this embodiment provides a communication verification method for an insulin infusion system. This method aims to significantly improve the security of wireless infusion devices in terms of device authentication, data transmission, and operation control without modifying the existing hardware design, and to address various security vulnerabilities and hidden dangers in the existing technology. Specifically, the method includes: Improve the security of device identity authentication: Implement a more secure and reliable identity mutual recognition mechanism between the control end and the controlled end, prevent illegal device access and control, and eliminate user misoperation.

[0030] Ensure the security of data transmission: prevent wireless communication data from being maliciously hijacked, tampered with or leaked, and ensure the integrity, confidentiality and authenticity of infusion instructions and data.

[0031] Improve the safety of the infusion process: Reduce infusion risks caused by wireless communication security issues and ensure patient medication safety.

[0032] Flexible security controls: Optionally, manufacturers or authorized institutions (such as hospitals) can implement additional security controls on device usage, such as restricting the use of older versions of devices, adjusting the expiration date, and limiting the dosage range, to adapt to changing security needs and medical management requirements.

[0033] like Figure 1 and Figure 2As shown, this embodiment provides a communication verification method for an insulin infusion system. The method is applied to a control terminal in the insulin infusion system. In this embodiment, the insulin infusion system may include a control terminal and a controlled terminal. The control terminal may be a dedicated portable controller or an intelligent terminal (e.g., a smartphone or tablet computer) equipped with corresponding control software. The controlled terminal may be an insulin pump. Wireless communication may be used to exchange data between the control terminal and the controlled terminal. Specifically, the insulin infusion system is a medical device system used for continuous or on-demand automatic insulin infusion in diabetic patients. This insulin infusion system continuously and accurately delivers insulin to patients, helping them better control their blood sugar levels and reduce the risk of hyperglycemia or hypoglycemia. The control terminal is the device in the insulin infusion system used to set, control, and monitor the operation of the insulin pump. The control terminal may be a dedicated portable controller, for example, a handheld remote control designed specifically for insulin pumps, which may be equipped with a display and buttons. The control terminal may also be a smartphone. The controlled end can be the device that actually performs insulin infusion, namely the insulin pump itself. This insulin pump receives instructions from the control end, accurately injects insulin into the patient according to set parameters, and can also feedback status information and alarm information to the control end. The controlled end can be a wearable insulin pump (for example, an externally worn pump that connects to a subcutaneous infusion needle via a catheter), a subcutaneous implantable insulin pump, or a patch pump.

[0034] The method comprises: Step S12: receiving broadcast information; wherein the broadcast information is broadcast information sent by the controlled end of the insulin infusion system at a target power.

[0035] In this embodiment, the received broadcast information may be the control end receiving broadcast information sent by the controlled end. The broadcast information does not contain sensitive data and includes at least one custom target field; the target field is encrypted or hashed for device identification; the target power represents a preset low transmit power to limit signal coverage and thereby prevent the broadcast information from being intercepted by unrelated devices.

[0036] In a specific implementation scheme, the control terminal may send broadcast information to the controlled terminal.

[0037] In one specific implementation, the controlled (or controlling) end can actively transmit wireless signals for discovery and connection selection. Broadcast information can be pre-structured to contain only the necessary information for device identification and connection establishment, without directly including any sensitive data. Customized portions of the broadcast information require complex processing (e.g., encryption, hashing, etc.) to prevent easy parsing and exploitation. Optionally, the broadcast transmission power can be reduced to limit the wireless signal coverage range and mitigate the potential for remote monitoring and attack.

[0038] Specifically, the broadcast information can be a data packet periodically transmitted by one end (controlled end or controlling end) of the insulin infusion system to the surrounding environment in a wireless manner (for example, Bluetooth BLE broadcast). The broadcast information can be used for device discovery, identity recognition and initial connection establishment without carrying any sensitive user information or medical data to ensure the security of the insulin infusion system. The broadcast information only contains the minimum necessary information, and the key fields are encrypted or hashed to prevent the data from being intercepted and used for attacks. More specifically, step S12 may include: The control terminal starts the wireless interface and enters the scanning mode, continuously monitoring the surrounding broadcast signals.

[0039] When the broadcast information transmitted by the controlled end (or the other party) enters the signal receiving range of the control end, the control end will capture the broadcast signal.

[0040] The control end parses the custom target field in the broadcast signal and performs identity verification through a preset key or algorithm to determine whether the device is the target paired device.

[0041] If the identity verification is passed, the control end can initiate further pairing and connection requests and enter a communication stage with a higher security level.

[0042] Step S14: sending a connection request to the controlled end based on the broadcast information; wherein the connection request is used to establish an initial communication link between the control end and the controlled end.

[0043] In this embodiment, step S14 may include: First, the control end parses and filters the broadcast information. Specifically, after receiving the broadcast information sent by the controlled end, the control end first parses the custom target field in the broadcast packet. The target field has been encrypted or hashed (for example, a SHA-256 hash value or an AES-encrypted anonymous device identifier), and the control end can use a pre-stored decryption key or hash verification algorithm to verify the legitimacy of the target field. If the target field verification fails (for example, the hash value does not match or the decrypted content is invalid), the control end discards the broadcast information and does not initiate a connection request. The control end can also further extract the device type identifier (for example, an insulin pump device code) in the broadcast information to confirm that it belongs to a connectable controlled end type.

[0044] The control end then constructs and sends a connection request. Specifically, based on the parsed broadcast information, the control end can construct a connection request packet that complies with a wireless communication protocol (e.g., Bluetooth Low Energy). The connection request packet can include the control end's temporary device address (e.g., a random private address) and connection parameters (e.g., connection interval, timeout). To prevent the signal from being intercepted at a distance, the control end can send the connection request at a low transmission power (e.g., a signal coverage range of less than 1 meter). The control end can send the connection request packet to the controlled end via a wireless channel.

[0045] Finally, after receiving the connection request, the controlled end can execute the corresponding response. Specifically, the controlled end can verify the legitimacy of the control end's address (for example, checking whether it is the first connection or a device on the whitelist). The controlled end can confirm that the connection parameters comply with the preset security policy (for example, the connection interval does not exceed the maximum limit of the protocol). If the verification is successful, the controlled end can send a connection response packet to the control end to confirm acceptance of the connection request. The two parties establish an initial communication link based on the negotiated communication parameters (for example, channel hopping sequence, encryption mode). This initial communication link only implements the basic data path and does not enable encryption or identity authentication (security enhancement is completed in the subsequent binding phase). Moreover, the link status is temporary and will be automatically disconnected if the binding is not completed within the specified time.

[0046] Step S16: When the initial communication link is established, a preset binding defense mechanism is executed to achieve binding between the control terminal and the controlled terminal.

[0047] In this embodiment, the preset binding defense mechanism may be a man-in-the-middle attack defense mechanism, and the binding between the control terminal and the controlled terminal is achieved by executing the man-in-the-middle attack defense mechanism.

[0048] In this embodiment, the preset binding defense mechanism may be a one-time password mechanism.

[0049] In this embodiment, the preset binding defense mechanism may be a physical confirmation mechanism. For example, when binding, the user is required to physically confirm the binding operation on the controlled end (for example, by pressing a specific button, scanning a QR code, etc.) to ensure that the binding operation is initiated by the device owner.

[0050] In this embodiment, the preset binding defense mechanism may be a time and space restriction mechanism. For example, the binding operation is only allowed to be completed within a specific time period or a specific physical range (e.g., within the Bluetooth or NFC range of the device) to prevent remote counterfeit binding.

[0051] In this embodiment, the preset binding defense mechanism may be a multi-factor authentication mechanism. For example, multiple authentication methods such as password, SMS, email, fingerprint, and facial recognition may be combined to enhance the binding security level.

[0052] Step S18: After the binding is completed, the preset identity authentication strategy is executed.

[0053] In this embodiment, the preset identity authentication policy may be an identity authentication policy of a secondary bidirectional identity authentication between the control terminal and the controlled terminal.

[0054] In this embodiment, the preset identity authentication policy may be a server-based identity authentication policy.

[0055] In this embodiment, the preset authentication strategy can be a token-based authentication strategy. For example, a unique access token can be pre-configured for the control end. In each subsequent communication, the control end needs to carry a valid token. The controlled end or server verifies the legitimacy of the token and determines the identity is valid.

[0056] In this embodiment, the preset identity authentication policy can be an identity authentication policy based on behavior analysis. For example, by analyzing user operation habits, device usage characteristics, geographic location and other behavioral data, it can determine whether the current operation is initiated by a legitimate user and automatically trigger secondary verification for abnormal behavior.

[0057] The communication verification method for the insulin infusion system provided in this embodiment ensures the security and reliability of the system through reasonable steps. First, the control end receives the broadcast information sent by the controlled end, and based on the information, sends a connection request to the controlled end to establish a preliminary communication link. Then, the system ensures the secure binding of the control end and the controlled end by executing a preset binding defense mechanism to prevent unauthorized device access. Finally, after the binding is completed, the identity authentication strategy is executed to further ensure the legitimacy of the device identities of both parties. Through this series of steps, the method effectively improves the security of the insulin infusion system, prevents man-in-the-middle attacks and illegal access, and ensures the safety and stability of patients during medication.

[0058] In some embodiments, the broadcast information does not include sensitive data and includes at least one custom target field; wherein the target field is encrypted or hashed for device identification; the target power represents a preset low transmission power to limit the signal coverage range, thereby preventing the broadcast information from being intercepted by non-related devices.

[0059] In this embodiment, the broadcast information may be constructed based on the Bluetooth Low Energy (BLE) protocol or other wireless communication protocols, such as the Wi-Fi Direct (Wi-Fi P2P) protocol, the Zigbee protocol, the NFC (Near Field Communication) protocol, or the Ultra-Wideband (UWB) protocol.

[0060] In this embodiment, the broadcast information may include a general field and one or more customized target fields. The general field may include a device type identifier and a signal strength indication. The device type identifier may indicate that the device is a controlled end of an insulin infusion system. The signal strength indication may be used to assist the control end in determining the distance of the device, but does not contain precise location information. The customized target field may identify the specific identity of the device and is used by the control end to identify a legitimate controlled end. It is understandable that the broadcast information does not contain any sensitive data (e.g., device serial number, user ID, etc.). Moreover, the target field content may be an encrypted or hashed device identity identifier.

[0061] Specifically, the controlled end can perform symmetric encryption (e.g., AES-128) or asymmetric encryption (e.g., ECC public key encryption) on the device's unique identifier (e.g., the factory-set 128-bit device serial number). The controlled end can use a hash algorithm such as SHA-256 or HMAC-SHA3 on the device's unique identifier to generate a fixed-length hash value (e.g., 32 bytes) as the target field content. Alternatively, the device identifier can be hashed first and then the hash value encrypted for dual protection.

[0062] In this embodiment, the target power can be a transmit power between -20dBm and 0dBm, limiting the signal coverage range to within 1 meter (the specific value can be calibrated through RF testing). Specifically, the target power can represent the wireless transmit power set by the controlled end when broadcasting information. Its purpose is to limit the signal's physical coverage range by reducing signal strength, thereby effectively preventing the broadcast content from being intercepted by unrelated devices at a distance and improving the system's security and privacy protection capabilities. This embodiment can select lower settings such as -20dBm, -16dBm, -8dBm, or 0dBm, or it can be flexibly configured based on the actual environment and RF test results. It is understood that at a transmit power between -20dBm and 0dBm, the actual signal coverage radius is often less than 1 meter. The specific coverage distance will be affected by factors such as the environment, obstacles, and antenna characteristics, but through RF testing and field calibration, it can be ensured that the broadcast signal is only received within a very small range around the device.

[0063] In this embodiment, the non-related device can be an unauthorized control terminal, such as a nearby user's mobile phone, tablet, computer, or other smart terminal. Although these devices can receive broadcast signals using the same protocol, they have not undergone authentication or binding authorization and do not have a legitimate control relationship with the controlled terminal. They can also be scanning devices in public environments or potential attacker devices.

[0064] This implementation effectively prevents unauthorized devices from intercepting broadcast content by not including sensitive data in broadcast information, using encrypted or hashed target fields for identity identification, and limiting the wireless transmission power to a lower range. This improves the security of device pairing and identity authentication, and enhances the system's privacy protection capabilities. It is particularly suitable for scenarios with high data security requirements.

[0065] like Figure 3 As shown, in some embodiments, the preset binding defense mechanism is a man-in-the-middle attack defense mechanism; the step of executing the preset binding defense mechanism to achieve binding between the control terminal and the controlled terminal after the initial communication link is established includes: Step S162: Exchange verification information with the controlled end through out-of-band verification via the initial communication link.

[0066] In this embodiment, the out-of-band (OOB) authentication method can be a QR code scanning method. For example, the controlled end generates a dynamic QR code that can include the following information: a temporary session key (e.g., a 16-byte random number, which can be encrypted using an asymmetric public key) and an anonymous device identifier (e.g., a hashed serial number). The controlling end can scan the QR code, obtain the encrypted data using a local camera or a dedicated code scanning module, and decrypt it to extract the session key.

[0067] In this embodiment, the out-of-band (OOB) authentication method can also be an NFC touch method. The controlled end can write encrypted authentication information (for example, ECDH public key) through the NFC chip. The controlling end obtains this information through the NFC card reader and completes the key exchange.

[0068] In this embodiment, the out-of-band (OOB) verification method can also be a digital display comparison method. For example, the controlled terminal displays a 6-digit dynamic verification code on the screen, and the controlling terminal requires the user to manually enter the verification code to complete the comparison.

[0069] Step S164: Perform verification of the verification information.

[0070] In this embodiment, if a QR code / NFC method is used, the control end decrypts the received verification information and verifies whether the device's anonymous identifier matches the target field in the broadcast information. If a digital comparison method is used, the control end compares the verification code entered by the user with the verification code generated by the controlled end. The controlled end verifies the confirmation signal (e.g., hash value signature) returned by the control end to ensure that the control end is legitimate.

[0071] Step S166: If the verification information passes the verification, negotiate with the controlled end to generate a pairing key, and establish a secure communication link to achieve pairing.

[0072] In this embodiment, after the authentication information is verified, the master and slave enter the pairing key negotiation phase. The primary goal of this phase is to utilize a secure key agreement protocol to generate a pairing key, known only to both parties. Based on this key, a secure communication link is established to achieve pairing and subsequent encrypted communication. Specifically, a pre-defined key agreement algorithm can be used to generate the pairing key. Examples include asymmetric key agreement algorithms such as Diffie-Hellman (DH) key exchange and Elliptic Curve Diffie-Hellman (ECDH). The master generates its own key pair (e.g., ECDH private and public keys) and sends the public key to the slave. The slave similarly generates its own key pair and returns its public key to the master. Using their own private key and the other party's public key, both parties use the key agreement algorithm to calculate the same session key (i.e., the pairing key). Furthermore, to prevent man-in-the-middle attacks, both parties can perform integrity verification on the public key and related parameters during the negotiation process using message digests (e.g., HMAC) or digital signatures. Upon successful verification, the pairing key generation is considered successful. After the key is successfully generated, both parties can negotiate the use of a symmetric encryption algorithm (e.g., AES) based on the pairing key and establish an encrypted communication channel. Subsequent pairing-related data and instructions are encrypted and transmitted over a secure link to prevent information leakage and tampering.

[0073] Step S168: After pairing is completed, a binding operation is performed to store the pairing key and device identification information to form a binding relationship.

[0074] In this implementation, after the master and slave devices have paired and successfully established a secure communication link, they must perform a binding operation. The binding operation associates and securely stores the pairing keys and unique device identification information of both devices. This allows for secure communication to be established directly during subsequent use without the need for re-pairing, achieving trust and convenient connectivity between devices.

[0075] In this embodiment, the device identification information may be a unique identification code of the device (eg, MAC address, serial number, device ID, etc.), which is used to identify the uniqueness of the other party's device.

[0076] In this embodiment, the pairing key and device identification information (i.e., binding information) can be stored. The binding information can be stored locally on the control terminal and the controlled terminal, respectively, and can be saved in the form of structured data (e.g., key-value pairs, objects, database records, etc.). Furthermore, the control terminal and the controlled terminal can write the binding information into a secure storage area to prohibit direct external access. Specifically, the control terminal can associate the local pairing key with the identification information of the other device (e.g., MAC address and device name) to form a binding record. During subsequent use, the control terminal can quickly identify and establish encrypted communication with the controlled terminal by scanning the local list of bound devices, without repeating the pairing process. The binding information can serve as a trust credential to implement a "whitelist" mechanism between devices, effectively preventing unauthorized access by unfamiliar devices.

[0077] This implementation introduces an out-of-band verification mechanism after the initial communication link is established, achieving secure exchange and verification of verification information, effectively defending against man-in-the-middle attacks. Only the legitimate control end and the controlled end that have passed the verification can negotiate to generate a pairing key and establish a secure communication link, ultimately completing secure binding and persistently storing pairing information, thereby greatly improving the security and anti-attack capabilities of the device binding process and ensuring the reliability of subsequent communications and data security.

[0078] In some embodiments, the preset binding defense mechanism is a man-in-the-middle attack defense mechanism; and the step of executing the preset binding defense mechanism to achieve binding between the control terminal and the controlled terminal after the initial communication link is established includes: Step S162: Exchange verification information with the controlled end through out-of-band verification via the initial communication link.

[0079] In this embodiment, the out-of-band (OOB) authentication method can be a QR code scanning method. For example, the controlled end generates a dynamic QR code that can include the following information: a temporary session key (e.g., a 16-byte random number, which can be encrypted using an asymmetric public key) and an anonymous device identifier (e.g., a hashed serial number). The controlling end can scan the QR code, obtain the encrypted data using a local camera or a dedicated code scanning module, and decrypt it to extract the session key.

[0080] In this embodiment, the out-of-band (OOB) authentication method can also be an NFC touch method. The controlled end can write encrypted authentication information (for example, ECDH public key) through the NFC chip. The controlling end obtains this information through the NFC card reader and completes the key exchange.

[0081] In this embodiment, the out-of-band (OOB) verification method can also be a digital display comparison method. For example, the controlled terminal displays a 6-digit dynamic verification code on the screen, and the controlling terminal requires the user to manually enter the verification code to complete the comparison.

[0082] Step S164: Perform verification of the verification information.

[0083] In this embodiment, if a QR code / NFC method is used, the control end decrypts the received verification information and verifies whether the device's anonymous identifier matches the target field in the broadcast information. If a digital comparison method is used, the control end compares the verification code entered by the user with the verification code generated by the controlled end. The controlled end verifies the confirmation signal (e.g., hash value signature) returned by the control end to ensure that the control end is legitimate.

[0084] Step S166: If the verification information passes the verification, negotiate with the controlled end to generate a pairing key, and establish a secure communication link to achieve pairing.

[0085] In this embodiment, after the authentication information is verified, the master and slave enter the pairing key negotiation phase. The primary goal of this phase is to utilize a secure key agreement protocol to generate a pairing key, known only to both parties. Based on this key, a secure communication link is established to achieve pairing and subsequent encrypted communication. Specifically, a pre-defined key agreement algorithm can be used to generate the pairing key. Examples include asymmetric key agreement algorithms such as Diffie-Hellman (DH) key exchange and Elliptic Curve Diffie-Hellman (ECDH). The master generates its own key pair (e.g., ECDH private and public keys) and sends the public key to the slave. The slave similarly generates its own key pair and returns its public key to the master. Using their own private key and the other party's public key, both parties use the key agreement algorithm to calculate the same session key (i.e., the pairing key). Furthermore, to prevent man-in-the-middle attacks, both parties can perform integrity verification on the public key and related parameters during the negotiation process using message digests (e.g., HMAC) or digital signatures. Upon successful verification, the pairing key generation is considered successful. After the key is successfully generated, both parties can negotiate the use of a symmetric encryption algorithm (e.g., AES) based on the pairing key and establish an encrypted communication channel. Subsequent pairing-related data and instructions are encrypted and transmitted over a secure link to prevent information leakage and tampering.

[0086] Step S168: After pairing is completed, a binding operation is performed to store the pairing key and device identification information to form a binding relationship.

[0087] In this implementation, after the master and slave devices have paired and successfully established a secure communication link, they must perform a binding operation. The binding operation associates and securely stores the pairing keys and unique device identification information of both devices. This allows for secure communication to be established directly during subsequent use without the need for re-pairing, achieving trust and convenient connectivity between devices.

[0088] In this embodiment, the device identification information may be a unique identification code of the device (eg, MAC address, serial number, device ID, etc.), which is used to identify the uniqueness of the other party's device.

[0089] In this embodiment, the pairing key and device identification information (i.e., binding information) can be stored. The binding information can be stored locally on the control terminal and the controlled terminal, respectively, and can be saved in the form of structured data (e.g., key-value pairs, objects, database records, etc.). Furthermore, the control terminal and the controlled terminal can write the binding information into a secure storage area to prohibit direct external access. Specifically, the control terminal can associate the local pairing key with the identification information of the other device (e.g., MAC address and device name) to form a binding record. During subsequent use, the control terminal can quickly identify and establish encrypted communication with the controlled terminal by scanning the local list of bound devices, without repeating the pairing process. The binding information can serve as a trust credential to implement a "whitelist" mechanism between devices, effectively preventing unauthorized access by unfamiliar devices.

[0090] This implementation introduces an out-of-band verification mechanism after the initial communication link is established, achieving secure exchange and verification of verification information, effectively defending against man-in-the-middle attacks. Only the legitimate control end and the controlled end that have passed the verification can negotiate to generate a pairing key and establish a secure communication link, ultimately completing secure binding and persistently storing pairing information, thereby greatly improving the security and anti-attack capabilities of the device binding process and ensuring the reliability of subsequent communications and data security.

[0091] In some embodiments, the preset binding defense mechanism is a man-in-the-middle attack defense mechanism; and the step of executing the preset binding defense mechanism to achieve binding between the control terminal and the controlled terminal after the initial communication link is established includes: Perform digital input comparison and verification with the controlled end through the initial communication link; Specifically, the controlled end can generate a short digital verification code (e.g., a 6- or 8-digit random number) based on a secure random number generation mechanism. This verification code is unique and unpredictable within a short timeframe. The controlled end displays the generated digital verification code in plain text on its local display interface (e.g., a screen, LED display, etc.) for public disclosure to the user. The user observes the digital verification code displayed on the controlled end and enters it into the control end's input interface (e.g., a mobile app, a computer client, etc.). After receiving the verification code, the control end can send it to the controlled end for confirmation via the initial communication link, or the control end can compare it locally with a verification code previously obtained by the controlled end. After receiving the verification code from the control end, the controlled end compares it with the verification code it generated. If the verification codes are identical, the authentication between the control end and the controlled end is considered successful, confirming that both parties are operating from the same physical user and eliminating the risk of intermediaries interfering by forging the communication link.

[0092] If the input comparison and verification pass, negotiate with the controlled end to generate a pairing key, and establish a secure communication link based on the pairing key to complete the pairing; After pairing is completed, a binding operation is performed to store the pairing key and device identification information to form a binding relationship.

[0093] In some embodiments, the step of performing digital input comparison and verification with the controlled terminal through the initial communication link includes: A first random verification code sent by the controlled terminal is received through the initial communication link.

[0094] In this embodiment, the controlled end can use a secure random number generator to generate a first random verification code (e.g., a set of random characters). The controlled end can send this first random verification code to the controlling end (e.g., a mobile phone, a host, etc.) via an initial communication link (e.g., Bluetooth, Wi-Fi Direct, etc.). Simultaneously, the controlled end can display this verification code on a local screen or physically prompt the user.

[0095] Generate a second random verification code and compare and verify it with the received first random verification code.

[0096] In this embodiment, after receiving the first random verification code sent by the controlled end, the control end can locally generate a second random verification code based on a preset algorithm and security policy. Specifically, the second random verification code can use the same generation rules as the first random verification code, or be generated based on the first random verification code, session information, timestamp, and other parameters through hashing, encryption, or other methods to ensure its security and uniqueness.

[0097] The control end can compare the locally generated second random verification code with the first random verification code sent by the controlled end via the initial communication link. Specifically, this comparison can be a direct consistency check (i.e., the two must be identical) or a logical consistency check based on a pre-defined verification algorithm (e.g., checksum, cryptographic verification, etc.). If the comparison succeeds, the control end has established a unique and secure interactive link with the controlled end, and verification is successful. If the comparison fails, it indicates that the link may have been tampered with or a man-in-the-middle attack has occurred, resulting in verification failure and the subsequent pairing or binding process will be terminated or restarted.

[0098] This implementation implements a dual random verification code comparison mechanism during the initial communication link, achieving bidirectional authentication of both parties, effectively preventing security threats such as man-in-the-middle attacks and data tampering. The controlled end generates and sends a first random verification code using a secure random number generator. The controlling end independently generates a second random verification code based on the received verification code and a pre-set algorithm. A consistency or logical comparison is then performed, and pairing can only proceed if the verification passes. This mechanism ensures the uniqueness and real-time nature of the pairing process, significantly improving the security and reliability of device binding and providing a solid foundation for subsequent secure communication and data protection.

[0099] In some embodiments, the preset identity authentication policy is a two-way identity authentication policy; and after the binding is completed, the step of executing the preset identity authentication policy includes: Step S1802: Send the first identity authentication information to the controlled end so that the controlled end can verify the legitimacy of the first identity authentication information; wherein, the first identity authentication information is pre-encrypted data and is pre-stored in the control end; wherein, the controlled end pre-stores a first decryption key, and the first decryption key can perform decryption on the first identity authentication information.

[0100] In this embodiment, the control end generates first identity authentication information by pre-encrypting its own identity (e.g., device certificate hash value, serial number) through asymmetric public key encryption or symmetric encryption during device production or initial binding. This first identity authentication information can be persistently stored in the control end's non-volatile memory. Specifically, the control end does not store the encryption key, only the ciphertext. The key required for decryption is pre-stored only on the controlled end.

[0101] The controlling end can send the first identity authentication information to the controlled end via a secure communication link (an encrypted channel enabled after binding). The controlled end decrypts the first identity authentication information using the locally stored first decryption key to obtain a plaintext identity identifier. The controlled end then verifies the legitimacy of the plaintext identity identifier. For example, the controlled end can verify whether the plaintext identity identifier is in the authorized device list or whether the certificate signature or hash value matches a pre-stored value.

[0102] Step S1804: receiving second identity authentication information sent by the controlled terminal; wherein the second identity authentication information is pre-encrypted data and is pre-selected and stored in the controlled terminal.

[0103] In this embodiment, after the first identity authentication information is authenticated by the controlled terminal, the second identity authentication information sent by the controlled terminal is received. It is understandable that if the authentication fails, the controlled terminal will not send the second identity authentication information.

[0104] Similarly, when the controlled end manufactures the device or binds it for the first time, it will generate the second identity authentication information by encrypting its own identity (for example, the hash value of the device serial number) with the public key of the controlling end or by symmetric encryption.

[0105] Step S1806: Use a pre-stored second decryption key to decrypt the second identity authentication information and verify its legitimacy; wherein the second decryption key is pre-stored in the control terminal.

[0106] In this embodiment, the control end uses a locally pre-stored second decryption key to decrypt the second identity authentication letter to obtain a plaintext identity identifier. The control end can also verify its legitimacy. If the verification is successful, the control end and the controlled end can mutually recognize the legitimacy of the identity and allow the execution of infusion instructions, parameter adjustment and other operations. In addition, a session key update mechanism can be enabled (for example, a temporary key is rotated every hour). If the verification fails, the current session is terminated immediately, the secure communication link is disconnected, and a security alarm can also be triggered (for example, a pop-up window on the control end APP prompts "Device Identity Abnormal").

[0107] This implementation implements mutual authentication between the control and controlled devices by executing a pre-set bidirectional authentication policy after binding is complete, effectively preventing security risks such as impersonation by unauthorized devices and hijacking of communication links. By utilizing pre-encrypted authentication information and pre-setting keys before pairing, this ensures that only legitimate devices holding the correct keys can decrypt and verify the identity of the other party, achieving a higher level of device trust. This mechanism not only enhances the overall security and attack resistance of the system, but can also, combined with measures such as session key rotation, further ensure the security and reliability of subsequent sensitive operations and data exchanges, providing a solid foundation for long-term trust and secure operation between devices.

[0108] In some implementations, the step of executing a preset identity authentication policy further includes: Step S1808: receiving security verification request information sent by the controlled end; wherein, the security verification request information is generated by the controlled end, and the security verification request information includes device identification information and session parameters generated in the binding phase.

[0109] In this embodiment, the control end will receive security verification request information from the controlled end after establishing a secure communication link with the controlled end. Specifically, the security verification request information is automatically generated by the controlled end and contains its device identification information (for example, device ID, serial number, MAC address) and session parameters negotiated or generated during the binding phase (for example, session key ID, timestamp, random number, etc.). It can be understood that the above information is used to subsequently verify the legitimacy of the device identity and the validity of the current session to prevent illegal devices from impersonating or the session from being tampered with. The controlled end can send the security verification request information to the control end through the established encrypted communication link to ensure that the information is not stolen or tampered with during transmission.

[0110] Step S18010: forwarding the security verification request information to the server, so that the server performs security policy verification on the security verification request information; wherein the security policy verification includes verifying the legitimacy of the device identification information and session parameters.

[0111] In this embodiment, upon receiving the security verification request from the controlled end, the control end can forward the information intact or after necessary packaging to a cloud server or a local server. It is understood that the server, as a centralized security management node, is responsible for authoritatively verifying device identity and session parameters, thereby enhancing the security level of the overall system.

[0112] In this embodiment, the security policy verification may be: Verify device identification information. For example, you can confirm whether the device is registered, authorized, or whitelisted.

[0113] Verify session parameters. For example, you can check the timeliness, uniqueness, and integrity of session parameters (for example, verify that the timestamp has not expired, the random number has not been reused, and the session key ID is valid) to prevent replay and forgery attacks.

[0114] Step S18012: Receive a response data packet sent by the server; wherein, the response data packet is generated by the server, the response data packet includes a verification result and a control instruction, and the response data packet is a data packet encrypted by the server using a server key; wherein, the response data packet is also sent to the controlled end.

[0115] In this implementation, after the server completes security policy verification, it generates a response packet and sends it to the control end. Specifically, the response packet may include the verification result (e.g., "Verification Passed" or "Verification Failed") and control instructions for the current device and session (e.g., allowing / restricting certain operations, parameter adjustment suggestions, upgrade prompts, etc.).

[0116] In this embodiment, after the control end receives the response data packet from the server end, it will synchronously send the data packet to the controlled end to ensure that the controlled end obtains the same verification results and control instructions as the control end.

[0117] Step S18014: Use the pre-stored first server decryption key to decrypt and obtain the verification result and control instructions; wherein, the controlled end has a pre-stored second server decryption key, which can be used to decrypt the response data packet received by the controlled end.

[0118] In this embodiment, the control end can use the locally stored first server decryption key to decrypt the received encrypted response data packet and obtain the plaintext verification results and control instructions. Correspondingly, the controlled end can use the locally stored second server decryption key to decrypt the response data packet forwarded by the control end and obtain the same verification results and control instructions. It should be understood that the server decryption key is securely stored only locally on each device and is not transferred between devices or across the network, ensuring that only authorized devices can decrypt and read the response data packet content.

[0119] Step S18016: Execute preset operations according to the verification result and the control instructions; wherein, the preset operations include: if the verification result indicates a pass, allowing the infusion instruction interaction; if the verification result indicates a fail, terminating the current connection and triggering an alarm; restricting device behavior or prompting the device to upgrade according to the control instructions.

[0120] In this embodiment, device behavior may include: Infusion parameter adjustment: such as single infusion upper limit, basal rate range, etc.; Alarm rule settings: such as blood glucose threshold alarm, device abnormality reminder switch, etc.; System function configuration: such as data synchronization frequency, user interface lock, etc.

[0121] In this embodiment, if the verification result is passed, the control end and the controlled end can allow subsequent sensitive interactive operations, such as allowing infusion instructions to be issued, parameter adjustments, data synchronization, etc. If the verification result is failed, the current connection between the control end and the controlled end is immediately terminated to prevent any potential security risks, and a security alarm can be triggered in real time (for example, a pop-up window on the control end app, a buzzer alarm on the controlled end, etc.). Based on the control instructions issued by the server, the control end or the controlled end can proactively limit certain parameters (for example, maximum dose, operation permissions, etc.) or prompt the user to perform additional operations such as equipment upgrades and maintenance, thereby achieving remote control and dynamic security policy adjustment.

[0122] Through the above-mentioned multi-level security verification and encryption strategy, collaborative security management and control among the device side, control side and server side is achieved, which significantly improves the overall security and controllability of the system, effectively prevents risks such as illegal device access, session hijacking, parameter abuse, and ensures the safe and reliable operation of the equipment in critical business.

[0123] In some implementations, the step of executing a preset identity authentication policy after the binding is completed includes: Step S1822: Receive second identity authentication information sent by the controlled terminal; wherein the second identity authentication information is pre-encrypted data and is pre-selected and stored in the controlled terminal.

[0124] In this embodiment, during device production or initial binding, the controlled end processes its own identification information (e.g., device serial number, device ID, certificate hash, etc.) using a preset algorithm and encryption method (e.g., symmetric encryption or public key encryption) to generate second identity authentication information. This encrypted information is securely stored in the controlled end's local memory. When identity verification is required, the controlled end transmits this second identity authentication information to the controlling end via a secure communication link (e.g., encrypted Bluetooth, Wi-Fi, etc.). Because this information is pre-encrypted, even if an unauthorized third party intercepts the data, they cannot directly obtain the device's true identity or falsify the authentication process.

[0125] Step S1824: Send the second identity authentication information and the first identity authentication information together to the server, so that the server decrypts the second identity authentication information and the first identity authentication information respectively and verifies their legitimacy; wherein, the first identity authentication information is pre-encrypted data and is pre-selected and stored in the control end; wherein, the corresponding decryption key is pre-stored in the server.

[0126] In this embodiment, during device production or initial binding, the control end similarly uses an encryption algorithm to generate first identity authentication information from its own identity identifier (e.g., certificate hash, device serial number) and persistently stores it locally. The control end can then send both the second identity authentication information (from the controlled end) and the first identity authentication information (stored locally) to the server via a secure channel. The server may pre-store a decryption key associated with the authentication information and can decrypt the first and second identity authentication information separately to obtain the plaintext identity identifier. The server then verifies the legitimacy of the decrypted identity identifier. For example, this may include verifying whether the identity identifier is in the permitted list, whether it is consistent with the device registration information, and whether the hash value / signature matches.

[0127] This implementation achieves high security during the transmission and storage of authentication information by encrypting and storing the identity information of the control and controlled devices separately during device production or initial binding. After binding is complete, both parties upload their pre-encrypted authentication information to the server via a secure communication link. The server then decrypts and verifies its legitimacy using a dedicated decryption key, preventing identity forgery, fraudulent use, and data leakage. This effectively enhances the authority of inter-device authentication and overall system security, providing a solid foundation of trust for subsequent secure communications and sensitive operations.

[0128] In a specific embodiment, a device authentication and security management method for a wirelessly controllable infusion device is provided. The core design concept is as follows: 1. Collaboration and identity authentication requirements between the control and controlled terminals: A wirelessly controllable insulin pump system consists of a control terminal (typically a portable controller or a general-purpose terminal loaded with control software) and a controlled terminal (the insulin pump itself). Upon initial use or initial use, a wireless connection must be established between the control and controlled terminals. The primary task is bidirectional identity authentication to ensure the legitimacy and reliability of both communicating parties.

[0129] 2. Specially constructed broadcast information and low transmit power strategy: The controlled (or controlling) end actively transmits wireless signals for discovery and connection selection. Broadcast information must be specially constructed to contain only the necessary information for device identification and connection establishment, and not directly contain any sensitive data. Customized portions of the broadcast information must undergo complex processing (such as encryption and hashing) to prevent easy parsing and exploitation. Optionally, broadcast transmit power can be reduced to limit wireless signal coverage and reduce the possibility of remote monitoring and attack.

[0130] 3. Pre-binding secure connection and MITM protection: Before identity authentication, the controlled end must be able to establish a connection with any controlling end for initial binding. Before binding, secure man-in-the-middle (MITM) protection mechanisms must be implemented, such as digital input validation or out-of-band (OOB) methods. After binding is complete, encryption keys are negotiated and encrypted communication begins.

[0131] 4. Secondary bidirectional identity authentication and security key management after encrypted communication: After entering encrypted communication, the control and controlled devices must perform bidirectional identity authentication. First, the control device actively sends its identity information, which the controlled device decrypts and verifies. Once verified, the controlled device then sends its identity information, which the control device verifies. Bidirectional authentication ensures that both communicating devices are legitimate.

[0132] 5. Identity information storage and verification without encryption key storage: The control end and the controlled end do not store the key itself used to encrypt the identity information locally, but the pre-encrypted identity information. The decryption key is only stored by the device that needs to decrypt. Each connection uses a different pre-generated session key. Even if the locally stored information is leaked, the encryption key cannot be directly obtained, thereby minimizing the risk of key leakage and limiting the scope of impact of a single key leak on other devices or connections. At the same time, the system will store decryption keys or related parameters used to decrypt identity information from other roles (for example, the controller decrypts identity information from the pump and vice versa). Two-way authentication and secure key management together ensure the reliability and security of the identities of both communicating parties.

[0133] 6. Optional Server-Involved Secondary Security Verification and Control: Optionally, a server can be introduced for secondary security verification and device control. The controlled end generates a request message and forwards it to the server via the control end. The server decrypts the request message and performs a security assessment and policy judgment (for example, verifying the device serial number, checking the device version, applying control policies, etc.). The server returns a data packet regardless of the security verification result. The control end and the controlled end each decrypt the data packet returned by the server and, based on the decrypted information, determine whether subsequent actions are necessary (for example, rejecting the connection, prompting the user to upgrade, applying new control policies, etc.). Optimally, the decryption process can also be performed by the server, and the controlled and control ends do not even need to store the decryption key, completely eliminating the possibility of key leakage. Of course, solutions that do not use a server can pre-set the necessary verification information locally on the device, but this will sacrifice certain security and remote control capabilities.

[0134] 7. Persistent Binding Information, Whitelisting, and Subsequent Connection Security: After all authentication steps are successfully completed, the control and controlled devices persistently store each other's binding information (e.g., long-term key (LTK) and identity resolution key (IRK)), enable whitelisting mode, and add the other device to the whitelist. Each subsequent connection requires binding information verification and a secondary two-way identity verification to ensure connection security.

[0135] In a specific embodiment, the product implementation requirements may be: 1. Low-power Bluetooth secure connection capability: The product must use a chip with low-power Bluetooth (BLE) function and support the secure connection and pairing functions of the Bluetooth protocol stack, including secure pairing, key negotiation, link layer encryption, etc.

[0136] 2. Hardware support for OOB verification: If OOB verification is used, the control end and / or the controlled end must have the corresponding hardware interfaces and devices, such as: QR code / barcode scanning module: used for scanning identification codes; NFC module: used for near-field communication data exchange; digital input / output devices: such as touch screens, buttons, and displays, used for displaying and entering digital verification codes.

[0137] 3. Server Communication Capabilities: If a server-based secondary authentication and control solution is used, the controlling and / or controlled terminals must have network communication capabilities that allow them to connect directly or indirectly to the server (e.g., via mobile network, Wi-Fi, etc.). This requirement is not required if a server is not used.

[0138] In a specific embodiment, the device is mainly composed of the following functional modules: 1. Casing: Protects internal components and provides necessary physical interfaces and operating interfaces.

[0139] 2. Control part: including microprocessor, memory, power management module, etc., responsible for the core control, data processing and logical operations of the equipment.

[0140] 3. Wireless part: including Bluetooth chip, antenna, etc., responsible for the realization of wireless communication function.

[0141] 4. Infusion propulsion part: including motor, drive mechanism, drug reservoir interface, etc., responsible for precise control of insulin infusion.

[0142] 5. User interaction interface: such as display screen, touch screen, buttons, speakers, etc., used for user operation and information display.

[0143] 6. OOB verification module: such as QR code scanning module, NFC module, etc., used to support OOB device binding and authentication.

[0144] In a specific embodiment, the working principle is: An insulin pump is an artificial intelligence-controlled insulin delivery device that continuously delivers insulin subcutaneously, simulating physiological insulin secretion patterns and effectively controlling blood sugar levels. The device works as follows: 1. Insulin Storage and Infusion: The reservoir is preloaded with short-acting or rapid-acting insulin. The control unit drives the infusion propulsion unit based on a preset infusion plan and real-time blood glucose monitoring data (optional), accurately infusing insulin from the reservoir through the indwelling needle into the subcutaneous tissue.

[0145] 2. Wireless Control and Security Management: Users use a control terminal (e.g., a mobile app or dedicated controller) to set and control the insulin pump's operating parameters and infusion mode via a wireless communication link. The device authentication and security management method proposed in this invention ensures the legitimacy of the control terminal and the controlled terminal during wireless communication, preventing unauthorized access and malicious control, ensuring the security and integrity of data transmission, and enabling secure and reliable wireless infusion control.

[0146] 3. Alarm and prompt: The device has alarm and prompt methods (at least one, including but not limited to sound, vibration, display, etc.) to remind users of device status, low battery, infusion abnormalities and other information to ensure medication safety.

[0147] 4. Server interaction: In the solution with server intervention, the device connects to the server through the network to perform operations such as device authentication, security policy updates, and data synchronization, achieving a higher level of security control and remote management functions.

[0148] The device authentication and security management method for wirelessly controllable infusion devices proposed in this embodiment has the following significant advantages: 1. High security and low cost: Without modifying the existing product hardware design, the wireless communication security performance of the device can be significantly improved through software and process optimization, achieving an effective combination of high security and low cost.

[0149] 2. Ease of use and convenience: The entire security authentication and control process is mainly completed automatically by the program. Users only need to perform a small number of necessary confirmation operations (such as entering digital verification codes, scanning QR codes, etc.), which will not significantly increase the user's operating burden and ensure the product's ease of use and user experience.

[0150] 3. Scalability and Flexibility: Optional server-side authentication and control mechanisms provide a flexible and scalable solution for device security management. Manufacturers or authorized organizations can flexibly adjust security policies, update device versions, and implement remote control based on actual needs to adapt to evolving security threats and management needs.

[0151] 4. Professionalism for medical scenarios: The solution of the present invention fully considers the particularity of medical application scenarios and proposes a systematic and targeted safety solution to the safety defects of existing wireless infusion devices, which is more in line with the safety requirements and regulatory standards of medical equipment.

[0152] 5. Effective defense against various wireless security attacks: The solution of the present invention adopts a variety of security mechanisms, including specially constructed broadcast information, MITM defense binding method, link layer encryption, two-way identity authentication, optional server secondary verification, etc., which can effectively defend against various common wireless security threats such as eavesdropping, man-in-the-middle attacks, replay attacks, counterfeit device attacks, etc.

[0153] The key points of this implementation plan mainly include the following aspects: 1. Specially constructed broadcast information: Broadcast information used for device discovery and connection establishment. Its content is processed through non-simple construction, contains only necessary information, and does not disclose sensitive data.

[0154] 2. Binding method with MITM protection combined with wireless power control: Secure MITM protection mechanisms such as digital input verification or OOB methods are used to prevent man-in-the-middle attacks and ensure the security of initial binding. Low transmit power is used to further reduce the risk of wireless signal leakage and the possibility of man-in-the-middle attacks during the binding process.

[0155] 3. Enable link layer encryption: During the data transmission phase after Bluetooth binding, link layer encryption is forcibly enabled to ensure the confidentiality and integrity of data transmission.

[0156] 4. LTK and / or IRK-based binding and pairing mechanism: Utilize the long-term key (LTK) and / or identity resolution key (IRK) of Bluetooth secure connection for device binding and pairing to improve binding strength and security.

[0157] 5. Secondary two-way identity authentication mechanism: Two-way identity authentication is performed between the control end and the controlled end to ensure that both communicating parties are legitimate devices and prevent counterfeit devices from accessing.

[0158] 6. Server-enhanced secondary security verification mechanism: Introducing a server for secondary security verification and control to provide a higher level of security and remote management capabilities.

[0159] 7. Secure key storage and management: Critical keys used to construct broadcast and authentication information are not stored on the device, preventing key leakage and unauthorized use. Each connection uses a different key, effectively limiting the scope of the impact of a single key leak.

[0160] 8. Software control process for device authentication and security management: The software control process for implementing the above security mechanisms includes software implementation methods for each link such as device discovery, binding, authentication, encrypted communication, and security management.

[0161] According to an embodiment of the present invention, a communication verification method for an insulin infusion system is provided. The method is applied to a controlled terminal in the insulin infusion system, and the method includes: Sending broadcast information; wherein the broadcast information is broadcast information sent by the controlled end at the target power; wherein the broadcast information is used to cause the control end to send a connection request to the controlled end; Receiving a connection request sent by the control terminal; wherein the connection request is used to establish an initial communication link between the control terminal and the controlled terminal; When the initial communication link is established, the control end executes the preset binding defense mechanism to achieve the binding between the control end and the controlled end; After the binding is completed, cooperate with the control end to execute the preset authentication strategy.

[0162] Furthermore, the preset binding defense mechanism is a man-in-the-middle attack defense mechanism; the step of cooperating with the control terminal to execute the preset binding defense mechanism includes: Receive the out-of-band authentication request sent by the control end through the initial communication link: In response to the out-of-band verification request, generating encrypted verification information and outputting the information through a physical interaction interface; receiving a pairing negotiation request generated by the control end based on the encrypted verification information; Negotiate with the control end to generate a pairing key and establish a secure communication link to achieve pairing; After pairing is completed, a binding operation is performed to store the pairing key and the control terminal device identification information to form a binding relationship. Furthermore, the step of cooperating with the control terminal to execute a preset binding defense mechanism includes: Generate a first random verification code and send it to the control terminal through the initial communication link; Receive a second random verification code fed back by the control terminal; Verifying the consistency between the first random verification code and the second random verification code; After the verification is passed, a pairing key is generated through negotiation with the control end, and a secure communication link is established based on the pairing key.

[0163] Furthermore, the step of cooperating with the control terminal to execute a preset identity authentication policy includes: Receiving first identity authentication information sent by the control terminal; wherein the first identity authentication information is pre-encrypted data; Decrypt and verify the first identity authentication information using a pre-stored first decryption key; Sending second identity authentication information to the control end; wherein, the second identity authentication information is encrypted data pre-stored by the controlled end and can be decrypted and verified by the control end using a second decryption key.

[0164] The step of cooperating with the control terminal to execute the preset identity authentication policy also includes: Generate security verification request information, the request information including device identification and binding phase session parameters; Sending the security verification request information to the control end to be forwarded to the service end; Receive the encrypted response data packet returned by the server; Use the pre-stored server decryption key to decrypt the response data packet to obtain the verification results and control instructions; Execute corresponding actions based on the decryption result, including allowing input interaction, terminating the connection, or parameter restriction.

[0165] According to an embodiment of the present invention, an electronic device is provided. Figure 4 The electronic device in this embodiment may include one or more of the following components: a processor, a network interface, a memory, a non-volatile memory, and one or more applications, wherein the one or more applications may be stored in the non-volatile memory and configured to be executed by one or more processors, and the one or more programs are configured to execute the method described in the aforementioned method embodiment.

[0166] According to an embodiment of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a computer, the computer executes the method described in any one of the above embodiments.

[0167] According to an embodiment of the present invention, a computer program product comprising instructions is further provided. When the instructions are executed by a computer, the computer is enabled to perform a method in any one of the above embodiments.

[0168] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0169] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0170] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0171] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0172] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A communication verification method for an insulin infusion system, characterized in that: The method is applied to a control end of an insulin infusion system, and the method comprises: Receiving broadcast information; wherein the broadcast information is broadcast information sent by the controlled end of the insulin infusion system at a target power; Sending a connection request to the controlled terminal based on the broadcast information; wherein the connection request is used to establish an initial communication link between the control terminal and the controlled terminal; When the initial communication link is established, the preset binding defense mechanism is executed to achieve the binding between the control terminal and the controlled terminal; After the binding is completed, the preset authentication strategy is executed.

2. The method according to claim 1, characterized in that The broadcast information does not include sensitive data and includes at least one custom target field; wherein, the target field is encrypted or hashed for device identification; the target power represents a preset low transmission power to limit the signal coverage range, thereby preventing the broadcast information from being intercepted by non-related devices.

3. The method according to claim 1, characterized in that The preset binding defense mechanism is a man-in-the-middle attack defense mechanism; when the initial communication link is established, the step of executing the preset binding defense mechanism to achieve binding between the control terminal and the controlled terminal includes: Perform digital input comparison and verification with the controlled end through the initial communication link; If the input comparison and verification pass, negotiate with the controlled end to generate a pairing key, and establish a secure communication link based on the pairing key to complete the pairing; After pairing is completed, a binding operation is performed to store the pairing key and device identification information to form a binding relationship.

4. The method according to claim 3, characterized in that The step of performing digital input comparison and verification with the controlled terminal through the initial communication link includes: receiving a first random verification code sent by the controlled terminal through the initial communication link; Generate a second random verification code and compare and verify it with the received first random verification code.

5. The method according to claim 1, characterized in that The preset identity authentication strategy is a two-way identity authentication strategy; After the binding is completed, the step of executing the preset identity authentication policy includes: Sending first identity authentication information to the controlled terminal so that the controlled terminal verifies the legitimacy of the first identity authentication information; wherein the first identity authentication information is pre-encrypted data and pre-stored in the control terminal; wherein the controlled terminal pre-stores a first decryption key, and the first decryption key is capable of decrypting the first identity authentication information; Receiving second identity authentication information sent by the controlled terminal; wherein the second identity authentication information is pre-encrypted data and is pre-selected and stored in the controlled terminal; The second identity authentication information is decrypted using a pre-stored second decryption key and its legitimacy is verified; wherein the second decryption key is pre-stored in the control terminal.

6. The method according to claim 5, characterized in that The step of executing the preset identity authentication strategy further includes: Receive security verification request information sent by the controlled end; wherein the security verification request information is generated by the controlled end, and the security verification request information includes device identification information and session parameters generated in the binding phase; Forwarding the security verification request information to the server, so that the server performs security policy verification on the security verification request information; wherein the security policy verification includes verifying the legitimacy of the device identification information and session parameters; Receive a response data packet sent by the server; wherein the response data packet is generated by the server, includes a verification result and a control instruction, and is encrypted by the server using a server key; wherein the response data packet is also sent to the controlled terminal; Decrypting using the pre-stored first server decryption key to obtain the verification result and the control instruction; wherein the controlled terminal is pre-stored with the second server decryption key, and the second server decryption key can be used to decrypt the response data packet received by the controlled terminal; Execute preset operations based on the verification results and control instructions; wherein, the preset operations include: allowing infusion instruction interaction when the verification result indicates pass; terminating the current connection when the verification result indicates fail; restricting device behavior or prompting device upgrade according to the control instructions.

7. The method according to claim 1, characterized in that After the binding is completed, the step of executing the preset identity authentication policy includes: Receiving second identity authentication information sent by the controlled terminal; wherein the second identity authentication information is pre-encrypted data and is pre-selected and stored in the controlled terminal; The second identity authentication information and the first identity authentication information are sent together to the server, so that the server decrypts the second identity authentication information and the first identity authentication information respectively and verifies their legitimacy; wherein the first identity authentication information is pre-encrypted data and is pre-selected and stored in the control terminal; wherein the server pre-stores a corresponding decryption key.

8. A communication verification method for an insulin infusion system, characterized in that: The method is applied to a controlled end in an insulin infusion system, and comprises: Sending broadcast information; wherein the broadcast information is broadcast information sent by the controlled end at the target power; wherein the broadcast information is used to cause the control end to send a connection request to the controlled end; Receiving a connection request sent by the control terminal; wherein the connection request is used to establish an initial communication link between the control terminal and the controlled terminal; When the initial communication link is established, the control end executes the preset binding defense mechanism to achieve the binding between the control end and the controlled end; After the binding is completed, cooperate with the control end to execute the preset authentication strategy.

9. The method according to claim 8, characterized in that The preset binding defense mechanism is a man-in-the-middle attack defense mechanism; the steps of cooperating with the control terminal to execute the preset binding defense mechanism include: Receive the out-of-band authentication request sent by the control end through the initial communication link: In response to the out-of-band verification request, generating encrypted verification information and outputting the information through a physical interaction interface; receiving a pairing negotiation request generated by the control end based on the encrypted verification information; Negotiate with the control end to generate a pairing key and establish a secure communication link to achieve pairing; After pairing is completed, a binding operation is performed to store the pairing key and the control terminal device identification information to form a binding relationship.

10. An electronic device, characterized in that: include: a memory, and one or more processors communicatively coupled to the memory; The memory stores instructions that can be executed by the one or more processors, and the instructions are executed by the one or more processors to enable the one or more processors to implement the method as described in any one of claims 1 to 7, or to enable the one or more processors to implement the method as described in claim 8 or 9.

Images