Secure communication in medical monitoring systems

Abstract

This provides a method for secure communication between medical sensors and computer devices. [Solution] In one embodiment, a method for secure communication between a medical sensor and a computer device includes the step of the medical sensor receiving an authentication request from the computer device. The method includes the step of generating a challenge-response message for the computer device based on the values ​​provided in the authentication request. The method includes the step of receiving a responded challenge-response message from the computer device. The method includes the step of verifying that the responded challenge-response message contains expected values ​​and corresponds to an expected format. In response to the step of verifying the responded challenge-response message, the method includes the step of sending a sensor secret value to the computer device.

Description

Technical Field

[0001] (Priority) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 072,647, filed Aug. 31, 2020, under 35 U.S.C. § 119(e), which is incorporated herein by reference in its entirety.

[0002] (Technical Field) The disclosed subject matter relates to secure exchange of data between a medical device with low computing power or resources and other devices including, but not limited to, personal computer devices, interface devices, remote servers, or other medical devices.

Background Art

[0003] Certain medical devices can wirelessly transmit and receive data with other computer devices. Some of these medical devices are equipped with powerful processors and operate using an uninterruptible power supply, while other medical devices are designed to operate efficiently with little power. Low-power medical devices may also have less computing power or resources than the devices they communicate with. In some cases, low-power devices may transmit and receive confidential data, such as a patient's personal medical information. For example, it may be difficult to protect confidential data from eavesdropping and tampering using the low computing power or resources characteristic of such low-power medical devices, including the low power medical device's ability to perform encryption or decryption processes.

[0004] Active medical sensors are an example of medical devices that can incorporate wireless communication capabilities. Medical sensors can collect private medical information about a user. After collecting data, the medical sensor can transfer the medical information to a more powerful device for data collection and analysis. Such features may include the medical device communicating data with other computer devices. In addition, or alternatively, some sensors can be physically connected to other devices to facilitate data transfer after being removed from the patient or while still connected to the patient, thereby restricting the patient's free movement. Wireless communication can be more convenient as it enables communication without physical connection to other devices. The challenge with such data communication is preventing interception by third parties. In the case of related medical devices, data security is desirable, as intercepted data may include the patient's health status, medical history, and other confidential information. Furthermore, tampering with intercepted data or device operation could lead to the provision of false medical information to the user.

[0005] Medical sensors can be designed to be disposable and low-cost, and such medical sensors may have less power or computing power compared to other devices when running data security algorithms to protect wireless communication. Therefore, there is an opportunity for methods and systems that can be implemented by low-power medical devices with limited computing power or resources to provide secure wireless communication and facilitate data transfer from such medical devices to other devices. [Overview of the project]

[0006] The objectives and advantages of the disclosed subject matter will be described and become apparent from the following description, as will be acquired through the implementation of the disclosed subject matter. Additional advantages of the disclosed subject matter will be realized and achieved by the methods and systems specifically indicated herein and in the claims, as well as from the drawings.

[0007] To achieve these and other advantages, the disclosed subject matter includes systems and methods for secure communication protocols for use by medical sensors, as embodied and extensively described in accordance with the objectives of the disclosed subject matter. An exemplary method may include the step of a medical sensor receiving an activation signal from a computer device. In response to the activation signal, the medical sensor may verify one or more authentication values ​​associated with the computer device. In response to successful authentication, the medical sensor may begin collecting sensor information from a patient. As embodied herein, the sensor information may include medical data relating to a patient. As embodied herein, the medical sensor may receive the activation signal via a near-field communication protocol that can provide radio power to one or more communication modules of the medical sensor. As embodied herein, the medical sensor may use the information received via the near-field communication protocol to establish a connection with a computer device via a second near-field communication protocol without requiring additional verification from a user, including but not limited to a patient. As embodied herein, a near-field communication protocol may include Near Field Communication (NFC), and a second near-field communication may include Bluetooth Low Energy (BLE). As embodied herein, a medical sensor may include computing resources that are not more powerful than those of a computer device.

[0008] According to other aspects of the disclosed subject matter, the system and method may include the step of a medical sensor receiving an authentication request from a computer device. The medical sensor may use the information contained in the authentication request to generate a challenge-response message for the computer device. The medical sensor may receive the responded challenge-response message from the computer device and further verify that the responded challenge-response message corresponds to the expected format and values. The medical sensor may then transmit a sensor secret to the computer device. As embodied herein, the sensor secret may include data and random values ​​specific to the medical sensor. As embodied herein, the random values ​​may be based on predefined values ​​provided to the sensor, values ​​generated by the medical sensor's communication module, or values ​​generated in response to user interaction. The medical sensor may encrypt one or more medical measurements using an encryption key derived from the sensor secret using a first cryptographic function and transmit the encrypted medical measurements to the computer device. As embodied herein, the encryption key may be used with a special low-power stream cipher or block cipher. The first cryptographic function may include performing an addition-rotation-XOR operation on the medical measurements. As embodied herein, the addition-rotation-XOR operation may include the steps of: segmenting unencrypted medical measurements into a series of data blocks; segmenting each data block into two or more words; and performing a series of additional operations on each data block. The additional operations may include: rotating the bits of the first word of the two or more words in the block by a first fixed amount; adding a second word of the two or more words in the block; performing a bitwise XOR operation of the first key on the first word; rotating the bits of the second word by a second fixed amount; and performing a bitwise XOR operation of the first word on the second word.As embodied herein, medical measurements may include body temperature, heart rate, blood glucose level, activity level, and other medical measurements.

[0009] According to other aspects of the disclosed subject matter, a system and method may include the step of receiving a set of medical measurements encrypted by a first computer device from a medical sensor using a sensor secret and a first key derived from a first encryption algorithm. The first encryption algorithm may include the step of performing an addition-rotation-XOR operation on the medical measurements. The sensor secret may include an intrinsic value associated with the medical sensor and a random value generated by the medical sensor. The method may include the step of the computer device deriving a first key based on the sensor secret. The method may include the step of the computer device decrypting the set of medical measurements using the derived first key. The method may include the step of encrypting the decrypted medical measurements using a second key and a second encryption algorithm. The second key may include information specific to the computer device and a random value generated by the computer device. The second encryption algorithm may be different and may be a computationally more complex encryption algorithm than the first encryption algorithm, as embodied herein. The method may include the step of transmitting the encrypted medical measurements to a second computer device. As embodied herein, encrypted medical measurements can be transmitted to a second computer device via wired or wireless communication. Encrypted medical measurements can be transmitted using packet-level coding computer protocols. As embodied herein, the method may include the step of the second computer device decrypting the encrypted medical measurements, encrypting the medical measurements with a third key and a third encryption algorithm, and then transmitting them to the third computer device, where the first, second, and third keys are all different and derived from different root values, and the first, second, and third encryption algorithms are all different. As embodied herein, the medical sensor may include computing resources that are not more powerful than those of the first computer device.The first computer device may contain computing resources that are less powerful than those of the second computer device.

[0010] Please understand that both the general description above and the detailed description below are illustrative and intended to provide further explanation of the disclosed subject matter.

[0011] The accompanying drawings incorporated herein and constituting part of this specification are included to illustrate the methods and systems of the disclosed subject matter and to provide further understanding. Together with the description, the drawings illustrate the principles of the disclosed subject matter.

[0012] Details of the subject matter described herein, both in terms of its structure and operation, can be made apparent by examining the accompanying drawings, in which similar reference figures refer to similar parts. [Brief explanation of the drawing]

[0013] [Figure 1] This figure shows an exemplary operating environment for a low-power medical monitoring system that can embody the technologies described herein. [Figure 2] Block diagram showing an exemplary sensor according to an exemplary embodiment of the disclosed subject. [Figure 3] A block diagram shows an exemplary dedicated data receiving device for communicating with a sensor, according to an exemplary embodiment of the disclosed subject matter. [Figure 4] This figure shows an exemplary structure of a message payload according to an exemplary embodiment of the disclosed subject matter. [Figure 5] This diagram shows an exemplary operation flow and data lifecycle of a low-power medical monitoring system. [Figure 6] This figure shows an example of a messaging response state machine based on the disclosed subject. [Figure 7A] This is a diagram illustrating an example of a mutual recognition scheme based on disclosed subject matter. [Figure 7B]This is a diagram illustrating an example of a mutual recognition scheme based on disclosed subject matter. [Figure 7C] This is a diagram illustrating an example of a mutual recognition scheme based on disclosed subject matter. [Figure 7D] This is a diagram illustrating an example of a mutual recognition scheme based on disclosed subject matter. [Figure 8] This figure shows an exemplary data flow for secure data exchange between two devices based on the disclosed subject. [Figure 9] This figure shows an exemplary data flow for secure data exchange between two devices based on the disclosed subject. [Modes for carrying out the invention]

[0014] Herein, embodiments of the present disclosure, of which one or more examples are illustrated in the accompanying drawings, will be described in detail. The structure of the disclosed subject matter and the corresponding operating methods will be described in conjunction with the detailed description of the system.

[0015] The systems and methods presented herein can be used for secure communication in medical monitoring systems. As an example of the disclosed subject matter, but not limited to such examples, this specification refers to secure communication using medical devices such as medical sensors. Where used herein, “medical sensor” can refer to any device capable of receiving sensor information from a user useful for medical purposes, such as a body temperature sensor, blood pressure sensor, pulse or heart rate sensor, glucose level sensor, analyte sensor, physical activity sensor, motion sensor, or any other sensor useful for medical purposes, but not limited to such examples. The purposes and advantages of the disclosed subject matter will be described and will become apparent therefrom. Additional advantages of the disclosed subject matter will be realized and achieved by the methods, apparatus, and devices specifically pointed out herein and in the claims, as well as from the accompanying drawings.

[0016] In one embodiment, a method for secure communication between a medical sensor and a computer device includes the step of the medical sensor receiving an authentication request from the computer device. The method includes the step of generating a challenge-response message for the computer device based on the values ​​provided in the authentication request. The method includes the step of receiving a responded challenge-response message from the computer device. The method includes the step of verifying that the responded challenge-response message includes expected values ​​and corresponds to an expected format. In response to verifying the responded challenge-response message, the method includes the step of sending a sensor secret value to the computer device.

[0017] According to the disclosed subject matter, for illustrative purposes only and not limiting, a method for secure communication between a medical sensor and a computer device. The exemplary method may include the step of the medical sensor receiving an activation signal from the computer device. In response to the activation signal, the medical sensor may verify one or more authentication values ​​associated with the computer device. In response to successful authentication, the medical sensor may begin collecting sensor information from the patient. As embodied herein, the sensor information may include medical data relating to the patient. As embodied herein, the medical sensor may receive the activation signal via a near-field communication protocol that can provide radio power to one or more communication modules of the medical sensor. As embodied herein, the medical sensor may use the information received via the near-field communication protocol to establish a connection with the computer device via a second near-field communication protocol without requiring additional verification from a user, not limited to a patient. As embodied herein, the near-field communication protocol may include Near Field Communication (NFC), and the second near-field communication may include Bluetooth Low Energy (BLE). As embodied herein, medical sensors may include computing resources that are not more powerful than those of a computer device.

[0018] According to other aspects of the disclosed subject matter, the system and method can include receiving an authentication request from a computer device by a medical sensor. The medical sensor can use the information included in the authentication request to generate a challenge response message for the computer device. As embodied herein, the challenge response message can be encrypted according to an agreed-upon encryption scheme. The medical sensor can receive the responded challenge response message from the computer device and can further verify that the responded challenge response message corresponds to an expected format and value. The medical sensor can then transmit a sensor secret to the computer device. The sensor secret can also be encrypted according to an agreed-upon encryption scheme. As embodied herein, the sensor secret can include data unique to the medical sensor and a random value. As embodied herein, the random value can be based on a predefined value provided to the sensor, a value generated by the communication module of the medical sensor, or a value generated in response to a user interaction. The medical sensor can encrypt one or more medical measurements using an encryption key derived from the sensor secret and transmit the encrypted medical measurements to the computer device. As embodied herein, the encryption key can be used with a special low-power stream cipher or block cipher. As embodied herein, the medical measurements can include body temperature, heart rate, blood glucose level, movement, and other medical measurements.

[0019] According to other aspects of the disclosed subject matter, a system and method may include the step of receiving a set of medical measurements encrypted by a first computer device from a medical sensor using a sensor secret and a first key derived from a first encryption algorithm. The sensor secret may include unique values ​​associated with the medical sensor and random values ​​generated by the medical sensor. The method may include the step of the computer device deriving a first key based on the sensor secret. The method may include the step of the computer device decrypting the set of medical measurements using the derived first key. The method may include the step of encrypting the decrypted medical measurements using a second key and a second encryption algorithm. The second key may include information specific to the computer device and random values ​​generated by the computer device. The second encryption algorithm may be different and may be computationally more complex than the first encryption algorithm, as embodied herein. The method may include the step of transmitting the encrypted medical measurements to a second computer device. As embodied herein, the encrypted medical measurements may be transmitted to the second computer device via wired or wireless communication. Encrypted medical measurements can be transmitted using a packet-level coding computer protocol. As embodied herein, the method may include the step of encrypting medical measurements with a third key and a third encryption algorithm, after which a second computer device decrypts the encrypted medical measurements and transmits them to the third computer device, where the first, second, and third keys are all different and derived from different root values, and the first, second, and third encryption algorithms are all different. As embodied herein, the medical sensor may include computing resources that are not more powerful than those of the first computer device. The first computer device may include computing resources that are not more powerful than those of the second computer device.

[0020] For illustrative purposes only, not limiting, exemplary embodiments of the medical monitoring system 100 for use with the disclosed subject matter, as shown in Figure 1, are referenced. Figure 1 shows an operating environment for the low-power medical monitoring system 100 that can embody the technology described herein. The low-power medical monitoring system 100 may include a system of components designed to provide monitoring of medical statistics relating to the human or animal body, or may provide other medical operations based on the configuration of various components. For example, the low-power medical monitoring system 100 may provide a user with continuous glucose monitoring, or may provide delivery of drugs and other pharmaceuticals. As embodied herein, the system may include a low-power medical device 110, also called a sensor, which is worn by a user or attached to the body from which information is collected. As embodied herein, the sensor 110 may be a sealed, disposable device to improve ease of use and reduce the risk of tampering, as further discussed herein. The low-power medical monitoring system 100 may further include a dedicated reading device 120, configured as described herein, to facilitate the acquisition and distribution of data, including medical data from the sensor 110. As embodied herein, the low-power medical monitoring system 100 may be incorporated into a multipurpose hardware device 130, such as a mobile phone, tablet, personal computer device, or other similar computer device, which may include a third-party licensed software library or application and communicate with the sensor 110 via a communication link. The multipurpose device 130 that embodies and runs the software library may be said to form a data receiving device for communicating with the sensor 110.As used herein, the dedicated data receiving device 120 refers to a hardware device specially manufactured to communicate with the sensor 110 within the low-power medical monitoring system 100, while the general-purpose data receiving device 130 refers to a properly configured hardware device incorporating a software library or running an application. As used herein, the data communication device equally refers to the dedicated data receiving device 120 or the general-purpose data receiving device 130. It should be understood that the security architecture and design principles discussed herein are equally applicable to any properly configured system including the low-power medical device 110, the properly configured dedicated data receiving device 120 or general-purpose data receiving device 130, and other components similar to those described herein. The role of the low-power medical device 110 can be defined by the nature of the medical hardware embodied in the low-power medical device 110.

[0021] Generally and at a high level, the low-power medical monitoring system 100 supports a minimally computed multi-factor (MCMF) scheme for generating authentication and cryptographic keys based on various additional elements, including a device identifier, a secret key maintained by the device and its manufacturer, and a true random value. Using this technology, the various devices of the low-power medical monitoring system 100 expend minimal computing resources to perform authentication and computing functions. Furthermore, the MCMF scheme does not require any device in the low-power medical monitoring system to have access to a wide-area network such as the Internet. Thus, the technology of this disclosure enables secure communication between low-power medical computer devices without substantially increasing data processing load and power requirements. Moreover, since the disclosed security architecture and operation reduce the computing cost of the constituent low-power medical monitoring system, the architecture can be adapted for use with various medical devices (e.g., instead of sensor 110), including low-cost or disposable ones such as certain auto-injectors, in-vivo injectors, and sensors. Throughout this disclosure, the low-power medical device 110 may be referred to as a sensor for simplification.

[0022] As embodied herein, the sensor 110 may include a small, individually packaged, disposable device having a predetermined active service life (e.g., 1 day, 14 days, 30 days, etc.). The sensor 110 may be applied to the skin of a patient's body and remain attached for the duration of the sensor's service life. As embodied herein, the sensor 110 may be designed to remain functional when selectively removed and reapplied.

[0023] For illustrative purposes only, not limiting, exemplary embodiments of sensor 110 for use with disclosed subject matter, as shown in Figure 2, are referenced. Figure 2 is a block diagram of exemplary sensor 110 in an exemplary embodiment compatible with the security architecture and communication scheme described herein. As embodied herein, sensor 110 may include an application-specific integrated circuit ("ASIC") 200 communicably coupled with a communication module 240. For illustrative purposes only, not limiting, exemplary communication module 240 may include a Bluetooth Low-Energy ("BLE") chipset, a Near Field Communication ("NFC") chipset, or other chipsets for use with similar near field communication schemes, such as a personal area network using the IEEE 802.15 protocol, the IEEE 802.11 protocol, or infrared communication using the Infrared Data Association Standard (IrDA). Communication module 240 may transmit and receive data and commands through interaction with a communication module having similar capabilities, such as a dedicated data receiving device 120 or a multipurpose data receiving device 130. As embodied herein, a specific communication chipset can be embedded in the ASIC 200 (e.g., an NFC antenna loop). As embodied herein, since the sensor 110 is designed to be power-efficient, low-cost, and potentially disposable, the ASIC 200 may include a microcontroller core 210, onboard memory 220, and storage memory 230. The storage memory 230 can store data used in the authentication and cryptographic security architecture disclosed herein. The data can have a variety of elements and applications, including those described in the embodiments herein. The ASIC 200 can receive power from a power module 250, such as an onboard battery, or from NFC pulses. The power module 250 can store only relatively small charges. As embodied herein, the sensor 110 can be a disposable device with a predetermined lifespan and no wide-area network communication capabilities.As embodied herein, the communication module 240 can provide communication under battery power. While this disclosure describes exemplary configurations of the sensor 110 and ASIC 200, other preferred configurations are envisioned. For example, the processing hardware of the sensor 110 may be implemented as another type of special-purpose processor, such as a field-programmable gate array (FPGA). As embodied herein, the processing hardware of the sensor 110 may include a general-purpose processing device (e.g., a CPU) or another programmable processor that is temporarily configured by software to perform the functions of the sensor 110. More generally, the processing hardware 30 may be implemented using hardware, firmware, software, or a suitable combination of hardware, firmware, and software. Exemplary but not limiting, the processing hardware of the sensor 110 may be defined by one or more factors, including computing power, power capacity, memory capacity, and network connectivity availability.

[0024] To perform its medical function, the sensor 100 may further include medical hardware 260 suitable for that function. As embodied herein, the medical hardware 260 may include, for example, an auto-injector prescribed to a patient for self-administration of a drug or other pharmaceutical. Thus, the medical hardware 260 may include a mechanism for driving the needle or plunger of the syringe to subcutaneously administer the drug. The syringe may be pre-filled with the drug and may operate in response to a trigger event. For example, the mechanism may drive the needle into the patient and advance the plunger to deliver the drug subcutaneously through the needle.

[0025] As embodied herein, the low-power medical device 110 can be configured as an on-body syringe that can be attached to the patient's body tissue (e.g., skin, organs, muscles, etc.) and is capable of automatically delivering a subcutaneous injection of a patient-selected amount of medication, fixed for a controlled or selected period of time. In such embodiments, the medical hardware 260 or low-power medical device includes, for example, an adhesive or other means for temporarily attaching the medical hardware 260 to the patient's body tissue, a primary container for storing medication or pharmaceuticals, a drive mechanism configured to drive a plunger to discharge medication from the primary container or to allow its release, a trocar (e.g., a solid core needle), a flexible cannula positioned around the trocar, an insertion mechanism configured to insert the trocar and / or flexible cannula into the patient and optionally retract the trocar leaving the flexible cannula inside the patient, a fluid path connector configured to establish fluid communication between the primary container and the flexible cannula when the device is activated, and an actuation device (e.g., a user-displaceable button) configured to activate the device. As embodied herein, the internal syringe can be pre-filled and / or pre-loaded.

[0026] In addition to mechanical components, the medical hardware 260 may include electrical and / or electronic components. For example, an electronic switch may be coupled to the mechanism. The low-power medical device 110 is capable of establishing authenticated communication, receiving encrypted signals, decoding the signals using the techniques of this disclosure, determining that the signals contain commands to operate a switch, and driving a needle to the switch. Thus, the low-power computer devices embodied herein can be configured to use the medical hardware 260 to perform medical functions in response to remote commands.

[0027] As embodied herein, the medical hardware 260 may include a motion sensor and an analog-to-digital converter for generating a digital signal indicating the distance traveled by a needle or plunger. When delivering a drug, the low-power medical device 110 may acquire measurements from the sensor, encrypt the measurements using the techniques of this disclosure, and securely report the measurements to the remote device 14. In addition, or alternatively, the low-power medical device 110 may report other measurements or parameters, such as the time the drug was delivered, the amount of drug delivered, and any problems encountered during drug delivery. The low-power medical device 110 may be configured to provide data associated with the operation of the medical hardware 260 to a remote device.

[0028] As embodied herein, the low-power medical device 110 can be configured to perform both the steps of receiving encrypted data from a dedicated data receiving device 120 or a multipurpose data receiving device 130 and transmitting encrypted data to the dedicated data receiving device 120 or the multipurpose data receiving device 130. The medical hardware 260 can be configured to implement any suitable combination of one or more medical functions and may include one or more sensing components. Such sensing components can be configured to detect the operating state of the low-power medical device 110 (e.g., unpackaged / ready to administer, sterile barrier removal, contact with patient's body tissue, insertion of cannula and / or needle, initiation of drug delivery, displacement of operating part or button, completion of drug delivery, plunger position, flow path occlusion, etc.), the state of the low-power medical device 110 or the drug contained therein (e.g., temperature, exposure to shock or vibration, light exposure, drug color, drug turbidity, drug viscosity, geographic location, spatial orientation, time information, ambient pressure, etc.), and / or physiological information about the patient (e.g., body temperature, blood pressure, pulse or heart rate, glucose level, physical activity or movement, fingerprint detection, etc.).

[0029] Referring further to Figure 1, the ASIC 200 of sensor 110 can be configured to dynamically generate authentication and cryptographic keys using data held in storage memory 230. The ASIC 200 can be further configured to perform authentication procedures (e.g., handshake, mutual authentication, etc.) using the received data and to apply the generated keys to sensitive data before transmitting the sensitive data to the dedicated data receiving device 120 or the multipurpose data receiving device 130 via the communication module 240. The generated keys can be specific to sensor 110, specific to a pair of devices (e.g., specific to a particular sensor-reader pair), specific to a communication session between sensor 110 and the dedicated data receiving device 120, specific to a message transmitted during the communication session, or specific to a block of data contained within a message. The technology implemented by the ASIC 200 of sensor 110 will be discussed in more detail herein.

[0030] For illustrative, not limiting, purposes, exemplary embodiments of a dedicated data receiving device 120 for use with the disclosed subject matter, as shown in Figure 3, are referenced. Figure 3 shows an exemplary dedicated data receiving device 120 compatible with the security and computer architecture described herein with respect to the exemplary embodiment. As embodied herein, the dedicated data receiving device 120 may include a small form factor device. The dedicated data receiving device 120 may optionally be less constrained in memory or processing power than the sensor 110, and as embodied herein, the dedicated data receiving device 120 may include sufficient memory for operational software storage and data storage, as well as sufficient RAM for software execution for communicating with the sensor 110 as described herein. As shown in Figure 3, the reader 130 includes an ASIC 300 including a microcontroller 310, memory 320, and storage 330, and is communicatively coupled to a communication module 340. As embodied herein, the ASIC 300 may be identical to the ASIC 200 of the sensor 110. Alternatively, the ASIC300 can be configured to include additional computing power and functionality. Power for the components of the dedicated data receiving device 120 can be supplied by a power module 350, which may include a rechargeable battery, as embodied herein, enabling sustained operation and continuous use.

[0031] The dedicated data receiving device 120 can be configured to wirelessly couple with the sensor 110 or to scan the sensor 110 and acquire data from it, such as sensitive medical data. As embodied herein, the dedicated data receiving device 120 may further include medical hardware 360 ​​similar to, or extended from, the medical hardware 260 of the sensor 110. Not limited to, but illustrative, in an embodiment in which the medical hardware 260 of the sensor 110 is configured for continuous glucose monitoring, the medical hardware 360 ​​of the dedicated data receiving device 120 may consist of a blood glucose meter compatible for use with blood glucose test strips, thus extending the blood glucose monitoring of the sensor 110. As embodied herein, the dedicated data receiving device 120 may be configured to operate as an NFC scanner and BLE endpoint with respect to the sensor 110 via a specific module of the communication module 340 (e.g., BLE module 341 or NFC module 342), as described herein. As embodied herein, the dedicated data receiving device 120 can be configured to communicate via the universal serial bus (USB) 345 of the communication module 340. As embodied herein, the onboard storage 330 of the dedicated data receiving device 120 is capable of storing medical data received from the sensor 110 for extended periods. Furthermore, as embodied herein, the multipurpose data receiving device 130 or the user computer device 140 can be configured to communicate with a remote cloud server 150 via a wide area network. As embodied herein, the sensor 110 can provide sensitive data to the dedicated data receiving device 120 or the multipurpose data receiving device 130. The dedicated data receiving device 120 can transmit sensitive data to the user computer device 140. The user computer device 140 (or the multipurpose data receiving device 130) can then transmit that data to the remote cloud server 150 for processing and analysis.When communicating with the cloud server 150, the multipurpose data receiving device 130 and the user computer device 140 can generate unique user tokens according to authentication credentials entered by the user and stored in their respective devices. These authentication credentials can be used to establish a secure connection to the remote cloud server 150 and, as appropriate, to encrypt any sensitive data provided to the cloud server 150. As embodied herein, the multipurpose data receiving device 130 and the user computer device 140 can optionally be less restricted in terms of processing power usage, and therefore, standard data encryption and transmission techniques can be used when transmitting to the remote cloud server 150.

[0032] Once the sensor 110 is successfully activated by a data receiving device (e.g., a dedicated data receiving device 120 or a multipurpose data receiving device 130), the sensor 110 can be configured to collect medical data and make that data available to the data receiving device. For example, the data receiving device can pair with the sensor 110 via an NFC interface, provide short-range power to the sensor 110, and be coupled to communicate with the sensor 110 via the NFC interface. Alternatively, the sensor 110 can be paired with the data receiving device via a corresponding communication module to transmit medical data used for medical monitoring and alarm functions. Data from the dedicated data receiving device 120 can be uploaded to, for example, a user computer device ("PC") 140 via the USB interface 345 of the dedicated data receiving device 120. The user computer device 140 can further transmit data to a cloud server 150. The USB connection can be authenticated at each plug event. Authentication can use a three-pass design with different keys, similar to the three-pass mutual authentication described herein with respect to Figure 4. The USB system can support various different sets of keys for encryption and authentication. Keys can be matched to different roles (clinical, manufacturer, user, etc.). Sensitive commands that could potentially leak security information can trigger authenticated encryption using an additional set of authenticated keys.

[0033] As used throughout this disclosure, Bluetooth Low Energy ("BLE") refers to a short-range communication protocol optimized for easy pairing of Bluetooth devices for end users. As described herein, the use of BLE on sensor 110 may optionally use application-layer encryption that uses one or more block ciphers to establish mutual authentication and encryption, rather than relying on Bluetooth's standard BLE implementation for security. The use of a non-standard encryption design implemented at the application layer has several advantages. One advantage of this approach is that a user can complete pairing of sensor 110 and dedicated data receiving device 120 simply by NFC scanning, without performing additional inputs such as entering a security pin or confirming BLE pairing between the data receiving device and sensor 110. Another advantage is that this approach reduces the possibility, at least in part, of allowing a device not in immediate proximity to sensor 110 to pair unintentionally or intentionally, since the information used to support the pairing process is shared over a short-range backup short-range communication link (e.g., NFC) rather than over a longer-range BLE channel. Furthermore, since BLE pairing and bonding schemes are not involved, pairing of the sensor 110 can avoid implementation issues by chip vendors or vulnerabilities in the BLE specification.

[0034] The data collected by sensor 110 and exchanged between sensor 110 and the data receiving device is highly sensitive and beneficial to protect because it is associated with medical information about the user. Medical data associated with a patient is highly sensitive because, at least in part, this information may be used for a variety of purposes, including health monitoring and medication decisions. In addition to patient data, the low-power medical monitoring system 100 can implement security hardening against external parties' efforts for reverse engineering. The security architecture described herein may include, but is not limited to, protection of inter-device communications, protection of intellectual property within components and applications, and protection of secrets and primary keying materials. As embodied herein, encryption and authentication can be used as two of the primary technical controls for providing protection. As embodied herein, various components of the low-power medical monitoring system 100 may be configured in accordance with security interfaces designed to protect the confidentiality, integrity and availability ("CIA") of this communications and associated data. To address these CIA concerns, the following security features can be incorporated into the hardware and software design of the low-power medical monitoring system 100.

[0035] As embodied herein, to facilitate data confidentiality, a communication connection between any two devices (e.g., sensor 110 and dedicated data receiving device 120) can be mutually authenticated before either device transmits sensitive data. The communication connection can be encrypted using device-specific or session-specific encryption keys. As embodied herein, encryption parameters can be configured to change for each data block of communication.

[0036] As embodied herein, to ensure data integrity, encrypted communication between any two devices (e.g., sensor 110 and dedicated data receiving device 120) can be verified by a transmission integrity check incorporated into the communication. As embodied herein, session key information that can be used to encrypt the communication can be exchanged between the two devices after each device has been authenticated. Encrypted communication between sensor 110 and dedicated data receiving device 120 (or an application running on multipurpose data receiving device 130) can be verified by an error detection code or error correction code, including, as an example and not limited to, an unsecure error detection code, minimum distance coding, repeating code, parity bit, checksum, cyclic redundancy check, cryptographic hash function, error correction code, and other suitable methods for detecting the presence of errors in a digital message.

[0037] As embodied herein, minimum distance coding includes a random error correction code that provides a strict guarantee regarding the number of detectable errors. Minimum distance coding involves selecting a codeword to represent a received value that minimizes the Hamming distance between the value and its representation. Minimum distance coding, or nearest neighbor coding, can be assisted using standard arrays. Minimum distance coding is considered useful when the probability of an error occurring does not depend on the position of a given symbol and the error can be considered an independent event. These assumptions can be particularly applied to transmissions over binary symmetric channels.

[0038] Furthermore, or alternatively, as embodied herein, repeating codes are associated with encoding schemes that repeat bits across a channel to ensure that communication messages are received error-free. Given a stream of data to be transmitted, the data is divided into blocks of bits. Each block is transmitted and retransmitted any predetermined number of times. If any transmission of a repeated block is different, an error is detected.

[0039] In addition, or as a further alternative, as embodied herein, a checksum is a value for a message based on the modular arithmetic sum of fixed-word-length message codewords. The checksum can be inferred from the entire message or a block of messages. The checksum is generated using a checksum function or cryptographic hash function configured to produce significantly different checksum values ​​(or hash values) for minor changes to the message in question. A parity bit is a bit added to a set of bits at transmission to ensure that the resulting count of a particular bit is even or odd. For example, a parity bit can be used to ensure that the number of bits with the value 0 is odd. A parity bit can also detect a single error or a certain number of recurring errors. A parity bit can be considered a special case of a checksum.

[0040] As embodied herein, in order to further reduce the risk of compromise of individual devices and the low-power medical monitoring system 100, the root key (e.g., the key used to generate a device-specific key or session-specific key) may optionally not be stored on the sensor 110 but encrypted in storage on a dedicated data receiving device 120 (which may have additional processing power to decrypt the key as needed). As embodied herein, the root key may be stored in an obfuscated manner to prevent third parties from easily accessing the root key. The root key may also be stored in different encryption states depending on where it is stored in storage. For example, the root key may be stored unencrypted in a region of memory that is inaccessible to third parties (e.g., due to other read and write locking mechanisms).

[0041] As embodied herein, to facilitate data availability, the operation of sensor 110 can be protected from tampering during its service life, during which it can be designed as disposable, by restricting access to write functionality to memory 220 via communication interfaces (e.g., BLE and NFC). Access to read functionality to memory 220 can also be enforced, in particular, when the read functionality attempts to access specific areas of memory 220 designated as secure or sensitive. Furthermore, sensor 110 can be configured to advertise and become connectable only when it is disconnected from its paired dedicated data receiving device 120. Sensor 110 can also block communication connection requests that do not complete authentication within a specified time, in order to protect against certain denial-of-service attacks on the communication interface. Furthermore, the general authentication and encryption designs described herein can support interoperable use, where the data of sensor 110 can be made available to other "trusted" data receiving devices without being permanently tied to a single device.

[0042] As embodied herein, communications in the low-power medical monitoring system 100, including sensitive data such as medical data or security parameters described below, are subject to authentication. Commands associated with such communications are re-authenticated for each operation as a three-way handshake implementing a challenge-response mechanism. For example, and as embodied herein, a challenge request can be sent, and a response containing challenge parameters is returned. The next request is in the form of an authentication token incorporating the challenge parameters of the first party and presenting the challenge parameters of the second party.

[0043] In the authentication scheme, mutual authentication between the sensor 110 and the data receiving device can be protected by a device-specific cryptographic key stored in the sensor 110 and derived from a personalization value received by the data receiving device. Furthermore, mutual authentication can be protected by a pre-shared device-specific key between the sensor 110 and the data receiving device. Upon successful authentication, the sensor 110 can transmit a randomly generated sensor-specific key. The sensor-specific key can be used as the base key for a stream cipher or a block cipher. As embodied herein, the input to the cipher can be changed for each encrypted block.

[0044] Mutual authentication between the dedicated data receiving device 120 and the user computer device 140 can occur via wired or other wireless communication. Communication between the dedicated data receiving device 120 and the dedicated application running on the user computer device 140 can be mutually authenticated. Cryptographic keys for authentication and communication exchange can be derived from root keys incorporated into the dedicated data receiving device 120 and the application encryption library.

[0045] The message payload between sensor 110 and data receiving device can be encrypted with a device-specific key. A device-specific key makes it difficult to attempt meaningful alteration or interception of message content, as a breach of a single device-specific key would allow a malicious party to decrypt message payloads from that device, but it cannot be used to decrypt message payloads from other devices. As embodied herein, for efficiency, the encryption implementation can use the counter mode of a block cipher as a stream cipher. In such a mode, a single bit flip in a message results in the corruption of a single bit message. Such corruption using counter mode and stream ciphers can be mitigated by verifying the integrity of message transmission with an error detection code of appropriate length.

[0046] For illustrative purposes only, not limiting, exemplary embodiments of message payload structure for use with the disclosed subject matter, as shown in Figure 4, are referenced. Figure 4 shows an example of message payload structure according to an exemplary embodiment. In the example shown in Figure 4, an error detection code is calculated over the entire message 410, including the plaintext command code 420 and the encrypted payload 430. An error detection block 440 appended to the communication block 400 can be used to ensure the integrity of the message 410.

[0047] The sensor operation can be protected from tampering for its service life via the communication module 240 through two complementary approaches. Firstly, the ability to write to the sensor 110's memory 220 (including software) via a communication interface (e.g., NFC) can be disabled at manufacturing. Ports on the ASIC for debugging and reprogramming can be selectively deactivated based on the activation security state of the sensor 110. In addition or alternatively, and as embodied herein, the sensor 110 can be configured without the ability to support write functionality via other communication interfaces (e.g., BLE).

[0048] As embodied herein, the sensor 110, the dedicated data receiving device 120, and the multipurpose data receiving device 130 can each employ various security practices to ensure the confidentiality of data exchanged over the communication session and to facilitate the associated devices finding trusted endpoints and establishing connections. For example, the sensor 110 can be configured to advertise and enter a connectable state, for example, via a BLE interface, when it becomes disconnected from the paired dedicated data receiving device 120. The sensor 110 can enter a connectable state for a predetermined period of time at regular intervals, for example, for 2 seconds every 2 minutes. The sensor 110 can further reject and block a connection request if the requester cannot complete its own login procedure on the communication interface within a predetermined period (e.g., within 4 seconds). These characteristics protect against certain denial-of-service attacks, particularly against denial-of-service attacks against the BLE interface. As embodied herein, the identifier used to connect to the sensor 110 may be modifiable to reduce the ability to track a single sensor 110 to connect to one or more data receiving devices. The connection identifier for sensor 110 or the data receiving device may include, as an example only, a unique or semi-unique device identifier, the media access control address of the device's communication module, a device address configured for a specific communication protocol (e.g., a Bluetooth address), an Internet Protocol address, an identifier assigned to the device by a low-power medical monitoring system, a universally agreed identifier for the type of device broadcasting, etc. Sensor 110 may change its identifier between activation and pairing with the first dedicated data receiving device 120. If sensor 110 disconnects from the first dedicated data receiving device 120 during its active usage timeline, sensor 110 may change its connection identifier at the time of disconnection or upon receiving a new connection request with the second dedicated data receiving device 120.

[0049] In addition, or alternatively, the connection identifier may be modified according to the connection type or based on the encryption capabilities of the communication protocol and may be supported by a multipurpose data receiving device 130 or a dedicated data receiving device 120. As embodied herein, the representation of the connection identifier may be modified using one or more cryptographic functions before the connection identifier is broadcast by a device (e.g., by a sensor 110 or a data receiving device). The device may operate in a privacy mode in which several functions are performed simultaneously to mask and secure the connection identifier in order to reduce the risk that the connection identifier may be uniquely associated with a broadcasting device. One such function may include randomizing the aspect of the connection identifier before broadcasting. The connection identifier may also be encrypted with an agreed-upon cryptographic function and public key. Then, only devices that possess the corresponding private or shared private key, know the type of cryptographic function used, and can deterministically decrypt the randomization effect will be able to identify a particular device. As embodied herein, these levels of cryptographic security may be implemented at the application layer or higher infrastructure layer of the communication protocol.

[0050] As embodied herein, the sensor can support the establishment of long-term connection pairs by storing encryption and authentication keys associated with a data receiving device, or the data receiving device can support the long-term storage of encryption and authentication keys for the sensor 110. For example, the sensor 110 or the data receiving device can associate the connection identifier of the other party in exchange with the encryption and authentication keys used by the other party. In this way, the sensor 110 can establish a connection with the data receiving device more quickly, as it can, at least in part, avoid establishing a new authentication pairing with the data receiving device and proceed directly to exchanging information via the encrypted communication protocol described herein. After a connection is successfully established, the two devices can refrain from broadcasting the connection identifier and other information to establish a new connection and can communicate using an agreed-upon channel-hopping scheme to reduce the opportunity for a third party to listen in on the communication. As another example, the sensor 110 can be configured to scan for available connection points and prefer to connect with devices it has already connected with, such as devices with which it has previously established an authenticated exchange. This process can reduce the chances of a malicious third party intercepting the authentication exchange when other trusted data receiving devices are within range.

[0051] In addition or alternatively, the sensor 110 and data receiving device can support the use of a whitelist for known trusted devices. For example, a user who intends to use multiple sensors 110 over the lifespan of a data receiving device can register connection identifiers associated with multiple sensors, or register a range of connection identifiers. Similarly, the sensor 110 can be configured with trusted connection identifiers or ranges of connection identifiers (e.g., protected values ​​associated with a dedicated data receiving device 120 or multipurpose data receiving device 130 belonging to a particular user). Thus, when establishing a connection, the sensor 110 and data receiving device can compare the connection identifiers associated with available connection points with connection identifiers stored in a whitelist. The whitelist can represent an exclusive range, meaning that no connection identifiers other than those included in the whitelist will be used. Alternatively, the whitelist can represent a preferred range, where the whitelist is searched first, but other devices may still be used. As embodied herein, the sensor 110 and data receiving device can be configured to verify the identity of a device accepted via any of the shortcut procedures described above and to disconnect and reject future connections with devices suspected of providing invalid identifiers and authentication addresses.

[0052] Certain commands compatible with sensor 110 can be referenced at least in part based on the level of security used before executing the command. For example, certain commands can be called “open” or “unauthenticated” commands. Such commands may include those that do not result in any modification to sensor 110 or the extraction of sensitive medical information, such as retrieving the battery status indicator of sensor 110 or retrieving information to initiate authentication. Other commands may be called “authenticated” commands. Such commands may include those that result in the collection of sensitive data. As embodied herein, the communication path between sensor 110 and the data receiving device can be re-authenticated for each authenticated command. As embodied herein, the low-power medical monitoring system 100 can be designed as a so-called “fail-open” system, allowing a user with multiple data receiving devices to use any of the data receiving devices instead of establishing an exclusive binding. For example, exclusive binding would prevent a user from activating and authenticating on, for example, a first data receiving device and then using an unpaired second data receiving device to receive medical data. Such use cases are desirable for supporting third-party multipurpose data receiving devices 130.

[0053] Next, the high-level security architecture of the low-power medical monitoring system 100 will be described with reference to Figure 5. Figure 5 shows an exemplary embodiment of the operation flow and data lifecycle 500 of the low-power medical monitoring system 100 for use with the disclosed subject matter. In step 510, the manufacturer 160 selects information that can be used to generate an encryption key for each device. As embodied herein, the information may include a secure root key for the sensor 110 and optionally a dedicated data receiving device 120, which can be used in combination with device-specific information and operational data (e.g., entropy-based random values) to generate an encryption value specific to the device, session, or data transmission, as needed. In step 520, the manufacturer may assign a unique identifier ("UID") to each sensor 110. The manufacturer may further assign other identification information to each sensor 110, such as the manufacturer's identifier, the communication module and manufacturer's identifier, or any other appropriate identification information for the sensor or sensor component. For example, the UID of each sensor 110 can be derived from sensor-specific data, such as a serial number assigned to each ASIC 200 embodied in the sensor 110 by the ASIC vendor, a serial number assigned to the communication module 240 embodied in the sensor 110 by the communication module vendor, or a random value generated by the sensor manufacturer. In addition or alternatively, the UID can also be derived from manufacturing values ​​that include a lot number of the sensor 110 or its components, the manufacturing date, date or time of the sensor 110 or its main components, the manufacturing location, process or line of the sensor or its main components, and other information that can be used to identify when and how the sensor was manufactured. The UID may be accompanied by an encryption key that is also unique to each sensor 110 and several generated random values. In step 530, the manufacturer may provide each dedicated data receiving device 120 with data including a root key that can be used, for example, to derive a data encryption key for the purpose of facilitating communication.

[0054] In step 540, the sensor 110 can collect medical data, such as from a patient or user 140 (e.g., the body of a human or animal). For example, the sensor 110 can collect data at predetermined intervals upon activation by a properly configured dedicated data receiving device 120. In step 550, the sensor 110 can transmit medical data to the dedicated data receiving device 120 via a communication interface (e.g., via NFC, BLE, etc.) through its communication module 240. In addition to medical data, the sensor 110 can transmit additional information to facilitate exchange in accordance with a selected protocol. For example, the message payload from the sensor 110 to the dedicated data receiving device 120 may include manufacturer unique values, manufacturer identification values, sensor identification values, and transmission power level values. As embodied herein, the power level value can be defined on a range established by the selected communication interface (e.g., on a range of 0 to 20). The power level value can be used by the dedicated data receiving device 120 to request the sensor 110 to rebroadcast the data or to perform future data transmissions at a higher power level. For example, sensor 110 can be located at a distance from a dedicated data receiving device 120, where ensuring the integrity of communication can be difficult. The dedicated data receiving device 120 can send instructions to sensor 110 to divert more power to sensor 110's communication model 240 in order to ensure that the transmission is delivered intact.

[0055] In step 560, the sensor 110 may optionally transmit medical data to the multipurpose data receiving device 130 via a communication interface (e.g., via NFC, BLE, etc.) through its communication module 240. In step 570, the dedicated data receiving device 120 may be communicably coupled to a dedicated application running on a user computer device 140 (e.g., the patient's personal computer). Through communication with the dedicated application, the dedicated data receiving device 120 can communicate the medical data acquired from the sensor 110. As embodied herein, the dedicated data receiving device 120 can be shipped with the internal program flash of the ASIC 200 locked at the debug and programming port, and provided to the end user in a firmware-locked state that prevents access without mass erasure. As embodied herein, the sensor 110 or the dedicated data receiving device 120 can be returned to the manufacturer 160 (or a trusted third party) for diagnostic purposes, such as recovering inaccessible data or identifying the cause of a particular error.

[0056] In step 580, the multipurpose data receiving device 130 or the user computer device 140 can communicate medical data to the cloud server 150 as embodied herein. As described herein, the multipurpose data receiving device 130 or the user computer device 140 can optionally be less restricted in the use of computer processing power and therefore engage in standard data security approaches when transmitting data to the cloud server 150. The communication exchange between the multipurpose data receiving device 130 or the user computer device 140 and the cloud server 150 may include the exchange and confirmation of transmitted data. As an example, the cloud server 150 may generate additional information from the data provided to the cloud server 150 and provide that additional information to the user computer device 140 or the multipurpose data receiving device 130 so that the user of the device (e.g., patient 140) can view the additional information. As embodied herein, before the data is uploaded to the cloud server 150, the data can be anonymized by removing, encrypting, or otherwise obscuring the patient 140's personally identifiable information from the data. The cloud server 150 may (if necessary) associate the data back with patient 140 using other information, such as an authentication token used to connect to the cloud server 150, identification information of the multipurpose data receiving device 130, or information associated with the user computer device 140. Alternatively, the data may be irreversibly unassociated with patient 140, ensuring data privacy while allowing the data to be used for research, for example, to monitor or improve the accuracy of the technology used to process the data. Furthermore, the data may be compared with previously received data to ensure that the data is not a duplicate of another dataset. For example, patient 140 may upload data using both the multipurpose data receiving device 130 and the user computer device 140, which should not be double-counted for patient 140.

[0057] The data lifecycle described with respect to Figure 5 illustrates areas where sensitive data, such as security parameters (described in further detail herein) or patient data, may be exposed to or potentially attacked by malicious third parties. For example, encryption keys are embedded for use in the manufacturing process, and security parameters are delivered to the sensor 110 and the reading device 120. Medical data exchanged via communication links (e.g., NFC, BLE, USB, etc.) between the sensor 110 and the multipurpose data receiving device 130, the sensor 110 and the dedicated data receiving device 120, or the dedicated data receiving device 120 and a dedicated application running on the user computer device 140 is exchanged remotely from the control of the manufacturer 160, and therefore the communication needs to be protected, for example, through authentication and encryption. Logs from the sensor 110 and the dedicated data receiving device 120, for example, those obtained from the associated devices upon return to the manufacturer 160, contain minimal medically sensitive data, but re-enabling manufacturer-specific interfaces to obtain these logs may expose security parameters and manufacturer-specific commands. Accordingly, as embodied herein, manufacturer-specific interfaces are authenticated through separate manufacturer-specific processes (for example, using manufacturer-specific device-specific or session-specific keys).

[0058] The security architecture described herein embodies several design principles for guiding security-related decisions. For example, parameters that can be used for authentication or encryption and are transmitted as plaintext are transformed before being used as security parameters. As part of the device identification and authentication sequence, sensor properties such as UID, software version, randomly generated challenge, and nonce value are transmitted as plaintext and therefore pose a direct, observable risk. Hereinafter, these parameters are processed in some way, such as through unencrypted transformations or algebraic operations, before being used as input for encryption or other security functions.

[0059] The integrity of communication transmissions is actively managed using on-chip hardware functions. Encryption provides a secure means of transmitting data in a tamper-proof manner, but encryption and decryption incur computational costs. Furthermore, transmission failures cannot be distinguished from attacks. As previously mentioned, high-speed, hardware-based error detection codes can be used for transmission integrity. As an example, an error detection code of appropriate size relative to the message length (e.g., a 16-bit CRC) may be used, as embodied herein, but this disclosure anticipates other suitable hardware-based error detection codes. Functionality, including additional security, relies on encryption.

[0060] The order of challenge parameters changes between the sender 110 and the data receiving device (e.g., from the data receiving device to sensor 110, or vice versa) to reduce the likelihood of a successful replay attack. The abstract risk of using parameters that coincidentally match cipher block boundaries is that it can create a situation where the coincident values ​​paired with the challenge produce the same ciphertext. Authenticated exchanges reduce this risk by changing the order of challenge parameters in the return token (e.g., reverse, transform, etc.) to reduce it to the rare case of 1 in 264 probability where random challenge A and random challenge B are equal and the matching parameters are equivalent. A challenge can be used for a single exchange, and a nonce can be used for a single message. To further reduce the risk of ciphertext collisions, challenges used in mutual authentication tokens can be discarded and regenerated for each new authenticated exchange, and nonce values ​​can be changed per message. To address the risks associated with known plaintext attacks, the values ​​used as input to counter-mode ciphers start with non-zero values ​​to reduce predictability.

[0061] Sensor 110 may receive exemplary security parameters ("SP") and keys during manufacturing. Sensor 110 may provide a static unique ID ("UID") which may include organizational unique identifiers ("OUI"), manufacturer identification codes, or other similar information, as embodied herein. The UID may be trackable and verified to be unique. The UID may be a non-variable hardware-encoded value. During manufacturing, sensor 110 may further receive personalized values ​​("PV") and cryptographic keys, including but not limited to authentication formed values ​​(AFV), cryptographic formed values ​​(EFV), or unique authentication values ​​(UAV), which are described in more detail herein. As embodied herein, the personalized values ​​may be used as initiating material for nonce s, which may be used as input for cryptography used between authentication and data encryption, while the formed values ​​may include random values ​​used to further obfuscate the relationship between the personalized values, other key information, and outputs. The Personalization Value may include a key, such as an Identity Resolving Key ("IRK"), which the sensor 110 or data receiving device can use to de-anonymize connection identification information (including, but not limited to, the information described herein) and resolve the anonymized or signed connection identification information to refer to a specific device for the purpose of identifying and initiating an authentication exchange. The AFV and EFV may be random values ​​generated by the manufacturer 160 and stored in the sensor 110. The AFV may be used as input to various cryptographics used during authentication, while the EFV may be used during encryption. As embodied herein, the AFV and EFV may be different or matching values. The UAV may be a value derived from the unique information of the sensor 110, derived from various components of the sensor, such as the ASIC 200 and the communication module 240.

[0062] As embodied herein, the sensor 110 can be configured to independently derive or deploy keys. Thus, the sensor 110 can receive cryptographic keys in the form of an extended key schedule. Since all inputs for generating key values ​​(e.g., root key, device-specific information, secret sensor value, etc.) are known at manufacturing time, the keys can be deployed before provisioning the sensor 110. For example, the sensor 110 can receive a random secret used to implement a sensor-specific key at the end of an authentication sequence with a data receiving device, or as part of a termination step to a data receiving device, before sending sensitive data to the data receiving device. Since the sensor 110, not under the supervision of manufacturer 160, could be subject to potential attacks, no particular key values ​​are stored on the sensor 110. For example, keys used to derive communication authentication values, or sensor-specific authentication values, may optionally not be permanently stored on the sensor 110, but instead are determined live and as needed from values ​​stored on the sensor 110. Furthermore, the sensor-specific key used to authenticate restricted commands may be stored outside of the sensor 110, or in a format that reduces the impact of compromises. As embodied herein, an irrelevant sensor-specific keying secret (e.g., "SS") is randomly generated during the manufacturing of the sensor 110 based on device-specific values, manufacturing-related values, a random value function, and other adjustment functions. The values ​​used to generate the SS are used to create the uniqueness of the secret. The random value function obscures the relationship between the SS, root key, and derived key. This secret can be used in operation to communicate with the data receiving device in combination with a root key available on the data receiving device. The root key can be stored by the data receiving device to derive a sensor encryption key ("SEK") unique to that sensor 110 and to encrypt data communication between the sensor 110 and the data receiving device.

[0063] SPs are inputs for control in a security architecture. For example, SPs are used as inputs to cryptographic functions and affect the output of the cryptographic function. For clarity, cryptography is applied to data. In particular, data is not used as an SP. Exemplary SPs available for use in the low-power medical monitoring system 100 are described herein. The derivative values ​​of SPs are not given for brevity, but it should be understood that they are adopted where appropriate. The system architecture intends to use various stored and generated security keys during security-critical processes such as device authentication, encryption of inter-device communications, and software and firmware updates. As previously stated, the sensor 110 of the low-power medical monitoring system 100 is designed with power efficiency and computational efficiency in mind, so the sensor 110 can store specific values ​​correlated with security keys. To enable authentication and encryption, the value (such as an SP) can be used by a data receiving device to generate an appropriate session or device-specific security key. As embodied herein, the key structure can be used to counter cryptographic vulnerabilities by prioritizing derived keys for authentication and encryption and using each derived key for a single purpose or activity. As embodied herein, derived keys can be configured to be specific to each device (e.g., sensor 110, dedicated data receiving device 120, multipurpose data receiving device 130) and further specific to each purpose (e.g., a particular communication session between two devices, or a particular exchange during a communication session). Thus, a compromise of a single derived key (such as a key used for authentication or encryption) is isolated to a compromise of a single function of a single sensor 110. A single key compromise does not introduce a significant weakness to the entire cryptographic system.

[0064] When generating authentication keys, cryptographic keys, and root keys (which can be used to derive a single device-specific cryptographic key or a single-purpose ephemeral cryptographic key), security practices are followed to ensure that the keys are secure, tamper-proof, and, where necessary, generated in a truly random manner. In practice, keys can be generated in part using system entropy collected through truly random behavior, such as minute user interactions (e.g., mouse movements), system interrupts, network interrupts, process table events, and other system entropy collection techniques.

[0065] This specification describes exemplary keys, including, but not limited to, exemplary uses of keys and relationships between keys in the security architecture for the low-power medical monitoring system 100 embodied herein. The keys used and described herein are exemplary and not exclusive, and additional or alternative keys may be appropriately used depending on the design requirements and applications of a particular medical monitoring system 100. For example, where, as embodied herein, an SEK is described as being used to encrypt communication between a sensor 110 and a multipurpose data receiving device 130, a similar key may be used to encrypt communication between a dedicated data receiving device 120 and a user computer device 140.

[0066] While SEKs can be unique, the impact of non-unique SEKs can be considered minimal in the overall security architecture, at least in part, due to authentication redundancy. For example, if two users have sensors 110 with the same SEK value (representing a 1:2n probability for an n-bit key), matching data nonce values ​​used for encryption (representing a 1:2n probability for an n-byte nonce), and matching communication interface coupling identifier values, then sensor 110 can be configured to communicate only with the activation data receiving device that is actively coupled at the hardware handshake level, provided that the hardware addresses match.

[0067] As embodied herein, true randomness can be incorporated throughout the security architecture. Randomness can be derived by different entities within the system, including the manufacturer 160, the sensor 110, the dedicated data receiving device 120, the multipurpose data receiving device 130, and the user computer device 140. A random bit generator ("RBG") produces a completely unpredictable (e.g., truly random) output. This unpredictable output is used to drive the generation of a key or other cryptographic parameter, ensuring that no external party can algorithmically predict the bits before they become available.

[0068] As embodied herein, the entropy provided by manufacturer 160 is provided to sensor 110 through a combination of proprietary and open, auditable software. The random values ​​provided to sensor 110 are used for a variety of purposes, including but not limited to authentication nonce inputs for communication links and random material used as inputs to key derivation functions. In security architectures, UAVs and AFVs can be used as initial values ​​for nonce construction, and their random nature can make the output more unpredictable. Furthermore, as embodied herein, once sensor 110 is activated by a user, the nonce value gains additional entropy from interaction with the user, and the significance of the manufactured value is surpassed by the entropy of the interaction with the user. For example, entropy can be introduced through unpredictable variables, such as the interaction time, the time period between interactions with dedicated data receiving device 120 or multipurpose data receiving device 130, or the communication module 240. For example, if sensor 110 includes a communication chipset that supports true random values, sensor 110 can collect entropy from the chipset. As embodied herein, calls to generate random values ​​from the microcontroller 210 of the sensor 110 can be made through a programming interface ("API") provided by the chipset vendor.

[0069] Similar to sensor 110, dedicated data receiving device 120 can use true random values ​​and collect entropy through its various sensors. For example, dedicated data receiving device 120 may include a communication chipset 340 that supports true randomness, separate from the communication chipset 240 of sensor 110. As embodied herein, dedicated data receiving device 120 can implement an RBG architecture in which entropy from true randomness is used as a live entropy source and is conditioned by a PRNG using a random entropy source (or a value derived therefrom) as input. Software libraries and applications within dedicated data receiving device 120 can retrieve random data from true randomness and store those values ​​in non-volatile memory as a cryptographic seed usable as a PRNG. Furthermore, third-party applications incorporating the software libraries can provide additional entropy functionality through the embedded operating environment of the target platform.

[0070] As embodied herein, the low-power medical monitoring system 100 may employ periodic key rotation to further reduce the possibility of key compromise and exploitation. The key rotation strategy employed by the low-power medical monitoring system 100 may be designed to ensure backward compatibility of field-deployed or distributed devices. As an example, the low-power medical monitoring system 100 may employ keys designed to be compatible with multiple generations of keys used by upstream devices for downstream devices (e.g., devices located in the field or for which viable updates cannot be provided). Upstream devices may be defined relative to downstream dependent devices and may be defined on the ease with which devices can be updated with new keys under the security architecture. As an example, a user computer device 140 running a dedicated application may be considered upstream of a multipurpose data receiving device 130 or a dedicated data receiving device 120, which is considered upstream of a sequential sensor 110. As another example, root key rotation may begin with the manufacturer 160. While manufacturing a new key generation for sensor 110, the manufacturer 160 may propagate the new key generation to newly manufactured sensors 110. Manufacturer 160 may also push updates to the data receiving device that enable the data receiving device to identify the security version returned by the sensor 110 in order to determine which root key to use when deriving the authentication key for a particular sensor 110. As a further alternative, key rotation can be performed on an agreed-upon schedule, in which devices are configured to adjust the keys used according to some time or event-driven function. After the occurrence of a trigger event, all authentication devices are configured to switch to a different generation of keys pre-programmed for the devices. The trigger event can be universal to all relevant devices (e.g., switching keys on a monthly, daily, or weekly basis), specific to individual devices (e.g., switching keys for a sensor after 24 hours of active use), or applicable to any subdivision of the devices.

[0071] As embodied herein, the encryption schemes described herein may include, for example, several functions associated with cryptographic performance. One class of these functions includes symmetric encryption functions such that the same key can be used for encrypting outbound data and decrypting inbound data. Such functions may include block ciphers and related functions. A block cipher is an encryption function that encrypts blocks of values ​​by applying a deterministic algorithm with a known key, rather than encrypting bit by bit like a stream cipher. Block ciphers may be particularly useful in the system architecture of the low-power medical monitoring system 100 because, as mentioned above, the sensor 110 (and to a lesser extent, the dedicated data receiving device 120) may have less available computing power, at least in part due to design options chosen to control cost, reduce size, and maintain battery life. However, stream cipher algorithms can be used according to the techniques disclosed herein, with appropriate modifications to take into account the power and computing resource limitations of this system architecture. The encryption algorithms that can be used include any suitable cryptographic technique.

[0072] As an example, the low-power medical monitoring system 100 may support a first lightweight block cipher or stream cipher for encryption. As another example, the low-power medical monitoring system 100 may further support additional, more cryptographically complex block ciphers or stream ciphers for encryption. In certain embodiments, the first lightweight block cipher or stream cipher may be preferred for use by devices with limited access to power and computerizability, while the second block cipher or stream cipher may be a more cryptographically complex block cipher or stream cipher for use by devices with fewer constraints on power and computer resources. The first block cipher or stream cipher may be selected for implementations where the amount of data generated and transmitted is relatively small, and the more complex cipher of the second block cipher or stream cipher is unsuitable or impractical. Thus, the first block cipher or stream cipher may be referred to as a lightweight block cipher or lightweight stream cipher in comparison to the second block cipher or stream cipher. The low-power medical monitoring system 100 may, as appropriate, support the use of additional block ciphers and stream ciphers. Each of the block ciphers and stream ciphers may be implemented by a software module or a dedicated hardware module.

[0073] As an example, a lightweight block cipher can employ an additive-rotating-XOR ("ARX") framework. In this example, no scheduled key is used. Given the data to be encrypted and the key, and each divided into at least four blocks, the algorithm begins by XORing each block of data with the corresponding block of the key. The algorithm proceeds through a predetermined number of rounds of substitution functions, the number of which is chosen based on a balance between security and performance. Each round of the substitution function may include the following operations performed in order: add the second block of data to the first block of data; rotate the second block by a predetermined amount; XOR the first block of data to the second block of data; rotate the first block of data by a predetermined amount; add the fourth block of data to the third block of data; rotate the third block of data by a predetermined amount; XOR the third block of data to the fourth block of data; add the fourth block of data to the first block of data; rotate the fourth block of data by a predetermined amount; XOR the first block of data to the fourth block of data; add the second block of data to the third block of data; rotate the second block of data by a predetermined amount; XOR the third block of data to the second block of data; rotate the third block of data by a predetermined amount. As a final step, after a predetermined number of rounds, the algorithm XORs each block of data in its current state with the corresponding block of the key.

[0074] As another example, a lightweight block cipher can employ the ARX algorithm. Given a block to be used in a cipher divided into two words and a key, the algorithm can proceed for a predetermined number of rounds. During each round, the bits of the first word of the block are rotated by a first predetermined amount, the second word of the block is added to the first word of the block, the key is XORed with the first word of the block, the bits of the second word of the block are rotated by a second predetermined amount, and the first word of the block is XORed with the second word of the block. As embodied herein, the key used in each round can be computed on demand depending on the available computing resources or can be pre-cached.

[0075] As another example, a lightweight stream cipher can utilize XOR, 32-bit addition, and constant-distance rotation. This cipher can be represented by an internal state containing 16 words arranged as a square matrix. This word consists of four predetermined words, eight key words, two stream position words, and two nonce words. The cipher operates by alternating rounds through operations on the rows or columns of the internal matrix, performing four quarter-round operations per round. The four operations performed in a round take four words as input and perform a series of XOR, addition, and rotation operations on the input words. In the first example, the quarter-round operation is performed in the following pattern: the first word is added to the four words, rotated by a predetermined amount, and XORed with the second word; the first and second words are added together, rotated by a predetermined amount, and XORed with the third word; the second and third words are added together, rotated by a predetermined amount, and XORed with the fourth word; the third and fourth words are added together, rotated by a predetermined amount, and XORed with the first word. The predetermined amount can be different for each operation. After a set number of rounds, the mixed array is added to the original internal slate to prevent recovery of the initial key. As a variation of the stream cipher, the internal slate and the quarter-round operation can be modified. The quarter-round operation can be modified to accept four input words and is performed in the following pattern: the second word is added to the first word, the resulting first word is XORed with the fourth word, and the result is rotated by a predetermined amount. This pattern is repeated, changing the predetermined rotation value. Each word is updated twice in every quarter round. Furthermore, the stream cipher can be modified so that quarter rounds operate on columns and diagonals instead of columns and rows.

[0076] As an example, more cryptographically complex block ciphers may employ a predetermined number of rounds consisting of decompression, key mixing, substitution, and reordering. Prior to the main set of rounds, the block can be divided into two halves, and each half can be processed alternately to facilitate symmetry in encryption and decryption. During expansion, the current half-block is expanded by duplicating half of the bits of the half-block so that the block contains a set of operation bits that include copies of four input bits and copies of the directly adjacent bits from both sides of the input bits. In the mixing step, a subkey is combined with the expanded half-block using an XOR (exclusive OR) operation. The subkey is determined according to a key schedule based on the main cryptographic key. After mixing the subkeys, the block is divided into several substitution boxes. Each substitution box decrements the input bit count according to a nonlinear transformation provided by a lookup table. The bits output from the substitution step are reordered according to a predetermined sort. Operations to form a key schedule may include taking a subset of the key's bits, splitting the subset, performing a predetermined number of bitwise rotations, and recombining the two halves to form a subkey.

[0077] As another example, more cryptographically complex block ciphers can be based on substitution-substitution networks. This cipher may include operations such as a key expansion step that derives a round key from a cryptographic master key using a predetermined key schedule, and an initial key addition step that XORs each byte of a block with the byte of the round key. The operations may include a predetermined number of rounds in which one or more of the following steps are performed: a nonlinear substitution step that replaces each byte with another byte according to a lookup table; a step that cyclically shifts selected bytes a certain number of steps by progressively changing the shift amount; a step that mixes the byte subdivisions with an inverting linear transformation; and an XOR of the round key with the resulting block.

[0078] As another example, more cryptographically complex stream ciphers can generate a pseudo-random stream of bits, i.e., a key stream, and combine it with the data to be encrypted using XOR. The key stream is generated using a key scheduling algorithm, in which an internal array is initialized with an ID sort of a predetermined length. The internal value is derived by adding the current value of the internal value, the value stored at the position in the internal array corresponding to the number of rounds, and the value of the key position determined by performing the modulo of the number of rounds and the key length for a number of rounds equal to a predetermined length. The modulo of the result of this operation and the maximum number of rounds is then set as the internal value. To end a round, the value of the internal array at the position indexed by the round number and the internal value is swapped. When the key scheduling algorithm finishes, a pseudo-random number generation algorithm changes the state of the internal array and outputs one byte of the key bundle. The encrypted data is realized by XORing the output byte of the key stream with the byte of the data to be encrypted. In each iteration of the pseudo-random number generation algorithm, the first internal value is incremented. The second internal value is assigned a value incremented by the value of the internal array at the position of the first internal value. The values ​​of the internal array at the positions indexed by the first and second internal values ​​are swapped. Then, the value of the internal array at the position obtained by adding the first and second internal values ​​is output as the value of the key stream. To prevent index out-of-bounds errors where values ​​are used as indices in the internal array, modulo can be performed between the value and the length of the internal array.

[0079] Furthermore, the implementation of block ciphers or stream ciphers can be selected based on known weaknesses or attack vectors. As an example, known attacks on the cipher can be evaluated as a way to assess the worst-case scenario regarding a malicious third party and compared to the amount of data generated, such as during the entire active service life of the sensor 110. As mentioned above, some keys are derived from device-specific values, and therefore the potential impact can be reduced by including a single key or cipher. Moreover, the amount of compromised values ​​required to know the value of the root key, for example, in supply chain level attacks, significantly limits the practicality of such attacks. As described herein, the sensor 110 uses a randomly generated key for the SEK, and attempts at key recovery against the SEK have little long-term value.

[0080] As embodied herein, the selection of a particular cryptographic implementation, such as block size and key size, may be based on the size of data blocks transmitted over various communication interfaces supported by the communication modules (e.g., communication module 240 and communication module 340). For example, as embodied herein, data blocks transmitted over NFC or BLE may be aligned on 8-byte boundaries, and a 64-bit cryptographic block size may be selected. As embodied herein, a particular cryptographic implementation may be based on the desired cryptographic strength, resulting in a change in the selected cryptographic block size. Stronger cryptography typically involves more computational overhead, for example, imposing additional time to decrypt data during mutual authentication exchange. Furthermore, the cryptographic block size may be selected based on the computational architecture of the microcontroller 210 of the ASIC 200 of sensor 110 and the communication protocol used between sensor 110 and the data receiving device. As embodied herein, the key size may be selected based on the specific memory constraints of the computer platform used.

[0081] As embodied herein, sensor 110 may use a separate sensor authentication key ("SAK") for authentication. As described, the SAK is used to secure the authentication exchange, which consists of a security challenge. The SAK is a sensor-specific key derived from a root key available to the data receiving device and sensor-specific security parameters. The root key is stored by a dedicated data receiving device 120 or a multipurpose data receiving device 130 and can be used during sensor authentication. Each SAK can be derived by the data receiving device for each authentication exchange. The SP is subject to transformation during communication before being used by the key derivation function to derive each SAK. This security architecture is secure because, without knowing the ciphertext output (SAK) and how the SP is transformed and used by the key derivation function, an attacker lacks the plaintext input and cannot attack the root key. During the encrypted exchange, the first encrypted block contains a random number generated by the sender and the transformed security challenge. Security is ensured under this security architecture because, without access to both the random values ​​and the unencrypted transformations, an attacker would not be given the opportunity to obtain plaintext input in order to attack the SAK.

[0082] As embodied herein, the sensor 110 can be configured to respond to requests from a data receiving device with either a plaintext response or an encrypted response. Responses that elicit a plaintext response include commands that do not involve authentication. For example, but not limited to, an unauthenticated command may include a Sensor Information Lookup (SIR) command in which the sensor 110 returns the sensor UID and software version. Encrypted responses are protected, for example, by a sensor-specific derived key SAK or a sensor-specific random key SEK. Authenticated exchanges may be protected by the SAK, while data communications on the communication link, such as reading memory blocks, may be protected by the SEK.

[0083] Authenticated commands may include the command request conforming to a specified format, with values ​​for the format synchronized from previous exchanges. This method can be used to mitigate the impact of random probing from third parties. The format of an authenticated command may be kept as proprietary information available only to the manufacturer or service provider. Before issuing an authenticated command request, the data receiving device and sensor 110 can first synchronize values ​​for exchange challenges (e.g., sender challenge response (SCR) and receiver challenge response (RCR)) and synchronize initial nonces. Synchronization can be achieved by completing the exchange of security challenge messages.

[0084] As embodied herein, challenge random values ​​(e.g., SCR and RCR) can be supplied from a true random value generator function provided, for example, by the communication module of the sensor 110 or the data receiving device. The security challenge can be exchanged as a unique payload and stored in persistent memory for later use as an authentication parameter when sending or verifying authenticated commands. The nonce can be derived from the AFV and other internal state variables stored in the sensor 110.

[0085] In addition to verifying these security exchange values, additional security features can be implemented to make the low-power medical monitoring system 100 more robust against attacks such as replay attacks and signal leaks. For example, before executing an authenticated command, the sensor 110 can be configured to verify that the SCR and RCR values ​​are valid for the current exchange. Once the authenticated command is successfully completed, the sensor 110 can increment the authenticated command counter and invalidate the SCR and RCR states in relation to the current exchange to prevent replay attacks. As another example, if a data receiving device sends an inappropriate authentication token after a security challenge response, the sensor 110 can be configured not to provide a valid response to avoid signal leaks.

[0086] For illustrative, not limiting, purposes, exemplary embodiments of the messaging response state machine 600 of sensor 110 for use with the disclosed subject matter, as shown in Figure 6, are referred to. Figure 6 shows the messaging response state machine 600 of sensor 110. The state machine 600 reflects three states, namely, an open programmable state (OPEN 610) and two normal states (STANDARD 620, AUTH 630) in which sensor 110 can be programmed. As embodied herein, in state OPEN 610, sensor 110 is programmable, reprogrammable, and personalized. For example, a port on the ASIC 200 of sensor 110 for debugging and reprogramming can be enabled. Before sensor 110 is provided for remote / non-manufacturer use, sensor 110 can transition to the first normal state STANDARD 620 upon receiving an encrypted initialization command 640.

[0087] In the first of the two normal states, STANDARD620, the sensor 110 can be configured to respond to all supported standard messages 660 and security challenge messages 650. Upon receiving a valid command, the sensor 110 transitions back to STANDARD 620 as shown in the figure. In this state, if the sensor 110 receives an authenticated command 665, the sensor 110 can respond with a deterministic value or not respond at all. If the sensor 110 receives a security challenge message 650, the sensor 110 can serve the request and, upon successful authentication negotiation as described above, transition to the state indicated as AUTH630.

[0088] As embodied herein, the AUTH state 630 can be characterized by the sensor 110 receiving and responding to requests for authenticated commands 670, as well as receiving and responding to all standard commands 660 available in the STANDARD state 620. When the sensor 110 receives a properly authenticated command, the sensor can service the command and transition back to the STANDARD state 620.

[0089] An example of an authenticated command may be a mutually authenticated command. As embodied herein, a mutual authentication function at a communication module-interface boundary can verify the integrity of the data path between components. As embodied herein, mutual authentication can be based on a mechanism for authentication between two entities without an online trusted third party to verify the establishment of a secret key via challenge-response.

[0090] As an example, but not limited to, the mutual authentication function can implement two-pass authentication in which the sensor 110 and the data receiving device are authenticated. The sensor 110 can initiate a sequence by sending an authentication request or by generating and sending a first token to the data receiving device. The first token can be encrypted according to a previously established cryptographic scheme (e.g., a pre-shared key and cryptographic function). The first token may include a time-varying or sequential value, an identifier corresponding to the sender, an identification constant value, and a text field. When the data receiving device receives the first token, it verifies the token by decrypting the encrypted portion and checks the accuracy and expected value of all values ​​contained therein. Next, the data receiving device generates a second token and sends it to the sensor 110 second. The second token may also be encrypted according to a previously established cryptographic scheme. The second token may include a sequential time-varying or sequential value, an identifier corresponding to the sensor 110, an identifier corresponding to the data receiving device, an identification constant value, and a text field. Upon receiving the second token, sensor 110 verifies the token by decrypting any encrypted portion and checks the accuracy and expected value of all contained values ​​by comparing any returned value with the expected transmitted value. The order of values ​​contained in the token can be changed within the token so that the message appears irrelevant, regardless of the selected cryptographic algorithm.

[0091] For illustrative purposes only, not limiting, exemplary embodiments of a mutual authentication scheme for use with the disclosed subject matter, as shown in Figure 7A, are referenced. With respect to Figure 7A, a two-pass mutual authentication scheme is described. In the mutual authentication scheme, an authentication request 731 can optionally be exchanged between a requesting party 720 (e.g., a sensor 110) and a receiving party 710 (e.g., a data receiving device). The requesting party 720 may generate and transmit a first token, TokenBA, in step 732. As described herein, TokenBA may include a time-varying or sequential value, an identifier corresponding to the requesting party 720, an identifying constant value, and a text field. The time-varying value may include, for example, a timestamp associated with the generation of the token or a timestamp associated with the start of the authentication request. The sequential value may be, for example, a nonce generated using an agreed-upon nonce function. The time-varying and sequential values ​​can be used to verify that the token has not been reused by an unauthorized entity at any given time. Furthermore, the identifier corresponding to the requesting party 720 can be used to verify that the authorized party is not attempting to impersonate the requesting party 720. After receiving the token, the receiving party 710 can decrypt TokenBA according to the expected key and verify the contents of the token, for example, verifying that the time variation value is accurate and that the identifier corresponds to the appropriate entity. The expected key may be, for example, a key derived from a pre-shared secret value, or a key established based on the identification information of the two parties. When verifying the expected value, the receiving party 710 generates a second token, TokenAB, to be sent. As described herein, TokenAB is similar to TokenBA and may include a pre-time variation value, a next value based on a continuous value, an identifier corresponding to the requesting party 720, an identifier corresponding to the receiving party 710, an identification constant value, and a text field. These values ​​serve similar functions for the benefit of the requesting party 720.For example, by including identification values ​​for both the requesting party 720 and the receiving party 710, the requesting party 720 can verify the decryption process while verifying the exchange. The receiving party 710 can encrypt TokenAB and, in step 733, send the token to the requesting party 733. The requesting party 733 can then decrypt the token using the agreed-upon cryptographic scheme and verify the information contained therein. Through this mutual authentication process, the requesting party 720 and the receiving party 710 can verify that the encryption scheme is mutually acceptable and that the parties to the communication are acting as expected.

[0092] As another example, though not limited to them, the mutual authentication function can implement three-pass authentication based on random value checks in the challenge-response sequence. In the challenge-response sequence, the data receiving device can initiate the sequence by sending a request for challenge parameters to the sensor 110. The sensor 110 can respond with the requested parameters. Next, the data receiving device can present a first authentication token to the sensor 110. The sensor 110 can respond with a second authentication token. As embodied herein, the lengths of variables included in the security challenge message, e.g., SCR and RCR, can be variable and can be chosen to be aligned with cryptographic block boundaries to reduce the predictability of discovery. Furthermore, the order of the parameters SCR and RCR included in the security challenge message can be varied in the authentication token so that the message appears irrelevant regardless of the selected cryptographic algorithm.

[0093] For illustrative purposes only, not limiting, exemplary embodiments of mutual authentication schemes for use with the disclosed subject matter, as shown in Figure 7B, are referenced. With respect to Figure 7B, a three-pass mutual authentication scheme is described. In the three-pass mutual authentication scheme, when an authentication request 740 is initiated by a requesting party 720 (e.g., sensor 110), a receiving party 710 (e.g., data receiving device) returns plaintext challenge parameters 741 (RA concatenated with Text), as shown in Figure 7B. The requesting party 720 may send additional challenge parameters and embed those parameters, along with a representation of the challenge, into an encrypted token 742 (TokenBA). The receiving party 710 may verify the contents of Token 742 and return another token 743 (TokenAB) incorporating at least a representation of the challenge parameters provided by the requesting party 720, with the token contents rearranged to accommodate possible ciphertext reproduction. As embodied herein, the encrypted token TokenAB 743 may contain command-specific data between the challenge parameters. This parameter exchange allows the data receiving device to encrypt the challenge parameter SCR and provide some information to sensor 110, enabling sensor 110 to verify that the data receiving device can be authenticated. This information includes the fact that the data receiving device can successfully derive the SAK from pre-shared secrets, root keys, etc., and sensor-specific parameters such as UAV. This information also includes the fact that the data receiving device can successfully implement the secret message protocol by incorporating the challenge parameter SCR into a message with RCR. This information may also include the fact that the data receiving device can encrypt with the derived key SAK and apply a synchronized nonce value.

[0094] Upon receiving and verifying the authentication token TokenBA, the receiver 710 (e.g., sensor 110) returns the parameter RCR. In doing so, sensor 110 provides several pieces of information to the transmitting party 720 (e.g., data receiving device), from which the data receiving device can verify that sensor 110 is verifiable. This information includes that sensor 110 has knowledge of the SAK. This information includes that sensor 110 can decrypt the authentication token and recover the RCR using the SAK and synchronized nonce. This information also includes that sensor 110 can implement the message protocol and return the RCR in a new message protected by the SAK, along with a subsequent nonce appropriately guided to a provided synchronized nonce derived from the progression of values ​​from a predefined function.

[0095] As another example, but not limited to, the mutual authentication function can implement four-pass authentication in which the sensor 110 and the data receiving device are authenticated by the use of a trusted third party. During four-pass authentication, the data receiving device can initiate authentication by generating a first token and sending it to the trusted third party. In addition, or alternatively, authentication can be initiated by the sensor 110 sending an authentication request to the data receiving device, which triggers the data receiving device to generate and send a token to the trusted third party. The first token may include a time-varying value, an identifier corresponding to the data receiving device, and a text field. Upon receiving the first token, the trusted third party generates a random key to be used by the data receiving device and the sensor 110, generates a response token, and sends it to the data receiving device. The response token includes two parts. The first part includes a first identification constant, a time-varying parameter or random value (used to distinguish the first part from the second part), the time-varying parameter received from the data receiving device, the random key, the identifier of the sensor 110, and text. The second part includes a second identification constant, another time-varying parameter or random value, a random key, an identifier for the data receiving device, and text. Each part of the response token can be encrypted according to a pre-established cryptographic scheme (e.g., pre-shared key and cryptographic function) between the two parties. The first part can be encrypted using a key shared between the data receiving device and a trusted third party. The second part can be encrypted using a key shared between the trusted third party and the sensor 110.

[0096] Upon receiving a response token, the data receiving device decrypts any encrypted portion using a key shared between the data receiving device and a trusted third party, and verifies the expected time-varying parameter or random value of the first portion. The data receiving device verifies the correctness of the identifier of sensor 110 and the time-varying parameter sent to the trusted third party. Next, the data receiving device obtains the random key from the decrypted portion of the responded token, extracts the second portion of the token, and uses it to construct a token to send to sensor 110. The token for sensor 110 includes the extracted second portion and an additional portion containing another time-varying value, the identifier of the data receiving device, and text. The data receiving device then sends the token to sensor 110. Upon receipt, sensor 110 verifies the correctness of the identifier of the data receiving device and its value of the time-varying value. The sensor decrypts the second portion containing the random key provided by the trusted third party. Next, sensor 110 encrypts and sends a message for the data receiving device using the random key provided by the trusted third party. The message contains the final sequential next value of the time-varying parameter. Upon receiving the data, the data receiving device decrypts the message using a random key from a trusted third party and then verifies that the message values ​​are correct. As previously mentioned, the order of the values ​​contained in the token can be altered in the token so that the message appears unrelated, regardless of the chosen cryptographic algorithm.

[0097] For illustrative purposes only, not limiting, exemplary embodiments of mutual authentication schemes for use with the disclosed subject matter, as shown in Figure 7C, are referenced. With respect to Figure 7C, a four-pass mutual authentication scheme is described. In the four-pass mutual authentication scheme, when an authentication request 760 is initiated by a requesting party 720 (e.g., a sensor 110), a receiving party 710 (e.g., a data receiving device) sends the request to a trusted third party 715 (e.g., a remote cloud server 150 associated with a low-power medical monitoring system 100) in step 761. The request includes at least a time-varying, non-repeatable value (TVA), an identifier (IB) of the requesting party 720, and text. The TVA can be any random value. The request does not need to be encrypted. In step 762, the trusted third party generates and sends a response token TokenPA. The TokenPA is used to share a random key for use in communication between the requesting party 720 and the receiving party 710. The TokenPA is characterized by including two parts, each encrypted using a separate key. The first encrypted portion is encrypted using a key shared between the trusted third party 715 and the receiving party 710. The second encrypted portion is encrypted using a key shared between the trusted third party 715 and the requesting party 720 (e.g., sensor 110). The first portion includes a random key, a time-varying, non-repeatable value sent by the receiving party 710, an identifier of the requesting party 720, and text. The second portion includes another time-varying value, a random key, and an identifier of the receiving party 710. The trusted third party sends this token to the receiving party 710 in step 762.

[0098] The receiving party 710 decrypts the first part of TokenPA and verifies its contents. The receiving party 710 can verify that the time variation value matches that sent by the receiving party 710 in order to verify that the message is not a repetition of a previous response to the key request message. The receiving party 710 can also verify that the identity of the requesting party 720 is correct. Next, the receiving party 710 can construct TokenAB to send to the requesting party 720. TokenAB includes the encrypted second part of TokenPA (which remains encrypted because the receiving party 710 does not have access to the key shared between the trusted third party and the requesting party 720), and another part encrypted using a random key provided by the trusted third party. This other part includes at least a time variation value used to verify the accuracy of the requesting party's decryption. In step 763, the receiving party 710 sends this TokenAB to the requesting party 720. The requesting party 720 receives the token and first decrypts the encrypted portion using a key shared between the trusted third party 715 and the requesting party 720. The requesting party 720 verifies the information in the encrypted portion, for example, by checking the time-varying value and verifying the identity of the receiving party 710. Then, the requesting party 720 can obtain a random key and use the random key to decrypt the encrypted portion of TokenAB. The requesting party 720 verifies the time-varying value contained therein.

[0099] Next, in step 764, the requesting party 720 generates a token TokenBA, which is encrypted using a random key and sent to the receiving party 710. The TokenBA may include at least a time-varying value and other information so that the receiving party 710 can verify that the requesting party 720 has the ability to encrypt and decrypt messages using the random key. As embodied herein, the time-varying value may, as appropriate, include random values ​​(e.g., RCR, SCR). Furthermore, the arrangement of values ​​within the token may be varied according to a pre-established scheme to further increase the difficulty for a malicious third party attempting to intercept and interpret the message and to address the reconstruction of the ciphertext.

[0100] As another example, but not limited to, the mutual authentication function can implement 5-pass authentication in which the sensor 110 and the data receiving device are authenticated by the use of a trusted third party. 5-pass authentication can include hybrids of 3-pass and 4-pass authentication. In particular, the sensor 110 can initiate an exchange and send a random value to the data receiving device. This message can be interpreted as an authentication request, or it can follow another authentication request, for example, determining the type of multi-pass authentication to be used. The data receiving device can include the random value and additional random values ​​in the message to the trusted third party. The trusted third party can generate an encryption key based on the random values ​​and provide it to the data receiving device. The data receiving device can provide the encryption key to the sensor 110 in an encrypted message using the encryption key. The data receiving device can also provide additional random values ​​generated by the data receiving device, from which the sensor 110 can derive an encryption key. Furthermore, the sensor 110 can send a confirmation message to the data receiving device to verify that it has properly received the encryption key.

[0101] For illustrative purposes only, not limiting, exemplary embodiments of mutual authentication schemes for use with the disclosed subject matter, as shown in Figure 7D, are referenced. With respect to Figure 7D, a five-pass mutual authentication scheme is described. In the five-pass mutual authentication scheme, authentication is initiated in step 771 by the requesting party 720 (e.g., in sensor 110) sending a message containing a random value RB to the receiving party (e.g., a data receiving device). The random value may take the form of a plaintext challenge parameter, as embodied herein. As with other mutual authentication schemes, authentication may optionally be initiated by the requesting party 720 sending an express authentication request. The authentication request may be used to identify the type of authentication random key used, which may inform the requesting party 720 whether additional information, such as the random value RB, must be provided to the receiving party 710.

[0102] The receiving party 710 receives a random value RB and generates a request to a trusted third party 715. The request may include at least a new random value RA, a random value RB, an identifier IB of the requesting party 720, and optionally text. In step 772, the receiving party 710 sends this message to the trusted third party 715. As embodied herein, the request may be sent in encrypted form, for example, using a random key shared between the trusted third party 715 and the receiving party 710, or optionally in plaintext, since any of the values ​​are expected to be confidential. The trusted third party 715 receives the message and can generate a token TokenPA. TokenPA is used to share a random key for use in communication between the requesting party 720 and the receiving party 710, based on the random values ​​RA and RB. TokenPA is characterized by comprising two parts, each encrypted using a separate key. The first encrypted part is encrypted using a key shared between the trusted third party 715 and the receiving party 710. The key can be derived from a random value RA to reduce the risk of the key being leaked. The second encrypted portion is encrypted using a key shared between the trusted third party 715 and the requesting party 720 (e.g., sensor 110). The key can be derived from a random value RB to reduce the risk of the key being leaked. The first portion includes a random key, a random value RA, an identifier for the requesting party 720, and text. The second portion includes a random value RB, a random key, and an identifier for the receiving party 710. The trusted third party sends this token to the receiving party 710 in step 773.

[0103] Upon receiving the TokenPA, the receiving party 710 decrypts the first portion of the TokenPA and verifies its contents. The receiving party 710 can verify that the random value RA is correct to ensure that the message is not a repetition of a previous response to a key request message. The receiving party 710 can also verify that the identity of the requesting party 720 is correct. Next, the receiving party 710 can construct TokenAB to send to the requesting party 720. TokenAB includes the encrypted second portion of the TokenPA (which remains encrypted because the receiving party 710 does not have access to the key shared between the trusted third party and the requesting party 720), and another portion encrypted using a random key provided by the trusted third party. This other portion includes at least a new random value (e.g., a new challenge-response parameter) that can be used to verify the accuracy of the requesting party's decryption, and a random value RB that can be used by the requesting party 720 as a challenge parameter to verify that the random key is used in the current communication session. In step 774, the receiving party 710 sends TokenAB to the requesting party 720. The requesting party 720 receives the token and first decrypts the encrypted portion using a key shared between the trusted third party 715 and the requesting party 720. The requesting party 720 verifies the information in the encrypted portion, for example, by checking the random value RB and verifying the correct identity of the receiving party 710. The requesting party 720 can then obtain the random key and use the random key to decrypt the encrypted portion of TokenAB. The requesting party 720 also verifies the random value RB contained therein.

[0104] Next, in step 775, the requesting party 720 generates a token TokenBA, which is encrypted using a random key and sent to the receiving party 710. TokenBA includes at least a new random value and other information provided in TokenAB, so that the receiving party 710 can verify that the requesting party 720 has the ability to encrypt and decrypt messages using the random key. The new random value then functions as a challenge-response token as described herein. Furthermore, the arrangement of values ​​within the token can be varied according to a pre-established scheme to further increase the difficulty for a malicious third party attempting to intercept and interpret the message and to address the reconstruction of the ciphertext.

[0105] As embodied herein, authenticated commands may occur in connection with the mutual authentication exchange described above. After completing the security challenge from sensor 110, the data receiving device may issue an authenticated command or send an authenticated message in the form of an opcode in plaintext, and then send an encrypted payload. The protocol for the encrypted payload may vary depending on the command or payload value. As an example, in one form of payload, the encrypted payload may include an SCR encrypted with a subsequent nonce derived from an RCR, command opcode, and a nonce synchronized with the key SAK. The SCR can be obtained from a preceding mutual authentication exchange and can be regenerated for each command request. The RCR can be newly generated to complete authentication and returned to the data receiving device in the response. If sensor 110 determines that the authenticated command does not follow the correct messaging protocol, the authenticated command may fail. In particular, sensor 110 may not arbitrarily confirm the request in order to avoid signal leakage. The response to an authenticated command may contain a specified collection of data between the SCR and RCR, and the payload is encrypted with the key SAK and the appropriate subsequent nonce of the nonce sent with the authenticated command.

[0106] As embodied herein, during manufacturing, the sensor 110 can be set to a post-manufacturing state by receiving an encryption initialization command message via a communication interface (e.g., an NFC interface integrated into the ASIC 200 of the sensor 110). The encryption initialization command causes the sensor 110 to apply encryption and commit the encrypted state to non-volatile memory. This operation can also trigger an ASIC command to disable a port on the ASIC 200 for debugging and reprogramming, and can also trigger a remapping of general-purpose input / output (GPIO) pins.

[0107] As embodied herein, the dedicated data receiving device 120 can also be shipped with the internal program flash of the ASIC 200 of the dedicated data receiving device 120 locked to the debug and programming ports, and provided to the end user in a firmware-locked state that prevents access without mass erasure. In this way, executable images (including confidential data stored for a long period of time) can be protected from tampering and viewing.

[0108] An NFC Initiation authentication command can be sent when the data receiving device powers the sensor 110 with an NFC scan and functions as a sensor activation command. This event may occur, for example, when the sensor 110 is activated by the data receiving device. The scan data can be protected by a session key (e.g., SEK). To initiate the NFC start command, if the challenge authentication is successful, the sensor 110 can send a sensor secret (SS) to the data receiving device. The data receiving device can use the SS to derive the session key (SEK). The SEK can then be used by the sensor 110 and the data receiving device as a cryptographic key with an appropriate nonce and, for example, a block number as a counter. Under this architecture, it is desirable that only authenticated sensor 110 and data receiving devices are provided with knowledge of the SEK.

[0109] Additional authenticated commands can be used to cause sensor 110 to perform additional functions. For example, an authenticated request information command may be an authenticated command that causes sensor 110 to determine and return parameters used by the data receiving device to derive SEK.

[0110] As another example, a communication initialization authentication command can be used to enable components of sensor 110 associated with one or more functions of communication module 240. For example, to maintain security and battery life, sensor 110 may optionally be prevented from being delivered to the user with certain communication functions (e.g., BLE) enabled. Communication functions can be enabled as appropriate when sensor 110 is activated. For example, BLE communication may become available when sensor 110 is activated by a dedicated data receiving device 120 or a data receiving device. A communication initialization command can be issued separately from a sensor activation command, or it can be automatically triggered when sensor 110 receives a sensor activation command. A communication initialization command may return a hardware address and binding ID ("BID") for later use during the connection session.

[0111] For illustrative purposes only, and not limiting, exemplary embodiments of message sequence diagram 800 for use with disclosed subject matter, such as shown in Figure 8, are referenced. Figure 8 shows message sequence diagram 800 illustrating exemplary data exchange between a pair of devices, in particular sensor 110 and data receiving device 801. Data receiving device 801 may be a dedicated data receiving device 120 or a multipurpose data receiving device 130, as embodied herein. In step 805, data receiving device 801 may send a sensor activation command 805 to sensor 110, for example, via a short-range communication protocol compatible with sensor 110. Sensor 110 may be primarily in a dormant state prior to step 805 and may conserve its battery until full activation is required. After activation in step 810, sensor 110 may collect data or perform other operations as appropriate for the medical hardware 260 of sensor 110. Although step 810 is shown to occur only once during data exchange, as embodied herein, step 810 can be performed sequentially as appropriate by the sensor 110 to the medical hardware 860.

[0112] At some point after step 810 first occurs, in step 815, the data receiving device 801 may initiate an authentication request command 815. In response to the authentication request command 815, both the sensor 110 and the data receiving device 801 may engage in a mutual authentication process 820. For example, the sensor 110 and the data receiving device 801 may perform a mutual authentication process as illustrated with respect to Figures 7A-7D and described herein. The mutual authentication process 820 may include the transfer of data, which includes a challenge parameter that enables the sensor 110 and the data receiving device 801 to verify that the other device is sufficiently capable of complying with the security framework described herein. For example, the mutual authentication process may include the data receiving device 801 deriving a sensor-specific authentication key (e.g., SAK) based on sensor-specific values ​​and random values ​​provided to the data receiving device 801 by the sensor 110.

[0113] Following a successful mutual authentication process 820, in step 825, the sensor 110 may provide the data receiving device 801 with a sensor secret 825 (e.g., SS). The sensor secret may also include a sensor-specific value and may be derived from a random value generated during manufacturing. The sensor secret may be encrypted before or during transmission to prevent third parties from accessing the secret. As embodied herein, the value used to derive the sensor secret may be universally unique, such that the sensor is specific to the communication session between the sensor 110 and the data receiving device 801. As embodied herein, the sensor secret 825 may be encrypted via one or more keys generated by or in response to the mutual authentication process 820. In step 830, the data receiving device 801 may derive a sensor-specific cryptographic key (e.g., SEK) from the sensor secret. As embodied herein, the sensor-specific cryptographic key may further be session-specific. In this way, the sensor-specific encryption key is determined by each device without being transmitted between the sensor 110 or the data receiving device 801, and only devices that have access to the root key, communication protocol, and secret information can decrypt the data encrypted with the sensor-specific encryption key.

[0114] In step 835, the sensor 110 can encrypt the data contained in the payload. Where appropriate, the data may include sensitive medical data, such as biometric data or the results of drug delivery trials. In step 840, the sensor 110 can transmit the encrypted payload 840 to the data receiving device 801 using a communication link established between the sensor 110 and the data receiving device 801 in a suitable communication model. In step 845, the data receiving device 801 can decrypt the payload using the sensor-specific encryption key derived during step 830. Following step 845, the sensor 110 can deliver additional data (including newly collected data), and the data receiving device 801 can process the received data appropriately. As embodied herein, the data receiving device 801 can further transmit the encrypted data to the sensor 110 using the sensor-specific encryption key derived during step 830. The sensor 110 can decrypt the data using the sensor-specific encryption key stored in the storage 230 of the ASIC 200.

[0115] Embodiments described herein may, where appropriate, repeat one or more steps of the method in Figure 8. While this disclosure describes and illustrates certain steps of the method in Figure 8 as occurring in a specific order, this disclosure intends that any preferred steps of the method in Figure 8 may occur in any preferred order. Furthermore, while this disclosure describes and illustrates exemplary methods for encrypting and transmitting sensitive medical data, including certain steps of the method in Figure 8, this disclosure assumes any suitable method for encrypting and transmitting sensitive medical data, including any suitable steps, which may include all, some, or any of the steps of the method in Figure 8. Furthermore, while this disclosure describes and illustrates certain components, devices, or systems for performing certain steps of the method in Figure 8, this disclosure intends that any suitable combination of any suitable components, devices, or systems may perform any suitable steps of the method in Figure 8.

[0116] As embodied herein, the dedicated data receiving device 120 can be configured to respond to requests from the user computer device 140, particularly from a dedicated application running on the user computer device 140, with either a plaintext response or an encrypted response. Responses that elicit a plaintext response include commands without authentication. Not limited to, but illustrative, an unauthenticated command may include a command requesting a value that can be used to identify the dedicated data receiving device 120 or the user of the dedicated data receiving device 120 in order to establish an encrypted connection. As an example, the dedicated data receiving device 120 may respond to such a command from the user computer device 140 with information such as a reader UID, software version, firmware version, user personalization value, or tokenized user identification. Encrypted responses can be protected, for example, by a reader-specific derived key or a reader-specific random key equivalent to a SAK or SEK. The dedicated data receiving device 120 may also use a transformation function that converts the authentication nonce not into an unpredictable sequence, such as a sequence unpredictable for those without access to the function, rather than a monotonically increasing sequence. As embodied herein, the reader may employ a key different from the key used by the sensor, which can reduce the risk of compromise or specific attacks in which a malicious actor could obtain a sensor-specific key and use that key to verify the exchange between the dedicated data receiving device 120 and the user computer device 140.

[0117] As discussed herein, the sensor 110 can be a device with limited processing power, battery supply, and storage. The encryption technology used by the sensor 110 (e.g., the choice of cryptographic algorithm or implementation of the algorithm) can be selected at least in part based on these limitations. The dedicated data receiving device 120 can be a stronger device with fewer constraints of this nature. Thus, the dedicated data receiving device 120 can employ more advanced and computationally intensive encryption technologies, such as cryptographic algorithms and implementations. For example, if the sensor 110 implements a lightweight block cipher, the dedicated data receiving device 120 can implement a more complex cipher. Thus, communication between the dedicated data receiving device 120 and the user computer device 140 can be considered more secure based on the level of encryption used. This corresponds to the amount of data transmitted, as the dedicated data receiving device 120 can store and transmit a larger amount of sensitive medical data to the user computer device 140 than the sensor 110 can store and transmit. This also offers the advantage of enforcing a higher level of encryption with sensitive medical data, as the data is transmitted far away from the sensor 110, increasing the risk of interception or exposure.

[0118] As embodied herein, an authenticated command may include the command request conforming to a specified format, where the values ​​for the format are synchronized from a previous exchange. Thus, the interface between the dedicated data receiving device 120 and the user computer device 140 can follow a similar procedure to that described for the interface between the sensor 110 and the dedicated data receiving device 120. This procedure can be used to mitigate the impact of randomized probing attempts from third parties. The authenticated command format may be kept as proprietary information available only to the manufacturer 160 or service provider. As embodied herein, the authenticated command format may conform to, or be based on, a security protocol for securely transmitting data over a wired or wireless communication link. As embodied herein, before issuing an authenticated command request, the dedicated data receiving device 120 and the user computer device 140 can first synchronize the values ​​for the exchange challenge and synchronize the initial nonce.

[0119] As embodied herein, the challenge random value can be supplied, for example, from a true random value generation function provided by a dedicated data receiving device 120 or a communication module or interface of a user computer device 140. The user computer device 140 can further connect to a wide area network to obtain a true random value from a security provider. As embodied herein, the security challenge can be exchanged as a unique payload and stored in persistent memory for later use as an authentication parameter when sending or verifying authenticated commands.

[0120] The authentication scheme can utilize security features supported by a specific communication link between the dedicated data receiving device 120 and the user computer device 140. For example, the dedicated data receiving device 120 and the user computer device 140 can be connected via a wired connection (e.g., USB) or a wireless connection (e.g., Bluetooth, NFC, Wi-Fi, etc.). As embodied herein, these connections can be associated with specific device interfaces associated with specific device drivers. These device drivers may be managed by a trusted third party or by the manufacturer and provider of the proprietary application running on the dedicated data receiving device 120 and the user computer device 140. As embodied herein, the cryptographic keys used by the user computer device 140 and the dedicated data receiving device 120 may be supplied by an update to the device driver or derived from updated information in the device driver. The updated keys can be propagated from the user computer device 140 to the dedicated data receiving device 120 through updates to the secured device. The keys can be frequently updated through such program updates to reduce the risk of compromise by using existing keys.

[0121] As described above, the multipurpose data receiving device 130 or the user computer device 140 can communicate with the remote cloud server 150. The device can exchange various types of information, including, but not limited to, highly sensitive medical data, statistical analysis of medical data, warnings and recommendations, device software and firmware updates, and security architecture updates (e.g., updates to authentication keys used and supported by various devices). For simplicity, the following discussion refers to the exchange of data between the user computer device 140, or any application running on the user computer device 140, and the remote cloud server 150. It should be understood that embodiments describing the functionality of the user computer device 140 can be adapted for use with the multipurpose data receiving device 130. Furthermore, as embodied herein, the uploading of sensitive data to the remote cloud server 150 can be managed and controlled by the user. For example, the user can set privacy settings to limit the amount and nature of data sent to the remote cloud server 150 for analysis. Furthermore, the user computer device 140 can be configured to perform some or all of the advanced analytical functions of the remote cloud server 150 without accessing a wide area network. Users can access the same level of analysis and data collection as users who choose to interact with the remote cloud server 150, while avoiding direct access to the remote cloud server 150.

[0122] The general characteristics of the remote cloud server interface may be broadly similar to those of other device interfaces described herein with respect to security architecture. For example, the user computer device 140 may be configured to respond to requests from the remote cloud server 150 with either plaintext or encrypted responses. In this regard, communication between the remote cloud server 150 and the user computer device 140 may be bidirectional. Communication including plaintext responses may include commands that do not require authentication. Not limited to, but illustrative, an unauthenticated command may include a command that requests a value that can be used to identify the user computer device 120 or its user in order to establish an encrypted connection. Encrypted responses may be protected by a unique key associated with the user or user computer device, for example, an SAK or a unique random key equivalent. The user computer device 140 may also employ a different key than the one used by the sensor or reader, thereby reducing the risk of compromise or specific attacks where a malicious actor could, for example, obtain a sensor-specific key and attempt to use that key to verify the exchange between the dedicated data receiving device 120 and the user computer device 140.

[0123] Compared to the sensor 110 and dedicated data receiving device 120, the multipurpose data receiving device 130 and user computer device 140 can have relatively fewer constraints on available processing power, battery supply, and storage. Therefore, the multipurpose data receiving device 130 and user computer device 140 can be configured to employ significantly more complex encryption and authentication technologies, such as complex cryptographic algorithms and implementations. Thus, communication between the multipurpose data receiving device 130 and the remote cloud server 150, or between the user computer device 140 and the remote cloud server 150, can be considered more secure based on the high level of encryption used. Furthermore, the user computer device 140 can function in many ways as a repository of patient 170's sensitive medical data and can transmit a large amount (possibly all) of sensitive medical data collected about patient 170, which matches the volume and nature of the data being transmitted. This also provides the advantage of enforcing a higher level of encryption on sensitive medical data, as the data is transmitted far away from the sensor 110 and data receiving device, increasing the risk of interception or exposure. To protect sensitive medical data in storage and in transit, several stages of encryption can be used, mixing proprietary encryption algorithms with industry-standard encryption architectures. For example, sensitive medical data can be encrypted before or during transmission between a multipurpose data receiving device 130 and a remote cloud server 150, or between a user computer device 140 and a remote cloud server 150, using mutually agreed-upon encryption keys (determined, for example, using the mutual authentication scheme described herein). Packets of the encrypted payload can be further delivered via secure transport protocols, including but not limited to HTTPS, SFTP, FTPS, SSL, and SSH. Authentication information for establishing a connection via a secure transport protocol can further be based on session, device, or user-specific keys similar to those described herein.

[0124] As embodied herein, the communication link between the user computer device 140 and the cloud server 150 can be associated with a specific device interface associated with a specific device driver. These device drivers can be managed by a trusted third party or by the manufacturer and provider of the low-power medical monitoring system 100. As an example, the provider can generate a secure driver to facilitate the establishment of the communication link. The secure driver can be linked to software and version updates so that the remote cloud server 150 can only communicate with the user computer device 140 that has the driver (and encryption key) updated to the appropriate software version level. In this way, the low-power medical monitoring system can ensure that keys that may be discovered or compromised over time are not used to compromise the entire system. The updated key can be propagated from the remote cloud server 150 or from the provider of the proprietary application to the user computer device 140 through a secure device update. The key can be updated frequently through such program updates, reducing the risk of compromise by using an existing key.

[0125] As embodied herein, the user computer device 140 or the multipurpose data receiving device 130 can be configured to operate in a pass-through manner, where data received via protected communication with the sensor 110 or the dedicated data receiving device 120 is not decrypted on the user computer device 140 or the multipurpose data receiving device 130. For example, the multipurpose data receiving device 130 can function solely as a method for the sensor 110, which does not have the ability to connect to a wide area network, to transmit data to a remote cloud server 150. The multipurpose data receiving device 130 can operate without even knowing the key used to encrypt the sensitive medical data. In such a case, the key (e.g., SEK) may be known by the sensor 110 and the remote cloud server 150, while another key (e.g., SAK) may be used to verify that the multipurpose data receiving device 130 can communicate with the sensor 110 and also communicate with the remote cloud server 150 on behalf of the sensor 110.

[0126] For illustrative purposes only, and not limiting, exemplary embodiments of message sequence diagram 900 for use with disclosed subject matter, such as that shown in Figure 9, are referenced. Figure 9 shows message sequence diagram 900 illustrating an exemplary exchange of data between a pair of devices, in particular a user computer device 140 and a remote cloud server 150. As embodied herein, the multipurpose data receiving device 130 can be configured to perform many or all of the functions of a proprietary application running on the user computer device 150, as described herein. Thus, Figure 9 may also be useful in illustrating a message sequence diagram of data exchanged between the multipurpose data receiving device 130 and the cloud server 150.

[0127] In step 905, the user computer device 140 may attempt to initiate a connection with the remote cloud server 150. The user computer device 140 may send a request and receive an acknowledgment from the remote cloud server 150 indicating that a connection is available or that a preliminary connection has been successfully established. As embodied herein, this connection may be made using one or more conventionally secure communication protocols (e.g., HTTPS, TLS / SSL, SFTP, etc.) or using a less secure but more efficient communication protocol. In light of the need for enhanced security for sensitive medical data collected by the user computer device 140, the user computer device 140 and the remote cloud server 150 may implement a series of steps to appropriately protect, encrypt, and transmit the sensitive data. As embodied herein, if the user computer device 140 is unable to establish a connection with the remote cloud 150, it may continue attempts to establish a connection at regular intervals (e.g., every second, every 10 seconds, every 60 seconds, etc.). While attempting to establish a connection, the user computer device 140 may secure the collected data for longer-term storage. For example, the user computer device 140 can be instructed to maintain data at a highly granular level and to avoid data corruption or data summarization without granular backups until it is confirmed that the data has been uploaded to the remote cloud device 150. The user computer device 140 can also warn the user when storage capacity is nearing full capacity and potentially encourage the user to provide additional storage capacity while the user computer device 140 attempts to verify connectivity.

[0128] In step 910, once the user computer device 140 can confirm its connection to the remote cloud server 150, the user computer device 910 can be configured to check for device updates to be delivered by the remote cloud server 150. For example, the remote cloud server 150 can deliver security updates to the user computer device 140 before the user computer device 140 can upload data to the remote cloud server. The remote cloud server 150 can further provide device updates (e.g., software updates, firmware updates) to be delivered to other devices within the low-power medical monitoring system 100. For example, the remote cloud server 150 can deliver device updates that were previously to be installed on a dedicated data receiving device 120 with which the user computer device 140 could communicate.

[0129] In step 915, the remote cloud server 150 can deliver any appropriate device updates. The user computer device 140 can then install the updates as needed after verifying their integrity, for example, with authentication and integrity check keys provided by the manufacturer.

[0130] In addition to checking for device updates, the user computer device 140 can be configured to request other notifications and updates from the remote cloud server 150. For example, the user computer device 140 can check in to the remote cloud server 150 for messages for the user. Messages may include, for example, updates regarding sensitive medical data processed by the remote cloud server 150, updates summarizing the results from data mining performed by the remote cloud server 150 as described herein, news and product information regarding low-power medical monitoring systems, etc. The remote cloud server 150 can deliver notifications to the user computer device 140 for the user to see.

[0131] In step 920, the user computer device 140 can determine the upload destination for the data. For example, the low-power medical monitoring system 100 can provide various destinations to which the data can be uploaded, depending on, for example, the identity of the patient or the user computer device 140, the location of the patient or the user computer device 140, and the intended use of the data. For example, a patient may be in a jurisdiction with data privacy controls that mandate that only remote cloud servers 150 with a specific geographical location be used for sensitive medical data. The user computer device 140 (or optionally the remote cloud server 150) can determine which destination is appropriate for the data. In another example, the user computer device 140 (or optionally the remote cloud server 150) can determine which remote cloud server 150 is likely to provide faster and more stable uploads of sensitive medical data. In yet another example, the low-power medical monitoring system 100 may include remote cloud servers that support the collection of large-scale public data in addition to individual personal medical data. The low-power medical monitoring system 100 can provide such data collection to support public health efforts, to provide application support to users (e.g., to identify and determine errors with devices), and to provide large-scale analysis for patients.

[0132] Based on the selection of the upload destination, the user computer device 140 can perform step 925, which determines the nature of the data to be transmitted and can de-identify or anonymize the data. The data to be included in the upload may include live collected data (e.g., data recently received from sensor 110) and may include historical data associated with patient 140. As an example, the user computer device 140 may be configured to collect data continuously or over a short period of time to ensure that the data collected about the patient is fresh and accurate. However, the user computer device 140 may be configured to package the data into larger chunks before uploading it to the remote cloud server 150. For example, individual measurements associated with blood glucose monitoring can be relatively small. The amount of data exchanged during the procedure to establish and maintain the connection may be larger than the size of individual measurements. Therefore, it may be inefficient for the user computer device 140 to upload each measurement as it arrives. The user computer device 140 can package the data for transmission based on the size of the target payload (e.g., file size, number of measurements, etc.), the time associated with the measurements (e.g., covering a target period), the time since the data was last uploaded, etc.

[0133] For example, the user computer device 140 can remove any personally identifiable information from the data of the patient from whom the data was collected. The user computer device 140 can also remove information that could be used to identify a specific individual (for example, the identity of the specific dedicated data receiving device 120 used to collect the data). By anonymizing the data, the low-power medical monitoring system can be understood as supporting programs that rely on such anonymized data for research and public health decisions, while also supporting efforts to protect patient privacy and confidentiality. After deidentifying the data, the user computer device 140 can simply upload the collected data to a remote cloud server 150 using the established connection.

[0134] As embodied herein, the user computer device 140 may continue to follow the process outlined in the message flow 900 as a method of execution under the security architecture. Furthermore, although described as being performed by the user computer device 140, sensitive medical data may be deidentified by other devices of the low-power medical monitoring system, such as the dedicated data receiving device 120 or the multipurpose data receiving device 130, before the data is sent to the user computer device 140, or by the remote cloud server 150 after the data has been sent by the user computer device 140.

[0135] In step 930, the user computer device 140 and the remote cloud server 150 may perform a mutual authentication exchange, for example, the mutual authentication exchange described herein, to verify that the devices can access and process the same root key and other security key information. As embodied herein, the root key and device-specific key used in this exchange may differ from the root key and device-specific key used in exchanges between the sensor 110 and the multipurpose data receiving device 130 or the dedicated data receiving device 120 and the user computer device 140, for example. In step 935, the user computer device 140 may transmit a device secret 935 to the remote cloud server 150, the device secret may form part of the information used to derive a device-specific cryptographic key that forms the basis of the cryptography used while transmitting a payload containing sensitive medical data. As embodied herein, the device secret may include a random value to ensure that a particular device secret transmitted in 935 is specific to the communication session between the user computer device 140 and the remote cloud server 150. The device secret may be encrypted before or during transmission to prevent third parties from accessing the secret. In step 940, the remote cloud server 150 and the user computer device 140 can derive a device-specific encryption key.

[0136] As embodied herein, the mutual authentication process or procedure described herein for determining a device-specific cryptographic key can also enable both the user computer device 140 and the remote cloud server 150 to establish a unique association between a specific authentication or cryptographic key and the device from which it was derived. For example, the user computer device 140 and the remote cloud server 150 can each associate the key used to communicate with other devices with their respective devices so that at some point in the communication, they can verify that data encrypted using the device-specific cryptographic key (or data transmitted by another device) was encrypted by the correct device. In this way, the security protocols described herein can be used to avoid so-called "man-in-the-middle attacks" in which a third party attempts to obtain authentication information related to data transmission and use that information as if it were associated with the third party. For example, by performing "certificate pinning" using the authentication key or device-specific cryptographic key used during mutual authentication, the user computer device 140 and the remote cloud server 150 can each independently verify that data packets transmitted between the two devices have not been intercepted by the other party.

[0137] In step 945, the user computer device 140 can encrypt the payload containing sensitive medical data (e.g., medical data including patient personal identification information) using a device-specific encryption key. As previously described, since the user computer device 140 has access to a larger computing power store, it can use more complex encryption ciphers than those available to less powerful devices within the low-power medical device monitoring system.

[0138] During the normal operation of the low-power medical device monitoring system 100, individual measurements can undergo multiple rounds of encryption and decryption as data is transmitted from the sensor 110 to the dedicated data receiving device 120 and from the user computer device 140 to the remote cloud server 150, with each step using a different key and an increasingly complex level of encryption. For example, when transmitting measurements from the sensor 110 to the dedicated data receiving device 120, the measurements can be encrypted using lightweight encryption based on a sensor-specific key. The dedicated data receiving device 120 can then decrypt and repackage the measurements and re-encrypt them using more complex encryption based on a reader-specific key before transmitting them to the user computer device 140. Similarly, the user computer device 140 can decrypt and repackage the measurements and re-encrypt them using even more complex encryption based on a device-specific key before transmitting them to the remote cloud server. Since reading is encrypted and decrypted at each stage, there is no need to share encryption keys between devices of varying complexity (and durability levels). Thus, even if, for example, the sensor-specific key is leaked, other keys, such as the user computer device key, remain unaffected. Furthermore, since each device will have more available computing resources and power, more complex encryption can be used. As described herein, at certain stages, the data can optionally be passed to another level of device without being decrypted and re-encrypted.

[0139] In step 950, the user computer device 140 can segment the payload into multiple transmit packets. Optionally, the user computer device 140 can segment the payload before encrypting it using a device-specific encryption key. Thus, the user computer device 140 can encrypt each of the payload segments using a device-specific encryption key. As embodied herein, it may be advantageous for the user computer device 140 to segment the payload into packets before transmission. Packeting the payload can improve the stability of communication with the remote cloud server 150 because the system can more easily recover data lost during transmission without transmitting the entire remainder of the payload. Such a protocol may include additional integrity checks to verify that individual packets have been received by the remote cloud server 150. Furthermore, although not illustrated, the remote cloud server 150 may send periodic acknowledgments of received packets so that the user computer device 140 can efficiently initiate a retransmission procedure as needed. Additionally, the user computer device 140 can apply any appropriate compression technique to the payload data to minimize the file size of the data that must be transmitted.

[0140] In step 955, the user computer device 140 transmits the encrypted payload to the remote computer device 140. As described herein, the user computer device 140 can transmit the data using any suitable communication protocol that provides individual packet protection to the payload, in addition to the block cipher applied to the payload before transmission begins (e.g., HTTPS, SFTP, FTPS, SSL, etc.). By using a communication protocol that provides such protection, the user computer device 140 can further support data protection as the nature of the data becomes more obscured from third parties. As embodied herein, the user computer device 140 and the remote cloud server 150 can alternatively omit the use of ciphers based on device-specific encryption keys and instead rely on a selected protocol that provides individual packet-level protection.

[0141] In step 960, the remote cloud server 150 receives and reconstructs the payload 960 from the received data packets. The remote cloud server 150 can identify any packets lost during transmission and request that they be retransmitted by the user computer device 140. Reconstructing the payload 960 may include reassembling the payload from the collection of packets. In step 965, the remote cloud server 150 may decrypt the payload using a device-specific encryption key. The remote cloud server 150 may confirm the successful reception of the payload content, for example, through the use of a checksum or other error detection code. In step 970, the remote cloud server 150 may send an acknowledgment of the payload to the user computer device 140. The acknowledgment may include a message indicating that sensitive medical data has been received. As embodied herein, the acknowledgment may also be encrypted and delivered using a communication protocol that provides packet-level encryption. Alternatively, since the acknowledgment may optionally not contain sensitive data, the acknowledgment may be sent unencrypted or in plaintext.

[0142] Embodiments described herein may, where appropriate, repeat one or more steps of the method in Figure 9. While this disclosure describes and illustrates specific steps of the method in Figure 9 as occurring in a specific order, this disclosure intends that any suitable steps of the method in Figure 9 may occur in any suitable order. Furthermore, while this disclosure describes and illustrates exemplary methods for encrypting and transmitting sensitive medical data, including specific steps of the method in Figure 9, this disclosure assumes any suitable method for encrypting and transmitting sensitive medical data, including any suitable steps, which may include all, some, or any of the steps of the method in Figure 9. Furthermore, while this disclosure describes and illustrates specific components, devices, or systems for performing specific steps of the method in Figure 9, this disclosure intends that any suitable combination of any suitable components, devices, or systems may perform any suitable steps of the method in Figure 9.

[0143] As described herein, to secure the transmission and storage of sensitive medical data in the low-power medical monitoring system 100, more complex encryption functions can be employed by devices further downstream from the sensor 110, which have relatively few limitations regarding processing power. For example, sensitive medical data can be encrypted by the sensor 110 using a first cryptographic function and based on a first cryptographic key before and during transmission between the sensor 110 and the dedicated data receiving device 120. The first cryptographic function can be a lightweight cryptographic function (e.g., a lightweight block cipher or a lightweight stream cipher) as described herein. Next, when the sensitive medical data is transmitted to the user computer device 140, the sensitive medical data can be encrypted using a second cryptographic function and based on a second cryptographic key before and during transmission to the user computer device 140. The second cryptographic function can be more complex than the first cryptographic function. The second cryptographic key can be different from the first cryptographic key.

[0144] As another example, sensitive medical data may be encrypted by sensor 110 before and during transmission between sensor 110 and multipurpose data receiving device 130 using a first cryptographic function and based on a first cryptographic key. The first cryptographic function may be a lightweight cryptographic function as described herein (e.g., a lightweight block cipher or a lightweight stream cipher). When sensitive medical data is transmitted by multipurpose data receiving device 130 to a user computer device 140 or a remote cloud server 150, the sensitive medical data may be encrypted before and during transmission using a second cryptographic function and based on a second cryptographic key. The second cryptographic function may be a more complex cryptographic function than the first cryptographic function, as described herein. The second cryptographic key may be different from the first cryptographic key. In addition, or alternatively, the transmission of sensitive medical data may be encrypted with packet-level encryption or other application-level, transport-level, or network-level encryption appropriate to the communication medium and protocol selected for transmission.

[0145] In addition or alternatively, as embodied herein, the user computer device 140 may use a more complex encryption scheme when transmitting data to the remote cloud server 140. For example, sensitive medical data may be encrypted by the sensor 110 using a first cryptographic function and based on a first cryptographic key before and during transmission between the sensor 110 and the dedicated data receiving device 120 or the multipurpose data receiving device 140. The first cryptographic function may be a lightweight cryptographic function as described herein (e.g., a lightweight block cipher or a lightweight stream cipher). Next, when the sensitive medical data is transmitted to the user computer device 140 by the dedicated data receiving device 120 or the multipurpose data receiving device 130, the sensitive medical data may be encrypted before and during transmission using a second cryptographic function and based on a second cryptographic key. The second cryptographic function may be more complex than the first cryptographic function. The second cryptographic key may be different from the first cryptographic key. When confidential medical data is transmitted from a user computer device 140 to a remote cloud server 150, the confidential medical data may be encrypted before and during transmission using a third cryptographic function and based on a third cryptographic key. The third cryptographic function may be more complex than both the first and second cryptographic functions. The third cryptographic key may be different from both the first and second cryptographic keys. In addition, or alternatively, the transmission of confidential medical data from the user computer device 140 to the remote cloud server 150 may be encrypted with packet-level encryption or other application-level, transport-level, or network-level encryption appropriate to the communication medium and protocol selected for transmission.

[0146] The following is an example of a request and the data it may contain that can be sent between the user computer device 140 and the remote cloud server. As embodied herein, the results and specifications of a request may be formatted in JSON or XML format, however, it should be understood that any suitable data packaging method may be used.

[0147] As described herein, upon initial connection to the remote cloud server 150, the user computer device 140 can call the UpdateCheck function of the remote cloud server 150. The UpdateCheck function causes the remote cloud server 150 to check the current software or firmware version in use and compare the current version with the version used by the user computer device (or other devices within the low-power medical monitoring system 150). The UpdateCheck function call can pass the collected values ​​to the appropriate update comparison module associated with the remote cloud server 150. The UpdateCheck function call may include, but is not limited to, values ​​such as application identifiers and version numbers, operating system identifiers and version numbers, identifiers corresponding to the dedicated data receiving device 120, the multipurpose data receiving device 130, or the user computer device 140, descriptors relating to the operating environment of the dedicated data receiving device 120, the multipurpose data receiving device 130, or the user computer device 140, and security tokens or security keys.

[0148] As described herein, the user computer device 140 may decide to send anonymized or despecified data to a data mining remote cloud server 150. The data mining server may collect data for the purpose of large-scale analysis for low-power monitoring system providers or various other sources. After despecifying the data, the user computer device 140 may call the MiningDataUpload function of the remote cloud server 150. The MiningDataUpload function causes the remote cloud server 150 to receive and process the despecified data for use for data mining purposes. The MiningDataUpload function call may, by example but not limited to, values ​​such as time since reset, firmware or software version, life count of sensor 110, or device settings associated with sensor 110 including nicknames, measurement logs including measured analyte values, food log entries; records associated with scheduled and unscheduled entries associated with the measurement of an analyte, such as time since initialization, startup, reset, or time change, measurement identifier, measurement timestamp, analyte value, trend value and direction associated with the analyte, and indication of whether the measurement is feasible.

[0149] As embodied herein, scheduled analyte entries may include timestamp values ​​corresponding to analyte measurements taken at predetermined intervals, such as 1-minute, 5-minute, or 15-minute intervals, or any other appropriate interval. In addition or alternatively, unscheduled analyte entries may include timestamp values ​​corresponding to analyte measurements taken in response to inputs or conditions, such as user scanning of the sensor, user viewing of the dedicated data receiving device 120 or the multipurpose data receiving device 130, or conditions determined by the sensor.

[0150] The user computer device 140 can further call the UnencryptedDataUpload function of the remote cloud server 150. The UnencryptedDataUpload function can deliver a payload containing non-confidential data to the remote cloud server 150. The UnencryptedDataUpload function call may, for example, include, but are not limited to, values ​​such as the device domain corresponding to the measured analyte or role, connection gateway identifier, user token, identifier of the type of content included in all functions, notification of the length of the provided content, and / or expected content.

[0151] A GetVersion call may include a UserToken. The UserToken can be encoded using any suitable encoding technique (e.g., Base64URL). The UserToken may include a header portion and a payload portion. The header portion can be decoded to identify the algorithm used to encode the payload. The receiving end (e.g., a remote cloud server 150) can decode the payload portion of the token using the identified algorithm to determine the token identifier of the sensor 110 or the user, user identification information of the sensor 110 or the user, including but not limited to the name, location, and preferred units of the analyte.

[0152] The user computer device 140 can further call the EncryptedDataUpload function of the remote cloud server 150. The EncryptedDataUpload function can deliver a payload containing sensitive data to the remote cloud server 150. As embodied herein, the payload may contain any or all of the payload data returned from the MiningDataUpload function, along with personal data about the user, including but not limited to specific sensors used by the user. Thus, device data containing sensitive data can be encrypted according to the procedure described herein. The EncryptedDataUpload function call may include values ​​including, but not limited to, data extraction timestamp, encoded data, device identifier, application version, startup time, initialization time, and diagnostic information including operating system identifier, drive identifier, driver key, gateway and / or connection information, device group identifier, sensor time, device serial number, and timestamp mismatch check.

[0153] The user computer device 140 can further call the RetrieveData function of the remote cloud server 150. The RetrieveData function can transmit information to identify a device or patient. Alternatively, the user computer device 140 can receive historical information about data stored by the remote cloud server 150. As embodied herein, the RetrieveData function can be used to retrieve information uploaded from the first user computer device for viewing on a second user computer device. The RetrieveData function call and return information may include, but are not limited to, data such as a device identifier, device type identifier, diagnostic information associated with the device, data retrieval time, device operating environment data, identification of the most recent device uploading data for the user, upload start time, connection and / or gateway identifier, user identifier, upload identifier, and upload path for each quanta of uploaded data.

[0154] In response to the RetrieveData function, the remote cloud server 150 may deliver a payload containing a list of devices that interacted with the sensor, along with additional data associated with device usage history and / or data measured by or stored on the device. The list of devices and data may include, but is not limited to, information such as data for creating data records, identification, nickname, serial number or type associated with the device, upload date of data uploaded from the device, timestamp associated with the data, analyte measurement count associated with the data, food input log, counts associated with scheduled and unscheduled data collection events associated with each device, user identifiers, and serial numbers associated with the device or user.

[0155] The user computer device 140 can further call the GetAnalyteHistory function of the remote cloud server 150. The GetAnalyteHistory function can retrieve data stored by the remote cloud server 150. The GetAnalyteHistory function can provide the stored information for viewing on the user computer device 140. The data returned by the remote cloud server 150 may include, but are not limited to, the identifier of the device that provided the analyte data, the data of the last upload by one or more of the device and / or device types, the raw analyte measurement, the mean analyte measurement, the number of test events recorded over a period of time, the range of the analyte measurement over a period of time, the extreme values ​​and other statistical measures (including quartile measurements) of the analyte measurement over a period of time, the data collection start date, the data collection end date, the data collection time range, and the count of events in which the analyte was above or below a threshold.

[0156] In addition to the specific embodiments described and claimed below, the disclosed subject matter is also directed to other embodiments having the dependent features claimed below and any other possible combination of those disclosed above and in the accompanying drawings. Thus, it will be recognized that the specific features disclosed herein can be combined with one another in other ways within the scope of the disclosed subject matter, and that the disclosed subject matter is particularly directed to other embodiments having any other possible combinations. Accordingly, the above description of specific embodiments of the disclosed subject matter is presented for illustrative and explanatory purposes. The above description of specific embodiments of the disclosed subject matter is not intended to be exhaustive or to limit the disclosed subject matter to these disclosed embodiments.

[0157] Those skilled in the art will understand that various modifications and variations can be implemented in the methods and systems of the disclosed subject matter without departing from the technical idea or scope of the disclosed subject matter. Accordingly, the disclosed subject matter is intended to include modifications and variations that fall within the scope of the appended claims and their equivalents.

[0158] Embodiments disclosed herein include the following: A. A method for secure communication between a medical sensor and a computer device, comprising: the steps of: the medical sensor receiving an authentication request from a computer device; generating a challenge-response message for the computer device based on a value provided in the authentication request; receiving a responded challenge-response message from the computer device; verifying that the responded challenge-response message includes an expected value and corresponds to an expected format; and transmitting a sensor secret value to the computer device in response to verifying the responded challenge-response message.

[0159] B. A method comprising: a first computer device receiving a sensor secret value from a medical sensor; the first computer device receiving a set of encrypted medical measurements from the medical sensor using a first encryption operation on unencrypted medical measurements based on a first key derived from the sensor secret value, wherein the encryption operation includes performing an addition-rotation-XOR operation on the unencrypted medical data; the first computer device deriving a first key based on the sensor secret value; and the first computer device decrypting the set of medical measurements using the first key derived by the encryption operation.

[0160] C. A method for secure communication between a medical sensor and a computer device, comprising: the steps of: the medical sensor receiving an activation signal from a computer device via a short-range communication protocol; the medical sensor verifying one or more authentication values ​​associated with the computer device in response to the activation signal; and, having successfully verified the authentication values ​​associated with the computer device, the medical sensor collecting sensor information from a patient.

[0161] D. A medical sensor arranged to provide secure communication with a computer device, comprising: means for receiving an authentication request from the computer device; means for generating a challenge-response message for the computer device based on a value provided in the authentication request; means for receiving a responded challenge-response message from the computer device; means for verifying that the responded challenge-response message includes an expected value and corresponds to an expected format; and means for transmitting a sensor secret value to the computer device in response to the verification of the responded challenge-response message.

[0162] E. A first computer device comprising: means for receiving a sensor secret value from a medical sensor; means for receiving a set of encrypted medical measurements from the medical sensor using a first encryption operation on unencrypted medical measurements based on a first key derived from the sensor secret value, wherein the encryption operation includes performing an addition-rotation-XOR operation on unencrypted medical data; means for deriving a first key based on the sensor secret value; and means for decrypting the set of medical measurements using the first key derived by the encryption operation.

[0163] F. A medical sensor arranged to provide secure communication with a computer device, comprising: means for receiving an activation signal from the computer device via a short-range communication protocol; means for verifying one or more authentication values ​​associated with the computer device in response to the activation signal; and means for collecting sensor information from a patient once the authentication values ​​associated with the computer device have been successfully verified.

[0164] G. A computer program, computer program product, or computer-readable medium that, when executed by a computer device or medical sensor, includes instructions causing the computer device or medical sensor to perform a step of any of the methods of Embodiment A, B, or C.

[0165] Each of embodiments A, B, C, D, E, F, and G may have one or more of the following additional elements in any combination: Element 1: The sensor secret value includes data specific to the medical sensor and one or more random values. Element 2: The one or more random values ​​are based on a predefined value provided to the medical sensor, a value generated by the medical sensor's communication module, or a value generated in response to user interaction. Element 3: The medical sensor further includes the steps of collecting sensor information from a patient and encrypting the sensor information using an encryption key derived from the sensor secret value. Element 4: The medical sensor further includes the step of transmitting the encrypted sensor information to a computer device using a short-range communication protocol. Element 5: The sensor information includes medical data relating to the patient. Element 6: The medical data includes body temperature, heart rate, blood glucose level, or measurement of activity. Element 7: The step of encrypting the sensor information includes encoding the sensor information with a power-efficient stream cipher or block cipher based on the encryption key. Element 8: The medical sensor further includes the steps of receiving an activation signal from a computer device via a near-field communication protocol, verifying one or more authentication values ​​associated with the computer device in response to the activation signal, and, if the authentication values ​​associated with the computer device have been successfully verified, collecting sensor information from the patient via the medical sensor. Element 9: The activation signal further supplies radio power to one or more of the communication modules of the medical sensor. Element 10: The medical sensor uses the information received via the near-field communication protocol to establish a connection with the computer device via a second near-field communication protocol without requiring additional verification from the patient. Element 11: The near-field communication protocol includes near-field communication, and the second near-field communication protocol includes Bluetooth Low Energy.

[0166] Element 12: The above addition-rotation-XOR operation includes the steps of: segmenting an unencrypted medical measurement into a series of data blocks; segmenting each data block into two or more words; for each data block, rotating the bits of the first word of the two or more words in the data block by a first fixed amount; adding a second word of the two or more words in the block; performing a bitwise XOR operation of the first key on the first word; rotating the bits of the second word by a second fixed amount; and performing a bitwise XOR operation of the first word on the second word. Element 13: Encrypting the decrypted medical measurement using a second key and a second cryptographic function, wherein the second key includes information specific to the first computer device and a random value generated by the first computer device; and transmitting the encrypted medical measurement to the second computer device. Element 14: The second cryptographic function is different from the first cryptographic function in that it is computationally more complex than the first cryptographic function. Element 15: The second cryptographic function is different from the first cryptographic function in that it is computationally more complex than the first cryptographic function. Element 15: The encrypted medical measurement is transmitted to a second computer device via wired or wireless communication. Element 16: The encrypted medical measurement is transmitted using a packet-level coding computer protocol. Element 17: The second computer device further includes the steps of decrypting the encrypted medical measurement, encrypting the medical measurement with a third cryptographic function based on a third key, and then transmitting the decrypted medical measurement to the third computer device, wherein the first key, second key, and third key are all different and derived from all different root values, and the first cryptographic function, second cryptographic function, and third cryptographic function are all different. Element 18: The sensor secret value includes an intrinsic value associated with the medical sensor and a random value generated by the medical sensor.

[0167] Element 19: The activation signal further supplies wireless power to one or more communication modules of the medical sensor. Element 20: The medical sensor uses the information received via the Near Field Communication protocol to establish a connection with a computer device via a second Near Field Communication protocol without requiring additional verification from the patient. Element 21: The first Near Field Communication protocol includes Near Field Communication, and the second Near Field Communication protocol includes Bluetooth Low Energy.

[0168] Element 22: Further comprises means for carrying out the method described in any of Elements 1 to 11.

[0169] Element 23: Further comprises means for carrying out the method described in any of Elements 12 to 18.

[0170] Element 24: Further comprises means for carrying out the method described in any of elements 19 to 21.

[0171] As a non-limiting example, exemplary additions or combinations applicable to Embodiment A include element 1 and any of elements 2-11; element 2 and any of elements 1 and 3-11; element 3 and any of elements 1-2 and 4-11; element 4 and any of elements 1-3 and 5-11; element 5 and any of elements 1-4 and 6-11; element 6 and any of elements 1-5 and 7-11; element 7 and any of elements 1-6 and 8-11; element 8 and any of elements 1-7 and 9-11; element 9 and any of elements 1-8 and 10-11; element 10 and any of elements 1-9 and 11; and element 11 and any of elements 1-10.

[0172] As a non-limiting example, exemplary additions or combinations applicable to Embodiment B include element 12 and any of elements 13-18; element 13 and any of elements 12 and 14-18; element 14 and any of elements 12-13 and 15-18; element 15 and any of elements 12-14 and 16-18; element 16 and any of elements 12-15 and 17-18; element 17 and any of elements 12-16 and 18; and element 18 and any of elements 12-17.

[0173] As a non-limiting example, exemplary additions or combinations applicable to Embodiment C include element 19 and any of elements 20-21; element 20 and any of elements 19 and 21; and element 21 and any of elements 19-20.

[0174] As a non-limiting example, exemplary additions or combinations applicable to Embodiment D include element 22.

[0175] As a non-limiting example, exemplary additions or combinations applicable to Embodiment E include element 23.

[0176] As a non-limiting example, exemplary additions or combinations applicable to Embodiment F include element 24.

[0177] Additionally or alternatively, any element and combination applicable to embodiments A, B, C, D, E, F, and G may be applicable to any other element and combination applicable to embodiments A, B, C, D, E, F, and G. [Explanation of Symbols]

[0178] 110 Sensor 120 Dedicated data receiving device 130 Multipurpose Data Receiving Devices / Applications 140 User Devices 150 Remote Cloud Servers

Claims

1. A method for secure communication between a medical sensor and a computer device, The medical sensor receives an authentication request from the computer device, The steps include generating a challenge-response message for the computer device based on the value provided in the authentication request, The steps include receiving a challenge-response message from the aforementioned computer device, The step of verifying that the aforementioned challenge-response message includes the expected value and corresponds to the expected format, In response to the step of verifying the challenge response message that was responded to, the step of sending the sensor secret value to the computer device, Methods that include...

2. The method according to claim 1, wherein the sensor secret value includes data specific to the medical sensor and one or more random values.

3. The method according to claim 2, wherein the one or more random values ​​are based on a predefined value provided to the medical sensor, a value generated by the medical sensor's communication module, or a value generated in response to user interaction.

4. The steps include: collecting sensor information from the patient using the aforementioned medical sensor; The steps include: encrypting the sensor information using an encryption key derived from the sensor secret value; The method according to any one of claims 1 to 3, further comprising:

5. The method according to claim 4, further comprising the step of transmitting the encrypted sensor information to the computer device using a short-range communication protocol.

6. The method according to claim 4 or 5, wherein the sensor information includes medical data relating to the patient.

7. The method according to claim 6, wherein the medical data includes body temperature, heart rate, blood glucose level, or measurement of activity.

8. The method according to any one of claims 4 to 7, wherein the step of encrypting the sensor information comprises encoding the sensor information with a power-efficient stream cipher or block cipher based on the encryption key.

9. The medical sensor receives an activation signal from the computer device via a short-range communication protocol, The steps include verifying one or more authentication values ​​associated with the computer device in response to the activation signal, The steps include: successfully verifying the authentication value associated with the computer device, collecting sensor information from the patient using the medical sensor, The method according to any one of claims 1 to 8, further comprising:

10. The method according to claim 9, wherein the activation signal further supplies wireless power to one or more of the communication modules of the medical sensor.

11. The method according to claim 9, wherein the medical sensor uses information received via the short-range communication protocol to establish a connection with the computer device via a second short-range communication protocol without requiring additional verification from the patient.

12. The method according to claim 11, wherein the short-range communication protocol includes short-range communication, and the second short-range communication protocol includes Bluetooth Low Energy.

13. It is a method, The first computer device receives a sensor secret value from a medical sensor, The first computer device receives from the medical sensor a set of encrypted medical measurements created using a first encryption operation on unencrypted medical measurements based on a first key derived from the sensor secret value, wherein the first encryption operation includes performing an addition-rotation-XOR operation on the unencrypted medical data. The first computer device derives the first key based on the sensor secret value; The first computer device decrypts the set of medical measurement values ​​using the first key derived by the first encryption operation, Methods that include...

14. The aforementioned addition-rotation-XOR operation is, The steps include segmenting the unencrypted medical measurements into a series of data blocks, The steps include segmenting each of the aforementioned data blocks into two or more words, For each of the aforementioned data blocks, The steps include rotating the bits of the first word among the two or more words of the data block by a first fixed amount, The steps include adding a second word from the two or more words in the data block, The steps include performing a bitwise XOR operation on the first word with the first key, The steps include rotating the bits of the second word by a second fixed amount, The steps include performing a bitwise XOR operation of the first word on the second word, The method according to claim 13, including the method described in claim 13.

15. The steps of: encrypting the decrypted medical measurement using a second key and a second cryptographic function, wherein the second key includes information specific to the first computer device and a random value generated by the first computer device; The steps include transmitting the encrypted medical measurement data to a second computer device, The method according to claim 13 or 14, further comprising:

16. The method according to claim 15, wherein the second encryption function is different from the first encryption function and is computationally more complex than the first encryption function.

17. The method according to claim 15 or 16, wherein the encrypted medical measurement values ​​are transmitted to the second computer device via wired or wireless communication.

18. The method according to any one of claims 15 to 17, wherein the encrypted medical measurement is transmitted using a packet-level coding computer protocol.

19. The second computer device decrypts the encrypted medical measurement data, A step of encrypting the medical measurement using a third cryptographic function based on a third key, and then transmitting the decrypted medical measurement to a third computer device, wherein the first key, the second key, and the third key are all different and derived from all different root values, and the first cryptographic function, the second cryptographic function, and the third cryptographic function are all different. The method according to any one of claims 15 to 18, including

20. The method according to any one of claims 13 to 19, wherein the sensor secret value includes an eigenvalue associated with the medical sensor and a random value generated by the medical sensor.

21. A method for secure communication between a medical sensor and a computer device, The medical sensor receives an activation signal from the computer device via a short-range communication protocol, The steps include verifying one or more authentication values ​​associated with the computer device in response to the activation signal, The steps include: successfully verifying the authentication value associated with the computer device, collecting sensor information from the patient using the medical sensor, Methods that include...

22. The method according to claim 21, wherein the activation signal further supplies wireless power to one or more communication modules of the medical sensor.

23. The method according to claim 21, wherein the medical sensor uses information received via the short-range communication protocol to establish a connection with the computer device via a second short-range communication protocol without requiring additional verification from the patient.

24. The method according to claim 23, wherein the short-range communication protocol includes short-range communication, and the second short-range communication protocol includes Bluetooth Low Energy.

25. A medical sensor arranged to provide secure communication with a computer device, Means for receiving authentication requests from the aforementioned computer device, Means for generating a challenge-response message for the computer device based on the value provided in the authentication request, Means for receiving a challenge-response message from the aforementioned computer device, A means for verifying that the aforementioned challenge-response message includes an expected value and corresponds to an expected format, Means for transmitting a sensor secret value to the computer device in response to verifying the challenge response message received, A medical sensor equipped with the following features.

26. The medical sensor according to claim 25, further comprising means for carrying out the method according to any one of claims 2 to 12.

27. A first computer device, A means of receiving sensor secret values ​​from a medical sensor, Means for receiving a set of encrypted medical measurements from the medical sensor, created using a first encryption operation on unencrypted medical measurements based on a first key derived from the sensor secret value, wherein the first encryption operation includes performing an addition-rotation-XOR operation on the unencrypted medical data. Means for deriving the first key based on the sensor secret value, A means for decrypting the set of medical measurement values ​​using the first key derived by the first encryption operation, A first computer device comprising the following:

28. The first computer device according to claim 27, further comprising means for carrying out the method according to any one of claims 14 to 20.

29. A medical sensor arranged to provide secure communication with a computer device, Means for receiving an activation signal from the computer device via a short-range communication protocol, Means for verifying one or more authentication values ​​associated with the computer device in response to the activation signal, When the authentication value associated with the aforementioned computer device is successfully verified, the means for collecting sensor information from the patient, A medical sensor equipped with the following features.

30. The medical sensor according to claim 29, further comprising means for carrying out the method according to any one of claims 22 to 24.

31. A computer program, computer program product, or computer-readable medium that, when executed by a computer device or medical sensor, includes instructions causing the computer device or medical sensor to perform steps of the method according to any one of claims 1 to 20.

Images