Protecting headless devices from malicious (re)configuration

Abstract

An illustrative embodiment includes: a headless medical device (S) for executing implementation of a medical resource or function (F) in the context of a configuration device (D); and an optional host device (H) for locking or unlocking a lock state (L) of the headless medical device relative to an action request related to the medical resource or function.

Description

[0001] This application claims the benefit of U.S. Provisional Application No. 62 / 622,984, filed on January 29, 2018, and entitled “SECURING HEADLESS DEVICE FROM MALICIOUS (RE-) CONFIGURATION.” U.S. Provisional Application No. 62 / 622,984, filed on January 29, 2018, is incorporated herein by reference in its entirety. Technical Field

[0002] The following generally relates to wireless medical sensors, low power wireless sensors, mobile sensors, and other similar applications. Background Art

[0003] In healthcare, the Internet of Things (IoT) is expected to bring many benefits, such as removing the clutter of wires and providing personal freedom of movement by applying wireless sensor and actuator devices. For example, wireless vital sign sensors can be connected to the hospital network to allow continuous uploading of vital sensor information, or to alert caregivers with alarms in the event of adverse events. Actuator devices such as drug delivery devices can be wirelessly connected to the hospital network to receive events to administer drugs and / or be configured (e.g., to change automatic dosage) for treatment.

[0004] The problem of wireless medical devices is to ensure the security of wireless communication. For patients to whom these wireless sensors or actuators are applied, malicious attacks on medical devices can be very harmful or even fatal. For example, if a wireless drug delivery actuator device (e.g., a wireless injection pump) can receive too many events to be able to administer the drug, or is maliciously (re)configured to the wrong dose for the patient, this can have fatal consequences. This is sometimes solved by using a short-range or proximity-based wireless protocol. However, short-range communication protocols such as Bluetooth have a range of up to about 20 meters, thereby providing enough space for malicious attacks. Proximity-based wireless protocols such as near-field communication (NFC) have a much shorter range, such as requiring a few centimeters of proximity, which can be considered safer. However, there is still a problem, wherein, after the medical device has been configured, it is still possible for someone with access rights to the patient (e.g., a non-staff visitor who enters when the patient is asleep) to reconfigure the device using the same proximity-based wireless protocol (e.g., NFC).

[0005] Another example of a malicious attack is a Bluetooth sensor, which can be subject to a man-in-the-middle attack. Here, the medical device is required to connect to the hacker's phone or other Bluetooth-equipped mobile device instead of connecting to the hospital network. In a man-in-the-middle attack, hospital staff may no longer be able to track the patient's vital signs (denial of service).

[0006] To prevent such man-in-the-middle attacks, a proximity-based out-of-band pairing method (e.g., NFC) can be used to configure the sensor with keys / pairing information. If this operation is performed by hospital staff, such as by using an authorized portable device in close proximity to the sensor to perform this NFC operation, this can be considered safe before it is applied to the patient. However, there is still a problem in that, after the sensor has been applied, it is still possible for someone with access to the patient (e.g., a non-staff visitor) to use the same proximity-based pairing method to set a different key into the sensor and take over the connection to the sensor using a rogue device (e.g., a Bluetooth-equipped cell phone).

[0007] Similarly, if a proximity-based wireless protocol (e.g., NFC) is used to configure the sensor device (e.g., frequency of sending measurements, destination IP address to send sensor data, wireless operating frequency), a malicious device could configure the sensor into an undesired operating state.

[0008] Certain improvements are disclosed below. Summary of the invention

[0009] In some illustrative embodiments disclosed herein, a device includes: a first communication interface for communicating with the device, a second communication interface for communicating with the device, a programmable electronic chip, and a non-transitory storage medium storing instructions, the instructions being readable and executable by the programmable electronic chip to operate a sensor or actuator or other medical function and perform a communication method. The communication method includes: controlling a lock state of the device via the second communication interface; receiving an action request related to the second communication interface or the medical function via the first communication interface; and executing the action request under the condition that the lock state is in an unlocked state. In some embodiments, the first communication interface includes a first radio (R1) operating according to a first wireless protocol, and the second communication interface includes a second radio (R2) operating according to a second wireless protocol; for example, the first radio may operate according to a near field communication (NFC) protocol, and the second radio may operate according to a Bluetooth protocol; or in other such embodiments, the first radio and the second radio may be two different virtual radios sharing the same physical radio transceiver hardware. In some alternative embodiments, one of the first communication interface and the second communication interface includes a radio, and the other of the first communication interface and the second communication interface includes a wired communication interface. In some embodiments of the disclosed device, the communication method also includes: when changing the lock state of the device to locked, performing one of the following actions: (a) deactivating the first communication interface; (b) enabling a firewall that blocks incoming messages on the first communication interface; or (c) ignoring any incoming action request messages on the first communication interface.

[0010] In some illustrative embodiments disclosed herein, a system includes: the device described in the previous paragraph; and a configuration device, the configuration device being configured to: when the lock state of the device is unlocked, send a security credential related to the second communication interface through the first communication interface. The device uses the credential to establish a secure communication channel on the second communication interface, and the device switches the lock state to locked. In some illustrative embodiments disclosed herein, the system includes the device and the configuration device as described in the previous paragraph, and the configuration device is configured to send an action request via the first communication interface and control the lock state of the device via the second communication interface. Any of the foregoing system embodiments may optionally also include a host device that cooperates with the configuration device to control the lock state of the device via the second communication interface.

[0011] Some illustrative embodiments disclosed herein include: a headless medical device for implementing a medical resource or function in the context of a configuration device; and an optional host device for locking or unlocking a lock state of the headless medical device in response to an action request related to the medical resource or function. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The invention may take the form of various components and arrangements of components, and may take the form of various steps and arrangements of steps.The drawings are only for the purpose of illustrating the preferred embodiments and are not to be construed as limiting the invention.

[0013] Figure 1 Diagrammatically illustrated is a headless medical device for executing implementation of a medical resource or function in the context of a configuration device, and an optional host device for authorizing the configuration device to lock or unlock a lock state of the headless medical device with respect to an action request related to the medical resource or function.

[0014] Figure 2-9 Diagrammatically shows the combination Figure 1 A method for appropriately implementing communication with a headless medical device.

[0015] Fig.10 Diagrammatically illustrates the Figure 1 An embodiment of a headless medical device includes a syringe pump.

[0016] Fig.11 Diagrammatically illustrates the Figure 1 An embodiment of a headless medical device includes a vital signs sensor. DETAILED DESCRIPTION

[0017] Many wireless protocols are vulnerable to malicious actors who have physical access or can get very close to the wireless medical device. Proximity-based authentication methods (such as NFC) are generally considered to be secure enough for use in payment transactions. However, these proximity-based authentication methods do not prevent unauthorized persons from misusing wireless medical devices. Authentication is used to verify the identity of a person or device attempting to access a specific resource. However, authentication is not the same as authorization, which is the function of enforcing access rights to a specific resource, and the authorization can be different for each person or device attempting to access the resource. For the example of a payment system, there are known identity verification and authorization protocols to avoid abuse. On many payment devices, the authorization problem is solved by managing several users on the device's operating system, each with their own access rights to certain privileged resources.

[0018] However, due to limited resources, storage space, lack of I / O modes for easy configuration or for providing login processes and feedback to users, it is very cumbersome and complicated to implement rules for many different users on simple devices such as low-cost, low-power wireless sensor or actuator devices. For example, in the medical context, many types of medical sensors or actuators are constructed as headless devices, where the device does not have a graphical user interface, but communicates with the outside world through an electronic data network link (e.g., Bluetooth, NFC, etc.). In some cases, the headless device may not include integrated input or output functions, and all communications are via one or more electronic data network links. In other embodiments, the headless device may include one or more simple input and / or output controls or devices, such as a reset button, a seven-bar LED display, etc., however, this is not sufficient to easily configure the headless device (instead, communication via one or more electronic data network links is required for full functionality).

[0019] For headless medical devices, adopting a security paradigm in which the device has multiple defined users (each with certain privileged resources) is difficult and cumbersome to implement. In fact, such headless medical devices are usually intended to be quickly and easily deployed to monitor patients or actuate certain treatments (such as intravenous drug delivery, etc.), and the need for complex user-specific authorization processes is contrary to this goal (for example, authentication may require entering a username and password via some user interface, which will first need to connect to the headless device via Bluetooth or other wireless connection). Therefore, for headless medical devices, only general rules are usually applied. For example, anyone in close proximity and / or anyone with a (single) password or verification code (passcode) may be allowed access to use or (re)configure the resources of the device.

[0020] As mentioned above, close proximity is not always sufficient protection, especially in the case of healthcare devices. This can usually be mitigated by building a shared secret (such as a password or verification code) at the factory. However, this increases the complexity of the manufacturing process because each device will have to be equipped with a different shared secret and makes the device less flexible to operate in different environments, and in addition, it is difficult to ensure the confidentiality of a single password or verification code that must be shared among all authorized users of the medical device. In order to mitigate unauthorized access to built-in shared secrets, it may be necessary to create tamper-proof hardware to prevent access to built-in storage devices, or to prevent the device's chipset from being used to process unusual things by affecting physical parameters. However, tamper-proof hardware adds a lot of additional complexity and cannot effectively prevent wireless attacks on headless medical devices. In the case of headless devices, wireless radios are the simplest and main "channel" to gain access to the device or configure the device to perform unauthorized operations.

[0021] Another factor that can influence the design of safety measures for headless devices is that there should be a balance between the complexity of these sensor / actuator devices and their power consumption, since some of these may even be implanted in the human body in the future.

[0022] refer to Figure 1 and Figure 2 In one embodiment, the headless device S operates security-sensitive resources / functions F (e.g., medical resources or functions, such as vital sign sensor functions, drug delivery functions, secure storage, secure wireless connections). The headless device S is equipped with a first wireless radio R1 operating a wireless protocol W1 and a second wireless radio R2 operating a wireless protocol W2. After initial configuration 10 of the second radio R2 to securely connect to a trusted network N, the device S switches 12 a lock state L to a locked state during which the device S stops 14 receiving messages from the wireless first radio R1, or during which the device S blocks any incoming action requests to be performed on the medical resource or function F received from any device D via the first radio R1 until after the wireless medical device S receives 16 a message via the second radio R2 allowing the reception of incoming action requests 18 from the device D while connected to the trusted network N. In other words, the second radio R2 is used to lock or unlock the lock state L of the medical device S regarding the ability of the medical device S to process action requests received via the first radio R1 for modifying the medical resource or function F.

[0023] By way of non-limiting illustration, in an example where the first radio R1 operates according to a Near Field Communication (NFC) protocol and the second radio R2 operates using a Bluetooth protocol, a request for an action to be performed on a medical resource or function F can include transmitting a password, verification code or other authentication secret (to perform an initial configuration 10 of the radio R2), configuring a patient identification (PID), adjusting a patient-specific operating parameter (e.g., injection rate), etc. For example, this can be accomplished using NFC using a negotiated BLE handover (Handover Request and Handover Select messages exchanged in NFC Forum peer-to-peer mode), such as using NFC. Secure Simple Pairing, application document, NFCForum-AD-BTSSP_1_1, 2014. The handover message based on the NDEF record may be extended with additional information fields (e.g. PID) as required by the application. When the lock state L is in the locked state, the medical device S may block incoming action requests to be performed on the medical resource or function F by being deactivated or turned off, or by enabling a firewall that blocks incoming messages on the first radio R1, or by being programmed to ignore any incoming messages requesting actions to be performed on the medical resource or function F when in the locked state.

[0024] While the lock state L is in the locked state, in some embodiments the first radio R1 may still be useful for sending outgoing messages 20, for example broadcasting an alarm message if a sensor determines that the second radio R2 is being attacked or misused.

[0025] refer to Figure 3 , a method for initiating configuration of a resource or function F is as follows. After receiving 30 an incoming request via a first radio R1 to perform an action of configuring a medical resource or function F, the wireless medical device S accepts 34 the incoming request via the first radio R1 to perform the action if the device is in an initial unconfigured state 32, after which the device S switches to a locked state 36. Thereafter, in order to make any further modifications to the medical resource or function F, the medical device S must be unlocked 38 using the second radio R2 with respect to such further modifications to the medical resource or function F.

[0026] In an illustrative embodiment, the first radio R1 employs a wireless protocol W1, which is a proximity-based wireless protocol (e.g., having a range of 10 cm or less in some embodiments), such as near field communication (NFC), Qi data communication, ISO / IEC 14443, and the second radio R2 employs a wireless protocol W2, which is a short-range wireless protocol (e.g., having a range of 50 meters or less), such as Bluetooth, IrDA, Zigbee, IEEE 802.15.4, or a medium-range protocol such as Wi-Fi, DECT (e.g., having a range of 100 meters or less), or a long-range protocol such as LTE Cat-M1, NB-IoT, LoRa (e.g., having a range greater than 100 meters). The incoming action request received by R1 for modifying a medical resource or function F may be, for example, an action request to store security credentials (e.g., a key, a public key, an X.509 certificate, a private key, a shared key, a long-term key) for performing a secure pairing of the radio R2 between the medical device S and a set of access points, small cells or base stations and / or connected devices that together form a closed trusted network N (e.g., a clinical network within a hospital) (e.g., LE secure pairing as defined in Bluetooth v4.2, WPA / WPA2 as defined in the Wi-Fi Protected Access specification / test plan, Diffie-Helman key exchange). If the second radio R2 is in an initial unconfigured state (or in other words, the lock state L is in an unlocked state at initial deployment), the device S accepts the incoming request on the first radio R1 to perform the action, and after the initial configuration, the device S switches the lock state L to the locked state and remains in the locked state until it receives an authentication message to unlock the first radio R1 through the second radio R2. It should be noted that when radio R2 is in an initial unconfigured state, device S should block or ignore any incoming secure pairing messages until after it has received security credentials C via R1, which enables the device to establish a secure connection with the trusted network N using the received security credentials C (i.e., Figure 2 Operation 10 of ). Note that this operation assumes that device D will be informed (via network N) of a set of access points, small cells or base stations to which device S will be able to connect, and the corresponding security credentials for pairing with device S.

[0027] Return to reference Figure 1 Also refer to Figure 4, another illustrative embodiment includes a system X including a headless device S and a configuration device D as described above. After the headless device S receives an incoming request 40 from the configuration device D via the first radio R1 to perform an action on a medical resource or function F, the device S confirms that the device D is part of the network N. In one embodiment, the device S issues a confirmation request message 42 via the second radio R2 targeting the device D. In one embodiment, the configuration device D displays the confirmation request 44 from the device S on its screen (i.e., display), after which the device D sends a confirmation response message 46 to the headless medical device S. The headless device S blocks the incoming action request 48 to modify the medical resource or function F received from the device D via the first radio R1 unless the headless device S receives a confirmation response message 50 from D via the second radio R2 that there is no problem accepting the incoming request. If the headless medical device S does not receive the confirmation message after several attempts 52, then in some embodiments, the device S begins broadcasting an alarm message 54, because this lack of confirmation suggests that the headless medical device S is vulnerable to attack. To implement this, it is again noted that the lock state being in the locked state does not (in some embodiments) block outgoing messages. In further optional aspects, the confirmation request may, when displayed on the configuration device D, reveal the history of treatment information managed by the medical device S in order to prevent replay attacks and handle wireless network failures that cause retries.

[0028] One illustrative method for confirming that the configuration device D can be reached via the network N uses the reverse ARP protocol or some automatic address translation (for example, in the case where the device operates both Wi-Fi Direct and Wi-Fi infrastructure connections, the device uses a different MAC address based on the same original MAC address built into the device using some bit flipping).

[0029] Return to reference Figure 1 And also refer to Figure 5 In a further optional aspect, the system X may include an additional host device H reachable via the network N. The host device H stores information 60 about the configuration device D, and the device S communicates with the host device D via a radio R2 (eg, Figure 16 (as indicated diagrammatically in FIG. 6 ) sends a request 62 to H to confirm that the configuration device D can be trusted and / or is part of the network. Device H can provide information 64 to device S, thereby confirming that device D is a trusted device and / or providing information about how to reach device D. The reason for this is that device D can be located in a different subnet (i.e., working with a different IP address range) because it may then use a different radio. In this case, an additional host device H can be employed to keep track of the devices in the network and store information about them, such as their address information in different subnets. Such a host device H (e.g., an AP controller) can also act as a bridging device. In particular, if the network N operates via Wi-Fi using IP addresses, and the configuration device D is connected to device S via Bluetooth, the host device H retrieves information about device D and how to reach it based on the Bluetooth address of device D rather than its IP address or its 802.11 MAC address.

[0030] Return to reference Figure 1 And also refer to Figure 6 , in another embodiment, after sending 70 a message to device S via radio R1, device D sends 72 a second message to device S via network N (e.g., a request for temporary unlocking), either directly or through a proxy via device H, after which, after receiving 74 the second message from device D from network N via radio R2, device S determines 76 that device D is part of network N and allows the incoming action request.

[0031] Return to reference Figure 1 And also refer to Figure 7 In another embodiment, an incoming action request 80 via the first radio R1 contains patient and / or physician information, and the medical device S contacts the host device H 82 via the radio R2 (eg, Figure 1 ) to verify that the configuration device D is allowed to be used for the physician's entitlements and / or for configuring the patient's treatment (e.g., by verifying that the received credentials match the physician's credentials). Only if this additional verification check is correct 84, the medical device S will perform an action 86 on the medical resource or function F. It should be noted that the credential can be a set of credentials or a chain of credentials for different caregivers (of different rankings). Device S can also be configured with special credentials to allow reconfiguration or (temporary) unlocking by another physician who is not registered with the host device H in an emergency. Device S can allow this operation to be performed via both radios R1 or R2, as long as device S can verify that the configuration device D used in the emergency is in possession of the special credential, for example, by using an authentication protocol (e.g. Diffie-Helman) via radio R1 or R2.

[0032] In a further optional aspect, the host device H can assist the headless medical device S in detecting the device currently being actively used by the physician and send a confirmation request message thereto.

[0033] In order to avoid losing connection with the trusted network N when an attempt to modify the medical resource / function F is received from some (e.g., inappropriate, such as a hacker) device (not shown), the following method can be adopted. If the headless device S receives a new configuration for communicating with the device D, it stores the old configuration and attempts to connect the configuration device to the trusted backend server (e.g., the known host H in the above system) using the new configuration. If this attempt fails, the new configuration is discarded, and the old configuration is retrieved from the storage (for properly configuring the device D), and the operation will be restored to the old configuration.

[0034] Return to reference Figure 1 And also refer to Figure 8 In another optional aspect, the configuration device D may discover 90 that the device S has its lock state L in a locked state (e.g., by outgoing a message via the first radio R1, or by pre-association service discovery information on the second radio R2, or by having the host device H store information about the lock state of the device S, which the configuration device D may later request). The configuration device D sends (or the device D requests the trusted host device H to send) an unlock message 92 to the medical device S via the second radio R2, and in response, the device S switches its lock state L to an unlock state 94 after receiving the message. In the case where the first radio R1 is not turned off, the unlocking may also be accomplished by closing the loop with the configuration device D via the second radio R2, or during initial configuration, the configuration device D sends a credential that the device S should store to enable unlocking, and the medical device S stores the credential, and after entering the locked state, the configuration device D requests the medical device S to switch from the locked state back to the unlocked state by sending a message containing the credential to the medical device S via the first radio R1 or the second radio R2.

[0035] Return to reference Figure 1 And also refer to Fig. 9 In a further optional aspect, the wireless medical device S repeats 102 on radio R2 all incoming traffic on radio R1 100 and sends it to the host device H for verification, and the host device H is equipped with a monitoring function to analyze the traffic 104. If the host device H detects abnormal traffic 106 (e.g., a replayed message), the host device H does not send a positive verification response to the wireless medical device S 108, or a request to shut down the first radio R1 to the device S. This method avoids overloading the medical device S during a denial of service (DOS) attack, and can prevent the execution of hacker algorithms (e.g., security code cracking algorithms).

[0036] In summary, a headless device S comprises two radios R1, R2 and maintains a lock state L that can be switched between a locked state and an unlocked state. In the locked state, the headless device S does not listen on one radio R1 for incoming requests from a configuration device or does not act on an action request to modify a medical resource / function F when in the locked state. By closing the loop with the configuration device D via communicating with the configuration device D on both the first radio R1 and the second radio R2, the disclosed method provides a simple and powerful mechanism to prevent malicious interactions with the medical resource / function F in the event that one of the radios is attacked, for example by verifying that the configuration device can be reached from a trusted network and requesting additional confirmation from the configuration device through a different network path. This makes it much more difficult to attack the medical resource / function F, as doing so would require attacking both radios R1, R2 simultaneously. Advantageously, the more vulnerable radio can be turned off after the initial configuration. In the illustrative example, this more vulnerable radio is NFC (the first radio R1 in the illustrative example), which is generally considered secure, but may not be sufficiently secure in a healthcare situation in case a malicious person can get close to the patient.

[0037] In some embodiments, symmetrical operation of the two radios R1, R2 is employed in the safety implementation, i.e., if radio R2 receives a request to take action on a medical resource or function F, radio R1 can be used to close the loop as already described in a similar case where radio R1 receives a request.

[0038] The wireless medical device S includes components such as a microprocessor, a microcontroller, a field programmable gate array (FPGA), a graphics processing unit (GPU), or other programmable electronic chip C (optionally multi-core, including a math coprocessor, or other enhanced version) and a non-transitory storage medium M storing instructions, which can be read and executed by the programmable electronic chip C to perform functions related to implementing medical resources or functions F and implement the device configuration protocol as disclosed herein. The non-transitory storage medium M may include (by way of non-limiting illustrative example) FLASH memory, read-only memory (ROM), electrically erasable programmable ROM (EEPROM) or variations thereof and / or magnetic storage media (e.g., hard disks), optical storage media (e.g., optical disks), various combinations thereof, and the like. The medical resources or functions F performed by the mobile medical device S depend on the type of device, and the device S may include additional components suitable for performing the medical resources or functions F.

[0039] refer to Fig.10For example, in the case where the medical device S includes an injection pump SIV, the device SIV includes suitable pump hardware PIV and a flow sensor FIV, etc., and the medical resource or function F may include functions such as controlling intravenous (IV) fluid flow, measuring IV fluid flow, measuring the temperature of IV fluid, and the programmable electronic chip C is programmed to implement the medical resource or function F, including operating the pump SIV based on flow feedback from the flow meter to deliver a controlled IV fluid flow, and optionally performing other related functions, such as monitoring IV fluid temperature, etc.

[0040] refer to Fig.11 As another example, in the case where the wireless medical device S includes a vital sign sensor SSEN, the device SSEN appropriately also includes sensor hardware SHW (e.g., EGC, EEG or HR monitoring electrodes, blood pressure cuff and inflation pump hardware, etc.), and the programmable electronic chip C is programmed to implement medical resources or functions F, including operating the sensor hardware to collect vital sign data.

[0041] These are merely non-limiting illustrative examples, and more generally, the wireless medical device may be further configured to provide (one or more) desired medical resources and / or perform desired medical functions. In addition, it is contemplated that the device S is a device for performing non-medical tasks in the context of non-medical applications. In the illustrative example, the device S is a headless device; however, alternatively, it is contemplated in other cases that the device S includes, for example, a graphical user interface (GUI) for user interface.

[0042] The radios R1, R2 each include components (not shown), such as a radio frequency transmitter and a radio frequency receiver (or integrated transceiver) operably connected to an antenna to send and receive signals according to a particular wireless communication protocol. It is worth noting that some wireless medical devices include two radios for other purposes, for example: both WiFi and Bluetooth connectivity may be included, and similarly, some wireless chipsets are equipped with two radios (e.g., Bluetooth / Wi-Fi combination chipsets / SoCs, such as many chipsets today). In the case of such a medical device, the two radios available can be used as the first and second radios R1, R2 as disclosed herein. The additional battery usage to achieve this is typically low because the second radio R2 only needs to be turned on when reconfigured (e.g., when a patient goes to a hospital for a visit), which may not occur often, and may be turned off during normal operation via R1.

[0043] As another variation, it will be appreciated that the two radios R1 , R2 may not necessarily be two physically distinct radios, but may be two distinct virtual radios sharing the same physical radio transceiver hardware.

[0044] As another variation, it will be appreciated that one or both of the two radios R1, R2 may be replaced by other types of communication interfaces, such as a wired communication interface such as a USB or microUSB port. In this case, the headless medical device S comprises an appropriate physical connector port (e.g., a USB or microUSB connector port), and the configuration device D also comprises an appropriate physical connector port (e.g., a USB or microUSB connector port) and is physically attached to the medical device S via an appropriate cable (e.g., a USB or microUSB cable) to establish a communication link corresponding to the replaced radio R1 or R2.

[0045] In summary, it will be appreciated that the disclosed security method employs a first communication interface for communicating with a medical device S (represented by a first radio R1 in the illustrative embodiment) and a second communication interface for communicating with the medical device S (represented by a second radio R2 in the illustrative embodiment), which is independent of the first communication interface.

[0046] The present invention has been described with reference to the preferred embodiment. After reading and understanding the above detailed description, others may think of modifications and changes. It is intended that the exemplary embodiments be interpreted as including all such modifications and changes as long as they fall within the scope of the appended claims or their equivalents.

Claims

1. A device for communication, comprising: a first communication interface for communication; a second communication interface for communication; Programmable electronic chips; as well as A non-transitory storage medium storing instructions that can be read and executed by the programmable electronic chip to operate a medical resource or function and perform a communication method including the following operations: initially configuring the second communication interface via the first communication interface to securely connect to a trusted network, and then switching the lock state of the device to a locked state for the first communication interface; and After initial configuration of the second communication interface: controlling the lock state of the device via the second communication interface; in response to an unlock message received via the second communication interface while the second communication interface is connected to the trusted network, changing the lock state from locked to unlocked; receiving, via the first communication interface, an action request related to modifying the medical resource or function; and The action request is performed under the condition that the lock state controlled via the second communication interface is in an unlocked state with respect to the first communication interface.

2. The device for communication according to claim 1, wherein: The first communication interface comprises a first radio operating according to a first wireless protocol; and The second communication interface includes a second radio operating according to a second wireless protocol.

3. The device for communication according to claim 2, wherein: The first radio operates according to a Near Field Communication (NFC) protocol and the second radio operates according to a Bluetooth protocol.

4. The device for communication according to claim 2, wherein: The first radio and the second radio are two different virtual radios that share the same physical radio transceiver hardware.

5. The device for communication according to any one of claims 1 to 4, wherein: The communication method further includes performing one of the following actions after the initial configuration of the second communication interface and after the second communication interface changes the lock state of the device to a lock state for the first communication interface: a) deactivating the first communication interface; b) enabling a firewall that blocks incoming messages on the first communication interface; or c) Ignore any incoming action request messages on the first communication interface.

6. A system for communication, comprising: A device for communication according to any one of claims 1 to 5; as well as A configuration device is configured to send security credentials related to the second communication interface through the first communication interface when the lock state of the device is an unlocked state for the first communication interface, and the device uses the credentials to establish a secure communication channel on the second communication interface in the initial configuration.

7. A system for communication, comprising: A device for communication according to any one of claims 1 to 5; as well as A configuration device is configured to send the action request via the first communication interface after the initial configuration of the second communication interface, and control the lock state of the device via the second communication interface.

8. The system for communication according to any one of claims 6-7, further comprising: A host device cooperates with the configuration device after the initial configuration of the second communication interface to control the lock state of the device via the second communication interface.

9. A method performed in conjunction with a medical device, the medical device comprising a first communication interface and a second communication interface for communicating with a device implementing the method, the method comprising: initially configuring the second communication interface via the first communication interface to securely connect to a trusted network, and then switching a lock state of the medical device to a locked state for the first communication interface; using the medical device to perform a medical resource or function; controlling a lock state of the medical device via the second communication interface of the medical device; in response to an unlock message received via the second communication interface while the second communication interface is connected to the trusted network, changing the lock state from locked to unlocked; receiving, via the first communication interface of the medical device, an action request related to modifying the medical resource or function; and The action request is performed using the medical device under the condition that the lock state of the medical device is in an unlocked state with respect to the first communication interface.

10. The method according to claim 9, further comprising, in the case of controlling the lock state of the medical device to change the lock state to a lock state for the first communication interface, performing one of the following: a) deactivating the first communication interface of the medical device; b) enabling a firewall that blocks incoming messages on the first communication interface of the medical device; or c) Ignoring any incoming action request messages received on the first communication interface of the medical device.

11. The method according to claim 9, further comprising: issuing a confirmation request message via the second communication interface of the medical device in response to receiving the action request via the first communication interface of the medical device, Therein, the unlock message is received via the second communication interface of the medical device in response to the issuing of the confirmation request message.

12. The method according to claim 9, wherein: The action request is received from a configuration device via the first communication interface of the medical device; and The unlock message is received from the configuration device via the second communication interface of the medical device.

13. The method according to claim 9, further comprising: storing information about the configuration device at the host device; wherein the action request is received from the configuration device via the first communication interface of the medical device, and The unlock message is received from the host device via the second communication interface of the medical device.

Images