Method and system for secure interoperability between medical devices

Abstract

This disclosure discloses a method for secure interoperability between an electronic device and a medical device. The method includes executing a control application configured to provide communication between the electronic device and the medical device, receiving user authentication data from an authentication service, receiving a key identifier from the medical device via an untrusted connection, and transmitting a message containing the user's identifier, the user authentication data, the key identifier, the control application's identifier, and an encrypted signature to an authorization service. The method further includes receiving a medical device encrypted key from the authorization service only in response to a successful authentication message, enabling at least one of control communication and data communication between the control application and the medical device.

Description

Technical Field

[0001] This disclosure generally relates to the field of secure communication for interoperability between electronic medical devices, and more specifically to secure communication for interoperability between medical devices used in artificial insulin delivery systems. Prior Technology

[0002] In the healthcare field, the use of portable medical devices is rapidly increasing, providing personalized healthcare to users in homes, workplaces, and other settings beyond traditional hospitals or clinics. Examples of these devices include, but are not limited to, continuous and spot blood glucose monitors, electronic medication delivery devices (including insulin pumps and smart insulin pens), health trackers, and fitness trackers. In many cases, medical devices are used in a "standalone" configuration, with the user operating the device independently without any substantial communication with other electronic devices. For example, some blood glucose monitors provide blood glucose level measurements, allowing patients with diabetes (PwD) or their caregivers to manually monitor the patient's blood glucose levels, but the monitor does not interact with other electronic devices to measure the PwD's blood glucose and provide the blood glucose measurement value. Recently, some medical devices have incorporated wired and wireless data connectivity, enabling them to transmit data (such as blood glucose measurements) to other computing and electronic devices. Furthermore, medication delivery devices such as insulin pumps or smart pens can receive commands from remote control devices to control the delivery of insulin or other medications.

[0003] The advent of medical devices with data connectivity capabilities has enabled further development of automated insulin delivery (“AID”) systems. While a detailed description of all aspects of AID is beyond the scope of this document, generally speaking, an AID system uses data collected from one or more continuous glucose monitors (CGMs) as input to a control system that controls insulin delivery to the PwD via an insulin pump. The AID system adjusts the level of insulin delivery so that the PwD can maximize the time spent “in-range,” which refers to the optimal range of blood glucose levels that improves the PwD’s health by minimizing the probability of hyperglycemia and hypoglycemia.

[0004] The exact configuration of an AID system can vary, but common configurations include a CGM, insulin pump, and control unit. The control unit receives blood glucose measurement data from the CGM and implements one or more algorithms to control the delivery of insulin from the pump, thereby controlling the PwD's blood glucose level over time. Of course, the CGM, insulin pump, and control unit need interoperability to deliver effective blood glucose levels to the PwD. As used herein, "interoperability" refers to an AID system component configured to process data and command messages from at least one other device in the system, such as a control unit configured to interpret blood glucose data and alert messages from the CGM and generate command messages in a format compatible with insulin pump operation. Some AID systems, including the CGM, insulin pump, and control unit, are manufactured by a single vendor to ensure interoperability, while other systems provide interoperability between components from different manufacturers.

[0005] While interoperability between components of an AID system is generally within the capabilities of the art, ongoing challenges remain regarding the information and operational security of AID systems. Two non-limiting examples of potential security issues include: unauthorized disclosure of data related to a patient's (PwD) blood glucose levels and insulin dosage; and an unsafe AID system potentially delivering incorrect insulin doses to the PwD through malicious control of the insulin pump. Existing technologies typically attempt to avoid these problems by strictly limiting the types of devices that can operate within an AID system. This results in extremely limited options for PwDs when selecting an AID system, or, alternatively, the potential for security vulnerabilities in AID implementations that do not enforce these limitations. Therefore, it would be beneficial to improve AID systems to achieve interoperability by enhancing the security between medical devices. Summary of the Invention

[0006] In one embodiment, a method for ensuring the interoperability of a secure medical device includes: executing a control application on a processor in an electronic device controlled by a user, the control application being configured to communicate with a medical device operated by the user; receiving user authentication data on the electronic device, the user authentication data being generated in response to a user authentication procedure; establishing an untrusted connection between the electronic device and the medical device; receiving a key identification code from the medical device via the untrusted connection on the electronic device; and transmitting a message to an authorized service on the electronic device, the message containing information about... Based on the user's identification code, user authentication data, key identification code, one of the identification codes of the control application, and one encrypted signature of the message, the encrypted signature is generated using a secret key stored in one of the memory of the electronic device; only in response to the successful authentication of the message authorizing the user and the control application, the electronic device receives a medical device encrypted key from the authorized service; and using the medical device encrypted key, a trusted connection is established between the electronic device and the medical device to enable at least one of control communication and data communication between the control application and the medical device.

[0007] In another embodiment, a method package for ensuring the interoperability of a secure medical device includes: receiving, via an authorization service, a message from an electronic device seeking authorization to control a medical device, the message containing information corresponding to an identification code of a user, user authentication information, a key identification code corresponding to a medical device encryption key stored in memory of the medical device, an identification code of a control application executed by the electronic device, and an encrypted signature of the message; and, via the authorization service, verifying the identification code of the control application and the encrypted signature of the message using the memory stored in the authorization service. The system uses a first encryption key to verify the authorization of the control application, which is associated with the identification code of the control application; using the authorization service, based on the data corresponding to the user's identification code and the user authentication data, a second encryption key stored in the memory of the authorization service is used to verify the user's authorization, which is associated with the authentication service; and using the authorization service, a device encryption key corresponding to the key identification code is transmitted to the electronic device, so that the electronic device establishes a trusted connection with the medical device only in response to successful verification of the authorization of the control application and the user's authorization.

[0008] In another embodiment, a method for ensuring the interoperability of a secure medical device includes: establishing an untrusted connection between a medical device and an electronic device; transmitting a key identifier corresponding to a public key and a private key associated with the medical device to the electronic device, the key identifier and the private key being stored in a memory of the medical device; establishing a trusted connection between the medical device and the electronic device only in response to a control application executed by the electronic device receiving the public key based on the key identifier, using the private key stored in a memory of the medical device; and performing an operation only in response to a command received from the control application in the electronic device via the trusted connection. Simple Explanation of the Diagram

[0009] The advantages, effects, features, and purposes beyond those described above will become more apparent when the following detailed description is considered. Such detailed description is illustrated in the following diagrams, wherein: Figure 1 is a schematic diagram of the system, which enables safe and interactive operation between user-controlled electronic devices and medical devices. Figure 2 is a schematic diagram showing the stored program instructions of the control application in the electronic device of Figure 1, as well as other data used and generated by the control application. Figure 3 is an illustrative embodiment of a message transmitted by an electronic device to an authorized service in the system of Figure 1. Figure 4 is a block diagram of a procedure for user and control application authentication and authorization, which establishes a trusted connection between the electronic device and the medical device in the system of Figure 1. Figure 5 is a block diagram showing the operation procedure for the authorized service in the program shown in Figure 4. Implementation

[0010] Priority Claim

[0011] This application claims the benefit of U.S. Provisional Application No. 63 / 041,603, entitled “Method and System for Secure Interoperability Between Medical Devices”, filed on June 19, 2020, the entire contents of which are incorporated herein by reference.

[0012] The following description will provide a better understanding of these and other advantages, effects, features, and objectives. In this specification, reference is made to the drawings, which form part of the invention, illustrating, rather than limiting, embodiments of the inventive concept. Corresponding reference numerals indicate corresponding portions throughout the various views of the drawings.

[0013] While the inventive concept allows for various modifications and alternatives, illustrative embodiments are shown by way of example in the drawings and described in detail herein. However, it should be understood that the following description of illustrative embodiments is not intended to limit the inventive concept to the specific forms disclosed, but rather is intended to cover all advantages, effects, and features falling within the spirit and scope of the invention as defined in the embodiments described herein and the following claims. Therefore, for the purpose of interpreting the scope of the inventive concept, reference should be made to the embodiments described herein and the following claims. Thus, it should be noted that the embodiments described herein may have advantages, effects, and features useful in solving other problems.

[0014] The apparatus, systems, and methods will now be described more fully below with reference to the accompanying drawings, which show some, but not all, embodiments of the inventive concept. In fact, the apparatus, systems, and methods may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided to enable this disclosure to meet applicable legal requirements.

[0015] Similarly, thanks to the teachings of the foregoing description and related drawings, those skilled in the art will conceive of numerous modifications and other embodiments of the apparatus, systems, and methods described herein. Therefore, it should be understood that the apparatus, systems, and methods are not limited to the specific embodiments disclosed, and modifications and other embodiments are intended to be included within the scope of the claims. Although specific terms are used herein, they are for general and descriptive purposes only and not for limiting purposes.

[0016] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. Although any methods and materials similar to or equivalent to those described herein may be used to implement or test the methods, preferred methods and materials are described herein.

[0017] Furthermore, the element referred to by the indefinite article "a" or "a" does not preclude the possibility of the existence of more than one element unless the context explicitly requires only one element. Therefore, the indefinite article "a" or "a" generally means "at least one". Similarly, the terms "having", "comprising", or "including" or any of their arbitrary grammatical variations are used in a non-exclusive manner. Thus, these terms can refer to either a situation where no further features exist in the entity described herein besides the features introduced by these terms, or a situation where one or more further features exist. For example, the statements "A has B", "A contains B", and "A includes B" can refer to a situation where no other element besides B exists in A (i.e., where A consists only of and exclusively of B) or a situation where one or more further elements (such as element C, element D, or even further elements) besides B exist in A.

[0018] Figure 1 illustrates a schematic diagram of system 100, which enables secure interoperability between a remote control application executed using electronic device 104 and a medical device 124 placed and communicating with electronic device 104. In the illustrative embodiment of Figure 1, system 100 includes electronic device 104, medical device 124, authorization service 154, and authentication service 174. Data network 140 enables communication between electronic device 104 and both authorization service 154 and authentication service 174. In the example of Figure 1, user 102 is a diabetic patient (PwD) or caregiver operating electronic device 104 and medical device 124.

[0019] More specifically, electronic device 104 includes electronic device processor 106 operatively connected to network device 108, input / output (I / O) device 110, and memory 112. While specific properties and operations of certain components in electronic device 104 relating to the establishment of a trusted connection with medical device 124 for secure interoperability are described in further detail herein, in at least some embodiments, electronic device 104 is embodied as a commercially available smartphone, tablet, personal computer, wearable device (such as a smartwatch or fitness tracker), or another suitable electronic device operated by user 102.

[0020] In electronic device 104, processor 106 is a digital logic element formed by one or more integrated circuits. This processor typically includes one or more central processing unit (CPU) cores and a graphics processing unit (GPU) to execute stored program instructions for implementing the operating system and application software, and to provide a graphical user interface through one or more display devices (not explicitly shown in FIG. 1). Among other software programs, an example of software executed by processor 106 during operation is a control application configured to transmit commands to and receive data from medical device 124. Processor 106 further incorporates a peripheral device and memory controller, which provides operability connectivity to network interface 108, I / O devices 110, and memory 112. In at least some embodiments, processor 106 includes a secure cryptographic processor that handles the secure storage of cryptographic keys in memory to maintain the confidentiality, isolation, and integrity of shared secret cryptographic keys, private cryptographic keys, and other non-public data. Additional components of processor 106 may include, as appropriate, a digital signal processor (DSP), an image processing unit, a neural network accelerator, an analog-to-digital converter, a digital-to-analog converter, and any other suitable digital and analog electronic components. For illustrative purposes, FIG1 shows processor 106, networking device 108, I / O device 110, and memory 112 as separate components; however, in some embodiments, processor 106 is implemented as a system-on-a-chip (SoC) configuration that incorporates some or all of the components of networking device 108, I / O device 110, and memory 112. []

[0021] In electronic device 104, network device 108 is a wired or wireless network transceiver that enables electronic device 104 to communicate with a remote computing system via data network 140. The remote computing system includes authorization service 154 and authentication service 174. Examples of network devices include wired network interface devices (such as Ethernet adapters) and wireless network devices. Wireless network devices include wireless local area network (WLAN) devices (such as IEEE 802.11 wireless network adapters) and wireless wide area network (WWAN) devices (such as modems for cellular or satellite networks). More typically, in system 100, network device 108 is a communication transceiver that enables communication via data network 140 using Internet Protocol (IP) or other suitable network communication protocols to provide communication with authorization service 154 and authentication service 174.

[0022] In electronic device 104, I / O device 110 is, for example, a wireless or wired I / O interface that provides a direct communication channel between electronic device 104 and an external computing device (such as medical device 124). Non-limiting examples of wireless I / O devices include Bluetooth transceivers implementing one or more of the Bluetooth family of communication protocols, including Bluetooth Low Energy (BLE) and Near Field Communication (NFC) adapters. Non-limiting examples of wired I / O devices include Universal Serial Bus (USB) adapters. Alternatively, alternative embodiments of I / O devices providing a compatible communication interface between electronic device 104 and medical device 124 may also be utilized.

[0023] In the embodiment of Figure 1, the configuration of I / O device 110 in electronic device 104 can be used for direct communication with the corresponding I / O device 130 in medical device 124. This point-to-point communication channel allows communication between electronic device 104 and medical device 124 without the need for a data network. Of course, those skilled in the art will recognize that embodiments of medical devices with network interfaces can communicate with electronic device 104 or other computing systems via a network (such as network 140), but in the illustrative embodiment of the AID system, using a direct communication connection between peripheral devices 110 and 130 is often preferred because such connections do not require network availability, and many practical direct communication I / O interfaces require less power to operate, which increases the effective operating time of battery-powered electronic and medical devices. []

[0024] In electronic device 104, memory 112 includes one or more volatile data storage devices (such as random access memory (RAM)) and non-volatile data storage devices (such as solid-state memory, magnetic media, or optical media) for storing programmed instructions and data to control the operation of electronic device 104. Specifically, FIG1 illustrates memory 112 storing control application instructions and data 114 (hereinafter referred to as "control application 114") configured to communicate with medical device 124. Memory 112 also stores: encryption device keys (such as public key 116 or shared secret encryption device key) received by electronic device 104 only in response to successful authentication and authorization of control application 114 and user 102 from authorization service 154; and user license 118 received by electronic device 104 only in response to successful authentication of user 102 from authentication service. Memory 112 further stores electronic device system software 120, which typically includes a commercially available operating system and system libraries, services, hardware drivers, and other applications stored in memory 112. In particular, in at least some embodiments, system software 120 provides an authentication application that enables user 120 to authenticate his or her identity using authentication service 174 without directly providing any private authentication information to control application 114. []

[0025] Figure 2 illustrates in more detail the program instructions and data included in or generated by the control application 114 during software packaging. The control application 114 includes stored program instructions 204 executed by the electronic device processor 106 to operate in conjunction with components of the electronic device 104 and other elements of the system 100. A global control application identifier 206 is an identifier (such as a numeric identifier, string identifier, or other data identifier) ​​corresponding to a publicly available identifier of the application software, which is universal across multiple installations of the control application (such as all executables of a particular application or all executables of a particular version of the application software). A local control application identifier 208 is another identifier, such as a numeric identifier, string identifier, or other data identifier, generated by the control application 114 during operation to serve as a unique identifier for a particular installation of the control application 114. The public / private key pair 210 includes a public key and a private key generated by the processor 106 using a predetermined key generation protocol, enabling the control application 114 to execute a key exchange protocol with the medical device 124 if the system 100 successfully completes the authentication and authorization described herein. The authorization message 300 includes data corresponding to the user's identification code, user authentication data, a key identification code, an identification code for the control application, and an encrypted signature transmitted from the electronic device 104 to the authorization service 154, as described in more detail below.

[0026] Referring again to Figure 1, the medical device 124 includes a medical device processor 126 operatively connected to one or more device components 128, I / O devices 130, and memory 132. In the medical device 124, the processor 126 is a digital logic element formed by one or more integrated circuits, typically including one or more CPU cores and, where appropriate, other digital processing components and analog processing components formed in an application-specific integrated circuit (ASIC) configuration. While those skilled in the art will recognize that the medical device processor 126 can be implemented using the same or similar components as the electronic device processor 106, in many practical embodiments, the medical device processor 126 is implemented with a narrower, more centralized design to ensure reliable operation of the medical device 124 and to reduce implementation costs and power consumption requirements. In at least some embodiments, the processor 126 includes a secure encryption processor that handles the secure storage of encryption keys in memory to maintain the confidentiality, isolation, and integrity of shared secret encryption keys, private encryption keys, and other non-public information. In medical device 124, device component 128 refers to additional components operated by processor 126 within the medical device, such as the pump motor in an insulin pump and a fluid sensor or a blood glucose sensing device in a CGM. I / O device 130 is another execution entity of the peripheral device, compatible with I / O device 110 to enable communication between medical device 124 and electronic device 104.

[0027] In medical device 124, memory 132 includes volatile and non-volatile data storage devices. Memory device 124 may be implemented using a Universal Integrated Circuit Card (UICC), microSD card, embedded Secure Element (eSE), or embedded UICC (eUICC), depending on the application. Memory 132 stores: program instructions 134; one or more device encryption keys, including private keys 136 or shared secret encryption keys that are unique to each individual executor of medical device 124 and stored in memory 132 at manufacturing time or during operation via a key derivation function; and one or more corresponding key identifiers 138 that correspond to one or more device encryption keys without revealing the contents of the device encryption keys. In the illustrative embodiment of FIG1, device encryption keys 136 include one or more private keys 136, each corresponding to a public key 160 stored in memory 156 of authorization service 154. In one embodiment, a key identifier 138 is generated by applying a cryptographically secure hash function to the public key corresponding to the private key 136, wherein the authorization service 154 stores the public key together with public key data 160, and the key identifier 138 is stored both in device memory 132 and in the memory of the authorization service 154 along with the device key identifier 138. In an alternative embodiment, the key identifier 138 is unique to each medical device, such as a universally unique identifier (UUID), a value generated by applying a cryptographically secure hash function to the medical device's private key 136 instead of the public key, or another value that uniquely identifies each medical device. In many medical device embodiments, the stored instructions 134 are implemented as device firmware to control the operation of the medical device 124, but no general software programs are provided for installation and operation on the electronic device 104 in a similar manner. Once again, while those skilled in the art will recognize that the configuration of a medical device can have a general-purpose processor and software, in many practical embodiments, more limited firmware implementations improve the operational reliability of the medical device 124 and reduce the hardware and power consumption requirements for the operation of the medical device 124. []

[0028] As described above, the authorization service 154 stores public keys 160, where each public key corresponds to a private key 138 in the medical device 124. The term "public key" as used herein has a slightly different meaning than its general meaning as used in the art, within the context of the public / private key pair used by each medical device 124. In the context of system 100, the public key 160 is initially known only to the authorization service 154 and is provided only to individual electronic devices (such as electronic device 104) in response to successful authentication and authorization as described herein. This differs from the general meaning of "public key," which refers to a key that is freely available worldwide ("public") and whose access is unrestricted. However, functionally, each medical device 124 has a pair of public and private keys that operate in the intended manner as public / private key pairs, used for data encryption / decryption, digital signature generation / verification, and key exchange protocols; in at least some embodiments, the key exchange protocols include, but are not limited to, elliptic curve Diffie-Hellman key exchange protocols. In alternative configurations, the device public key 160 and device private key 136 may be replaced by a single shared secret key used in a symmetric encryption system. Therefore, any reference herein to the device public key 160 and device private key 136 used in asymmetric encryption schemes should also be understood to apply to the shared secret encryption key used in symmetric encryption schemes.

[0029] In electronic device 104 and medical device 124, I / O interfaces 110 and 130 use the communication channels provided by these I / O interfaces to provide untrusted and trusted connections. The untrusted connection enables communication between the control application of electronic device 104 and medical device 124, but medical device 124 does not receive operable command messages from control application 114 and only provides access to publicly available data (such as device key identification code 138) to electronic device 104. If the control application 114 and user 102 successfully perform authentication and authorization in system 100 using the procedures described herein, the control application 114 in electronic device 104 responds with successful authorization using, for example, an elliptic curve Diffie-Hellman (ECDH) key exchange protocol in conjunction with the control application's public / private key pair 210, by establishing a trusted connection using the device public key 116 transmitted to electronic device 104 by authorization service 154. This trusted connection enables encrypted signing and encryption of data transmitted and received by I / O devices 110 and 130, thereby allowing the medical device processor 126 to ensure that commands and other data received from the control application 114 are trustworthy. After a trusted connection is established between the electronic device 104 and the medical device 124, the medical device processor 126 can accept commands transmitted from the control application 114 to the medical device 124 through the trusted connection. The medical device 124 can transmit data (such as information about the operating status of the insulin pump or glucose data generated by CGM) to the control application 114 through the trusted connection.

[0030] In system 100, licensed service 154 is a network-connected computing system implemented using one or more server computing devices. These server computing devices are implemented using commercially available hardware, including one or more server processors 170 and memory 156 comprising volatile RAM and non-volatile storage, including various combinations of solid-state drives and / or magnetic disks. Licensed service 154 is further connected to network 140 using, for example, Ethernet or other network adapters, to enable communication with remote computing devices including electronic devices 104. Licensed service 154 is implemented using dedicated hardware, virtualized servers, containerized servers, or any other suitable hardware configuration commonly known in the art. In licensed service 154, memory 156 stores program instructions 168, including, for example, operating system and server software executed by server processor 170 to implement the functions of licensed service 154. []

[0031] In the authorization service 154, memory 156 also uses a database or other suitable query structure to store device key identifiers 158, which are associated with public keys 160 corresponding to multiple medical devices. As is known in the art, each public key 160 stored in memory 156 corresponds to a private key 136 stored in memory 132 of a medical device 124. Device key identifiers 138 / 158 each correspond to a public / private key pair. In the illustrative embodiment of FIG1, the public / private key pair is an encryption key used with an elliptic curve cryptography scheme (including, for example, 224-bit, 256-bit, 384-bit, 512-bit, or any other suitable key size). However, alternative embodiments may employ keys used in conjunction with other forms of public key encryption, including but not limited to RSA, ElGamal, post-quantum asymmetric encryption schemes, etc. Each medical device 124 stores a personal private key 136 and a unique key identifier 138 for that specific medical device. The authorization service 154 stores a copy of the key identifier 138 along with key identifier data 158, which is associated with a unique public key 160 corresponding to the private key 136 in the medical device 124. Typically, due to the large number of medical devices, memory 156 generally stores multiple device key identifiers 158 and device public keys 160 corresponding to the unique private keys of multiple medical devices. []

[0032] In the authorization service 154, memory 156 also stores shared key and identification code data 162 for control applications. Shared key and identification code data 162 is, for example, a database or suitable query structure that stores shared encryption keys and identification codes for different approved control applications authorized to operate with medical device 124. After successfully completing the testing and verification process, the manufacturer of medical device 124 approves one or more control applications from a third-party developer to ensure that the control applications can operate medical device 124 in an approved manner. The medical device manufacturer generates and provides a shared secret key and a global control application identification code to the control applications. The control application developer then incorporates the shared secret key and global control application identification code into control application 114, enabling control application 114 to sign authorization messages, as described in further detail below. Authorization service 154 uses an appropriate shared secret key 162 to verify the authenticity of the signature from control application 114. In some embodiments, the developer obtains a different secret key and global application identifier for each new version of control application 114, and authorization service 154 deletes the shared key and global identifier of older versions of control application 114 to prevent authorization of older versions of control application 114. []

[0033] In the authorization service 154, memory 156 also stores a license verification key 164 and a user database 166. The license verification key 164 is an encryption key that enables the authorization service 154 to verify the authenticity of a user license. When user 102 successfully completes the authentication process to verify his or her identity, the user license is the data message generated by the authentication service 174. While the exact structure of a user license may vary depending on the implementation, generally each license includes: at least one piece of information that identifies user 102, such as a unique username, user ID, or email address; and a timestamp and encrypted signature for all information contained in the license. As described further below, after the authentication service 174 transmits the user license to the electronic device 104, the authorization service 154 receives the user license from the electronic device 104 as part of an authorization message. During operation, the authorization service 154 uses the license verification key 164 to verify the authenticity of the user license, thereby verifying the authenticity of the encrypted signature. Authorization service 154 also ensures that the timestamp data in the user license is sufficiently recent (e.g., stored for less than 60 seconds in a configuration), thereby ensuring that user licenses have been recently issued to prevent "re-execution" attacks that attempt to reuse old licenses by providing false user authentication data. Additionally, since authentication service 174 can verify users not registered with authorization service 154 in some configurations, authorization service 154 verifies whether the user identity in the user license corresponds to a previously registered user in user database 166. During the pre-registration process, user 102 provides the manufacturer with necessary information so that the manufacturer can contact user 102 using information about medical device 124 to ensure user safety, and user database 166 stores user identification codes and registration information. []

[0034] In system 100, authentication service 174 is another network-connected computing system implemented using one or more server computing devices. This network-connected computing system is implemented using commercially available hardware, including one or more server processors (not shown) and memory 178, which includes both volatile RAM and non-volatile storage, including various combinations of solid-state drives and / or magnetic disks. Authentication service 174 can be implemented using specialized hardware, virtualized servers, or containerized servers known in the art.

[0035] In authentication service 174, memory 178 stores user authentication database 182, which contains identification information for users, including user 102, as well as information necessary to verify user identity during the authentication process. Authentication service 174 allows user 102 to perform an authorization process based on a user identification code combined with, for example, a password, an encrypted signature generated by user 102 and a predetermined private key, a code generator, two-factor authentication, or any other suitable authentication procedure. In some configurations, user 102's authentication process can be automated using account credentials already stored in electronic device memory 112. For example, some smartphone devices provide user account information corresponding to user 102, and electronic device 104 can provide this account information to authentication service 174 to automate the user authentication process without requiring additional manual input from user 102. Authentication service 174 responds to successful authentication by using license signing key 184 to generate an encrypted signature for the resulting license, and authorization service 154 subsequently uses license verification key 164 to confirm the encrypted signature. In the embodiment of FIG1, both license signing key 184 and license verification key 164 are a single shared secret key used by authentication service 174 and authorization service 154. In another embodiment, in a public / private key pair, license signing key 184 is a private key and license verification key 164 is the corresponding public key. In the embodiment of FIG1, license signing key 184 and license verification key 164 are used to establish a specific trust relationship between authorization service 154 and authentication service 174, and authentication service 174 may store additional license signing keys for establishing trust relationships with other services, as appropriate. Accordingly, in system 100, each signed user license from authentication service 174 indicates that user 102 has successfully completed the authentication process of authentication service 174 for use by authorization service 154.

[0036] Figure 1 illustrates authentication service 174 as a service independent of authorization service 154, where authorization service 154 is under the control of the manufacturer of medical device 124, while authentication service 174 is a collaborating service with a trust relationship to authorization service 154. In another configuration, authentication service 174 is also controlled by the manufacturer of medical device 124, although the operation of the two embodiments is substantially the same.

[0037] While Figure 1 illustrates a single medical device 124 for illustrative purposes, in some configurations, a control application 114 in electronic device 104 establishes trusted connections with two or more medical devices 124 using the procedures described herein. In a non-limiting example of an AID system, the first medical device is an electronic drug delivery device, such as a drug pump that delivers insulin, glucagon, a combination of insulin and glucagon, or other medications to user 102, while the second medical device is a continuous glucose monitor (CGM) that provides measurements corresponding to the user's blood glucose levels. In this example, both the control application and the drug pump establish separate trusted connections with the CGM. The drug pump and CGM may be manufactured by a single manufacturer or by different manufacturers. In particular, in one configuration, the control application 114 receives authorization from two different implementers of an authorization service 154, which enables a single control application 114 to interact with medical devices from multiple manufacturers. For ease of operation, in systems where multiple device manufacturers utilize compatible user authentication services, user 102 only needs to authenticate himself or her using a single authentication service 174, simplifying the operation of the AID system for user 102. In the context of PwD, another electronic drug delivery device could be an insulin injector or glucagon injector that receives dosage instructions from a control application, which could be referred to as a "smart pen." The control software transmits commands to the smart pen to set the dosage of the drug injected into the PwD to control blood sugar. Other medical devices include spot blood glucose meters that generate a single instance during each use, or fitness trackers that measure various vital signs of user 102 in addition to instances, and the control application 114 establishes a trusted connection with the fitness tracker to receive sensor data corresponding to the vital signs of user 102.

[0038] Figure 4 illustrates a program 400 for establishing a trusted connection between electronic devices and medical devices in system 100 for user and control application authentication and authorization. In the following description, references to the operation of program 400 and control application 114 refer to the operation of one or more processors 106 and 126 in conjunction with the operation of other components in electronic device 104 and medical device 124 to achieve the described operations.

[0039] During procedure 400, the developer of control application 114 packages software and data within the control application for distribution, including stored program instructions 204 and other general program instructions, as well as a global control application identifier 206 and a shared secret key 212 that enable control application 114 to generate encrypted signatures for verification by authorization service 154 (block 404). Procedure 400 continues to install control application 114 in memory 112 of electronic device 104 (block 408). To enhance the confidentiality of shared secret key 212, the installer may, as appropriate, store shared secret key 212 in a secure portion of electronic device memory 112 in embodiments of electronic device 104, the electronic device including an encryption processor to support the secure storage of encrypted key data. In one embodiment, control application 114 generates a local control application identifier 208 and a public / private key pair 210 as part of the installation program, although in other configurations, control application 114 generates these items at a later time before use during execution of control application 114. Although not explicitly described herein, in at least one embodiment, the developer places the packaged control application 114 in an online application store, which user 102 and electronic device 104 access via data network 140 to retrieve and install control application 114. In other embodiments, user 102, a healthcare provider, or other entity receives the application package, and the application is installed on electronic device 104.

[0040] During procedure 400, user 102 uses electronic device 104 to perform an authentication operation to receive user authentication data (block 412) from authentication service 174. As described above, electronic device 104 provides services such as a web browser or other dedicated authentication software applications, allowing user 102 to provide a username and password or any other information required by the authentication process without providing sensitive information to the currently unauthorized control application 114. Communication between electronic device 104 and authentication service 174 via network 140 is encrypted and authenticated using protocols such as Transport Layer Security (TLS) or other suitable communication protocols to prevent third parties from receiving private information provided by user 102 to authentication service 174 for authentication purposes. Since the authorization data does not include plaintext secret data related to user 102, electronic device 104 receives authentication data from authentication service 174 in response to successful authentication and provides the authentication data to control application 114. In the embodiment of FIG1, user authentication information is implemented as a user license 118 stored in the electronic device memory 112. As described above, in one embodiment of system 100, the user authentication license 118 contains user authentication information, which includes at least a user identification code from authentication service 174, a timestamp, and an encrypted signature of the license.

[0041] During process 400, during the manufacture of the medical device 124 or during operation after manufacture, the medical device receives one or more unique private encryption keys 136 and corresponding key identifiers 138 (block 416) in memory 132. In some configurations, memory 132 stores multiple encryption keys 136 and corresponding key identifiers 138, which can be used to associate the medical device 124 with different partner control applications, or to enable the medical device 124 to operate in different modes in different geographic areas where different groups of control applications are approved for use. Those skilled in the art will recognize that during operation, multiple unique private encryption keys 136 can also be generated from the unique private keys via, for example, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, or any other suitable key derivation function. As described above, in one embodiment, the device private key 136 is a private key used in an elliptic curve cryptography scheme, and the medical device key identifier 138 is the output of a cryptographically secure hash function applied to the public key 160 corresponding to the medical device private key 136. Additionally, during the manufacture of the medical device 124, or at other times before the use of the medical device 124, the authorization service 154 receives a copy of the medical device key identifier 138 and the corresponding public key for storage together with the medical device key identifier data 158 and the medical device public key data 160, respectively.

[0042] When user 102 receives medical device 124 and cooperates with medical device 124 to execute control application 114 in electronic device 104 to establish an untrusted connection, procedure 400 continues (block 420). As described above, the untrusted connection enables communication between electronic device 104 and medical device 124 through I / O devices 110 and 130, respectively. However, medical device 124 does not accept commands from control application 114 through the untrusted connection and only provides publicly accessible data (such as device key identification code 138) through the untrusted connection. Non-limiting examples of untrusted connections include connections formed by Bluetooth pairing operations between electronic device 104 and medical device 124, where electronic device 104 cannot access the medical device's public key data 116 or an untrusted USB connection. After establishing an untrusted connection, electronic device 104 receives a medical device key identification code 138 (block 424) transmitted by medical device 124 through the untrusted connection. The order of operations shown in Figure 4, regarding user authentication (block 412) and receiving the medical device key identification code (blocks 420 to 424) through the untrusted connection between electronic device 104 and medical device 124, is presented for illustrative purposes, and these operations can occur in any order or simultaneously.

[0043] When the control application 114 and electronic device 104 use data network 140 to generate an encrypted signature authorization message and transmit it to the authorization service 154, process 400 continues (block 428). As described above, message 300 contains data corresponding to the user's identification code, user authentication data received from authentication service 174, key identification code, control application identification code, and encrypted signature of the message.

[0044] Figure 3 illustrates an example of the form of the authorization message 300 in more detail. In Figure 3, the authorization message 300 includes a user identification code and user authentication data 304, a medical device key identification code 138, control application identification code data (including a global application identification code 206 and, depending on, a regional application identification code 208), and an encrypted signature 308 corresponding to the entire contents of the rest of the message 300. For example, the user identification code and authentication data 304 includes the user license 118 of Figure 1. In one embodiment, the user license 118 contains an identification code of user 102, which is identified in the user database 166 of the authorization service 154; while in other embodiments, the user identification code is a separate data item that is still linked to the data in the user license 118 in a manner that enables the authorization service 154 to verify the identity of user 102.

[0045] In the embodiment of Figure 3, the user identification and authentication data 304 also includes a timestamp that identifies the time when the user authentication data was generated and, due to the cryptographic signature 308, identifies the remainder of the message 300 by signing the entire message 300. However, in another embodiment, the message 300 includes one or more additional timestamp fields that are part of the message covered by the cryptographic signature 308, so that the authorization service 154 can verify the retention period of the message 300, thereby reducing or eliminating "re-execution" attacks that attempt to provide the authorization service 154 with older but otherwise valid messages.

[0046] In message 300, the medical device key identifier 138 is the same identifier received by electronic device 104 from medical device 124 via an untrusted connection. Control application identifier data fields 206 / 208 enable the authorization service 154 to identify a specific type of control application 114, and in some embodiments, a specific version of control application 114. Region application identifier data 208 also enables the authorization service 154 to track the specific executor of control application 114 and provide further security by rejecting authentication messages containing copies of previously used region application identifiers.

[0047] In one embodiment, electronic device 104 uses a secret key 212 and a cryptographic hash function to generate a message signature 308 that utilizes a hash message authentication code (HMAC) corresponding to a user identification code and user authentication data 304, a device key identification code 138, and a control application identification code 206 / 208. Authorization service 154 verifies the HMAC signature using a copy of the shared cryptographic key 212 stored in database 162 by the authorization service. Alternative embodiments utilize a different form of cryptographic signature than HMAC. Of course, the format of message 300 is presented for illustrative purposes, and alternative configurations may use different formats to include additional information regarding the control application 114's use of the cryptographic key for signing.

[0048] During procedure 400, the authorization service 154 receives message 300 transmitted from electronic device 104 and performs a verification procedure for the authorization of both control application 114 and user 102. Figure 5 shows the verification procedure 500 in further detail. In the following description, reference to the operation of procedure 500 and authorization service 154 refers to the authorization service processor 170 working in conjunction with other components in authorization service 154 to implement the above-described operations.

[0049] During procedure 500, the authorization service 154 receives a message from the electronic device 104 via data network 140 (block 504). The authorization service 154 verifies the content of the message using a shared secret key corresponding to the global application identifier data contained in the message (block 508). More specifically, as described above, message 300 contains global application identifier data 206. The authorization service 154 identifies the corresponding shared secret encryption key in the control application / shared key database 162 and uses the retrieved key to confirm that the content of the message corresponds to an encrypted signature for a specific control application 114, thereby successfully verifying the control application 114. This prevents the control application 114 or another entity from altering the content of message 300 or forging another message without access to the shared secret encryption key 212. Furthermore, in some embodiments, the authorization service 154 disables older versions of the control application 114 to ensure that only the latest version of the control application 114 can successfully complete the verification process. In these embodiments, the authorization service 154 stores a different application identifier and a corresponding shared encryption key for each version of the control application 114. The authorization service processor 170 deletes the application identifier and encryption key corresponding to a version of the control application 114 that can no longer be used with the medical device 124 from the database 162 or otherwise disables them.

[0050] As part of verifying the message content, the authorization service 154 also uses the medical device key identifier 138 in message 300 and the corresponding device key identifier 158 to search for the public key stored in the public key database 160 to ensure that the public key corresponding to the medical device 124 is available. This operation is part of the message verification process to confirm that the electronic device 104 has received the valid medical device key identifier 138 contained in message 300. Additionally, in some embodiments, the system 100 enables only a single control application 114 to receive the public key corresponding to a single medical device 124 and control the operation of the medical device 124 throughout its entire lifecycle, particularly for medical devices with relatively short operating lifespans (e.g., days or weeks). In this configuration, after a single successful operation of procedures 400 and 500, the authorization service 154 deletes or otherwise invalidates the key identification code and public key corresponding to the medical device 124 to prevent the same public key from being issued multiple times.

[0051] During procedure 500, the authorization service 154 also uses the encryption key corresponding to the authentication service 174 (such as the license verification key 164 in system 100) to verify the user identification and authentication information (such as the user license 118 shown in system 100) included in the message (block 512). The user license 118 is generated by the authentication service 174 and is independent of the encryption signature used for the entire message 300. Verification of the encryption signature of the user license enables the authorization service 154 to verify the identity of user 102 and ensure that the control application 114 or another entity has not tampered with the contents of the user license 118. In addition, the authorization service 154 verifies the contents of the user license 118 to confirm that the user license 118 and any other associated user identification information correctly identify the user registered in the user database 166, and to confirm that the timestamp included in the user license 118 is recent enough to successfully verify the identity of user 102.

[0052] During procedure 500, if the authorization service 154 successfully completes message signing and content verification to authenticate the control application and the user based on user authentication data (block 516), then the authorization service 154 transmits the public key stored in the public key database 160 using the data network 140, which is used to provide a key identification code to the electronic device 104 (block 520). In system 100, a TLS or other encrypted and authenticated network connection between the electronic device 104 and the authorization service 154 prevents the public key from being exposed to the supplier. As described in more detail below, if the electronic device 104 receives the medical device's public key 116, then the electronic device 104 and the medical device 124 can establish a trusted connection so that the control application 114 can perform command and data retrieval communications with the medical device 124. However, if the authorization process fails for any reason related to any problem with the validity of the control application authorization, user authorization, or message content, the authorization service 154 does not transmit the public key to the electronic device 104, and the control application 114 cannot continue with the procedure 400 (block 524) described below. Although not described in more detail herein, in some embodiments, the authorization service 154 stores a log of any invalid authorization requests and, if such invalid request may indicate that the authorized party is attempting to operate the medical device 124 without proper authorization, generates an email or other communication alert for the user 102 as appropriate.

[0053] As described above, the authorization service 154 stores the necessary user database data 166 and the shared key and key identification code 162 for the control application to perform authorization for both user 102 and control application 114. Accordingly, apart from receiving the medical device private key 136 and medical device key identification code 138, it is not necessary to pre-program the medical device 124 with control application-specific or user-specific authorization data during its manufacture. This allows the authorization service 154 to, for example, provide authorization to new control applications created after the manufacture of the medical device 124, or revoke access to previously authorized control applications before execution program 500 without any modification or reconfiguration of the medical device 124.

[0054] Referring again to Figure 4, if electronic device 104 receives the public key 116 transmitted from authorization service 154 in response to successful authorization, or does not receive the public key in response to unsuccessful authorization (block 432), procedure 400 continues. If electronic device 104 does not receive the public key 116, medical device 124 continues to reject control requests from control application 114 and electronic device 104 (block 436). If medical device receives the public key 116, control application 114 uses the public key 116 stored in memory 112 in conjunction with the control application's public / private key pair 210 to establish a trusted connection with medical device 124 via I / O devices 110 / 130 (block 440). In the illustrative embodiment of Figure 1, electronic device 104 transmits the public key of the control application in public / private key pair 210 to medical device 124 to ensure that medical device 124 can access the public key of control application 114. After sharing the two public keys, electronic device 104 and medical device 124 establish a trusted connection using, for example, an elliptic curve Diffie-Hellman key exchange protocol or other suitable key generation communication protocol that generates a shared secret key shared only between electronic device 104 and medical device 124. This shared secret key enables control application 114 to use processor 106 to cryptographically sign and encrypt command messages, and enables medical device processor 126 to cryptographically sign and encrypt data transmitted to electronic device 104. Additionally, the medical device processor 126 uses a shared secret key to verify the authenticity of command messages; and the medical device 124 can continue to operate to execute commands received from the control application 114 for control communication, and provide measurement data to the control application 114 for data communication through a trusted connection.

[0055] While the above-described procedure 400 includes an authorization procedure that grants authorization to the combination of user 102 and control application 114 of electronic device 104, those skilled in the art will recognize that different simplified variations of this procedure are also disclosed in procedure 400. For example, one configuration of procedure 400 omits the authentication of user 102 as described in reference block 412. In this embodiment, control application 114 generates and transmits a signature authorization message 300 that omits user authentication data 304, and authorization service 154 similarly performs authorization of control application 114 in procedure 500, but does not attempt to authorize user 102. This simplified embodiment reduces the requirement for user 102 to provide information to authentication service 174 and authorization service 154, and further supports automation of execution in procedures 400 and 500. Furthermore, in this simplified embodiment, system 100 may omit the authentication service 174 and data structures (including, for example, user license 118, license verification key 164, and user database 166) required for user authentication in electronic device 104 and authorization service 154.

[0056] As described above, the embodiments described herein provide improvements to ensure secure interoperability between control applications and medical devices. Specifically, the embodiments described herein enable a third-party control application, not established by the medical device manufacturer, to gain access to the medical device while still maintaining security to prevent unauthorized control of the medical device. In at least some configurations, the medical device manufacturer can use authorization service 154 to authorize or revoke access to the control application without requiring any updates to the medical device 124. Furthermore, the embodiments described herein provide authorization for the control application and the user of the electronic device supporting the control application, further enhancing security and providing interoperability between devices in AID systems and other personalized healthcare systems.

[0057] This disclosure is described in conjunction with embodiments that are considered to be the most practical and preferred. However, these embodiments are presented by way of illustration, and this disclosure is not intended to limit one to the disclosed embodiments. Therefore, those skilled in the art will recognize that this disclosure includes all modifications and alternative configurations within the spirit and scope of this disclosure and within the scope of the appended claims.

[0058] 158: Device Key Identification Code 164: License Verification Key 160: Public Key Repository 166: User Database 162: Controls applications to share the key and key identifier. 168: Stored Program Instructions 156: Memory 170: Service Processor 154: Authorized Services 102: User 104: Electronic Devices 106: Electronic Device Processor 108: Network Devices 112: Memory 118: User License 114: Control Application 116: Public Key 120: Electronic device system software 110: Input / Output (I / O) Devices 130:I / O device 134: Stored instructions 136: Device Privacy Key 138: Device Key Identification Code 132: Memory 126: Medical Device Processor 128: Device Components 124: Medical Devices 140: Internet 184: License Signing Key 182: User Authentication Database 178: Memory 100: System 174: Verification Service 204: Stored program instructions 206: Global Control Application Identifier 208: Area Control Application Identifier 210: Public / Private Key 212: Control application / authorization service share password 300: Message 304: User ID and User Authentication Information 138: Device Key Identification Code 206 / 208: Identification code for control application 308: Encrypted Signature 404: Square 408: Square 412: Square 428: Square 432: Square 440: Square 416: Square 400: Program 420: Square 424: Square 436: Square 504: Square 508: Square 512: Square 516: Square 524: Square 520: Square 500: Program

Claims

1. A method for interoperability of a secure medical device, comprising: executing a control application on a processor of an electronic device controlled by a user, the control application being configured to communicate with a medical device operated by the user; receiving user authentication data on the electronic device, the user authentication data being generated in response to a user authentication procedure, the user authentication procedure further comprising: receiving authentication input data from the user on the electronic device, the authentication input data not being provided to the control application; transmitting an authentication request corresponding to the authentication input data on the electronic device to an authentication service; and receiving the user authentication data as a user authentication token from the authentication service on the control application, the user authentication token being received in response to a successful authentication by the user based on the authentication request; establishing an untrusted connection between the electronic device and the medical device; and receiving a key identification code from the medical device on the electronic device through the untrusted connection. The electronic device transmits a message to an authorized service, the message containing data corresponding to an identifier of the user, user authentication data, a key identifier, an identifier of the control application, and an encrypted signature of the message, the encrypted signature being generated using a secret key stored in a memory of the electronic device; only in response to successful verification of the message between the authorized user and the control application, the electronic device receives a medical device encrypted key from the authorized service; and using the medical device encrypted key, a trusted connection is established between the electronic device and the medical device, enabling at least one of control communication and data communication between the control application and the medical device.

2. The method of claim 1, wherein the user authentication license contains the user's identification code and the user authentication information.

3. The method of any one of claims 1 to 2, wherein the generation of the encrypted signature further comprises: using the secret key and a cryptographically secure hash function to generate the encrypted signature as a hash message authentication code (HMAC) corresponding to the user's identifier, the user authentication data, the key identifier, and the identifier of the control application.

4. The method of any one of claims 1 to 2, wherein the medical device encryption key is a public key corresponding to a private key stored in a memory of the medical device.

5. The method of claim 4, wherein the establishment of the trusted connection between the electronic device and the medical device further comprises: generating a public key and a corresponding private key for the control application using the control application; transmitting the public key to the medical device; and executing a key exchange protocol to establish the trusted connection between the control application and the medical device based on the public key, the private key, the public key, and the private key of the medical device.

6. The method of any one of claims 1 to 2, wherein the medical device encryption key is a common secret encryption key that is the same as a common secret encryption key stored in one of the memories of the medical device.

7. The method of any one of claims 1 to 2, wherein the electronic device is a smartphone.

8. The method of any one of claims 1 to 2, wherein the medical device is selected from the group consisting of an insulin pump, a continuous glucose meter, a spot blood glucose meter, and an electronic drug delivery device.

9. A system for the interoperability of a secure medical device comprising a medical device, an electronic device, an authorization service and an authentication service, the system being configured to perform the method of any one of claims 1 to 8.

Images