Secure health management system

Abstract

Techniques and protocols for establishing secure communications between a display device, a sensor system, and a server system are disclosed. In certain embodiments, the techniques and protocols include secure diabetes device identification techniques and protocols, user-centric mutual authentication techniques and protocols, and device-centric mutual authentication techniques and protocols.

Description

[Technical Field]

[0001] (Cross-reference of related applications) This application claims the benefit of U.S. Patent Application No. 63 / 021591, filed on 7 May 2020, entitled “SECURE DIABETES MANAGEMENT SYSTEM.” The aforementioned application is incorporated herein by reference in its entirety.

[0002] This application relates, in general, to medical devices such as analyte sensors, and more specifically to systems, devices, and methods related to secure communication between medical devices and other communication devices in diabetes management systems. [Background technology]

[0003] (Explanation of related technologies) Diabetes is a metabolic condition related to the body's production or use of insulin. Insulin is a hormone that allows the body to use glucose as energy or to store glucose as fat.

[0004] Diabetes mellitus is a disease in which the pancreas is unable to produce enough insulin (Type 1, i.e., insulin-dependent) and / or is ineffective with insulin (Type 2, i.e., non-insulin-dependent). In the diabetic state, affected individuals suffer from hyperglycemia, which leads to a number of physiological abnormalities associated with microvascular deterioration (renal failure, skin ulcers, or vitreous hemorrhage of the eye). Hypoglycemic reactions (hypoglycemia) can be triggered by inadvertent overdose of insulin, or by extreme exercise or insufficient food intake after normal administration of insulin or glucose-lowering agents.

[0005] Traditionally, diabetic patients carry self-monitoring blood glucose (SMBG) monitors, which can require an uncomfortable finger-pricking method. Due to the lack of comfort and convenience, diabetic patients typically only measure their glucose levels 2 to 4 times a day. However, these time intervals are so far apart that diabetic patients may not notice hyperglycemia or hypoglycemia until later, potentially leading to dangerous side effects. In reality, diabetic patients rarely obtain SMBG readings promptly, and furthermore, due to the limitations of conventional methods, they cannot know whether their blood glucose levels are rising (high) or falling (low).

[0006] As a result, a variety of non-invasive, transdermal (e.g., transcutaneous), and / or implantable sensors have been developed for the continuous detection and / or quantification of blood glucose levels. Generally, in diabetes management systems, these sensors wirelessly transmit raw or minimally processed data for subsequent display and / or analysis to one or more remote devices, which may include a display device, server, or any other type of communication device. The remote device, such as a display device, can then utilize a reliable (e.g., approved and / or provided by the sensor manufacturer) software application, which ingests the raw or minimally processed data and provides the user with information regarding their blood glucose levels. Diabetes management systems using such implantable sensors can provide users with more up-to-date information, thereby reducing the risk of users failing to regulate their own blood glucose levels.

[0007] However, using wireless connections between transdermal analyzer sensors and one or more remote devices based on existing wireless communication protocols may expose the sensor and / or remote devices to security, integrity, privacy, and availability issues (e.g., the possibility of the sensor and / or remote devices becoming unusable as a result of a malicious attack). For example, an attacker could use a malicious device impersonating a sensor to connect to a user's display device and transmit inaccurate data (e.g., inaccurate blood glucose levels) to harm the user. In another example, an attacker could use a malicious device to impersonate a user's display device or software application and run the software application on the user's display device to access the user's sensor. In such an example, the attacker could receive the user's sensor data (e.g., blood glucose levels), thereby violating patient privacy. Also in such an example, the attacker could transmit data to the sensor, causing the sensor or its electronic circuitry to malfunction. For example, a malicious or impersonated display device could miscalibrate the sensor, thereby causing the sensor to provide inaccurate blood glucose measurements. Furthermore, in the same example, an attacker could disrupt a communication session already established by the user between the user's sensors and the user's own display device running a trusted software application. In other specific examples, the user themselves might connect to their sensors using an unauthenticated software application that may be running on the user's own display device. In such examples, the unauthenticated software application may not have the necessary security measures in place to ensure the security and safety of the user's data.

[0008] Furthermore, according to guidelines from regulatory bodies (e.g., the Federal Drug Administration (FDA)), medical devices may require strict security (e.g., cybersecurity) protocols, and certification may be required for each of the aforementioned devices and the software applications running on them. This helps to alleviate some of the safety, integrity, privacy, and availability issues mentioned above.

[0009] This background is provided to introduce a brief context to the following summary and detailed description. This background is not intended to aid in defining the scope of the claimed subject matter, and the claimed subject matter should not be considered limited to an implementation that solves any or all of the disadvantages or problems presented above. [Overview of the project]

[0010] Certain embodiments of the present disclosure provide a method for performing a diabetes device identification protocol between a sensor system for measuring blood glucose levels and a display device, wherein the method performs the diabetes device identification protocol on the display device to identify the sensor system. Performing this includes obtaining a token ID of the sensor system on the display device. Performing this further includes calculating a first sensor system identifier based on the token ID. Performing this further includes receiving a second sensor system identifier from the sensor system. Performing this further includes determining whether the first sensor system identifier and the second sensor system identifier are identical. Performing this further includes identifying that the sensor system is associated with a user of the display device, based on the determination that the first sensor system identifier and the second sensor system identifier are identical. In response to the identification, the method further includes receiving analytic data indicating blood glucose levels from the sensor system on the display device.

[0011] In the above method, calculating the first sensor system identifier includes performing a hash function to hash the token ID and performing a truncation function to truncate the hash value, wherein the hash value is the first sensor system identifier. In the above method, calculating the first sensor system identifier includes performing a truncation function to truncate the token ID to obtain the truncated token ID and performing a hash function to hash the truncated token ID, wherein the hash value is the first sensor system identifier. In the above method, the display device is configured to communicate with the sensor system only when the received signal from the sensor system has a received signal strength that exceeds a threshold. In the above method, each of the sensor system and the display device is configured to reduce the transmit power when implementing the diabetes device identification protocol and to increase the transmit power for transmitting analyte data.

[0012] Certain embodiments of the present disclosure provide a method for secure wireless communication between a sensor system for measuring blood glucose levels and a display device, the method comprising: in the sensor system, implementing a device-centric mutual authentication protocol with the display device to verify whether the display device is trusted by a diabetes trust management system. Implementing this includes receiving one or more certificates of the display device to verify whether the display device is trusted by the diabetes trust management system, the one or more certificates of the display device including a certificate token of the display device. Implementing this further includes verifying one or more certificates of the display device, the verification including authenticating the certificate token of the display device. Implementing this further includes transmitting one or more certificates of the sensor system to the display device for verification of one or more certificates of the sensor system by the display device. The method further includes, in the sensor system, determining, based on the implementation, that the display device is trusted by a diabetes trust management system, and, after the implementation is successful, transmitting analyte data to the display device.

[0013] In the method described above, the certificate token includes a signature and information. Authenticating the certificate token of the display includes, in the sensor system, decrypting the signature of the certificate token using the public key of the diabetes trust management system, and authenticating the certificate token when it is determined that the decrypted signature is identical to the information or a hash of the information.

[0014] In the method described above, one or more certificates of a display device include a message signed by the display device. The message includes an unencrypted first part and a signature. The signature corresponds to the encrypted first part. The encrypted first part is encrypted using the display device's private key. Verifying one or more certificates of a display device includes verifying the integrity of the display device using the message by decrypting the signature using the display device's public key and determining that the decrypted signature is identical to the unencrypted first part or a hash of the unencrypted first part.

[0015] Certain embodiments of the present disclosure provide a method for secure wireless communication between a sensor system for measuring blood glucose levels and a display device, the method comprising: in the sensor system, implementing a user-centric mutual authentication protocol with the display device to verify whether the display device is trusted by the user of the sensor system, the implementation of the user-centric mutual authentication protocol comprising: using a shared key, implementing a password-authenticated key exchange (PAKE) algorithm with the display device. The method further comprises, after the implementation is successful, determining in the sensor system that the display device is trusted by the user of the sensor system. The method further comprises, in the sensor system, transmitting analyte data to the display device based on the determination.

[0016] In the above method, the shared key is a pairing code associated with the sensor system. In the above method, implementing the PAKE algorithm includes deriving an authentication key. The above method further includes implementing a key verification protocol with the display device to verify whether the display device also possesses the authentication key. In the above method, implementing the display device and key verification protocol includes: the sensor system receiving a first challenge value; the sensor system hashing the first challenge value and generating a first hash value using a hashing algorithm and an authentication key; transmitting the first hash value and a second challenge value to the display device to the display device to verify whether the sensor system possesses an authentication key; the sensor system hashing the second challenge value and generating a third hash value using a hashing algorithm and an authentication key; the sensor system receiving a fourth hash value from the display device; the sensor system verifying whether the third and fourth hash values ​​are identical; and, based on the determination that the display device possesses an authentication key when verifying that the third and fourth hash values ​​are identical, the sensor system determining that the display device is trusted by the user of the sensor system.

[0017] In the above method, implementing the display device and the key verification protocol includes calculating an obfuscation key by hashing an authentication key and a random number, calculating a third hash value by hashing the obfuscation key, calculating a fourth hash value by hashing the third hash value, receiving a second hash value from the display device, verifying whether the second hash value and the fourth hash value are the same, determining that the display device is trusted by the user of the sensor system based on verifying that the second hash value and the fourth hash value are the same, sending the third hash value for the display device to the display device, and verifying whether the sensor system is trusted by the user based on verifying whether the first hash value and the third hash value are the same based on the authentication key and the random number.

[0018] In the above method, implementing the display device and key verification protocol involves: calculating an obfuscated key by hashing the authentication key and a random number; calculating a third hash value by hashing the obfuscated key; calculating a fourth hash value by hashing the third hash value; receiving the second hash value and the signed second hash value from the display device; verifying whether the second hash value and the fourth hash value are identical; and determining that the display device is trusted by the user of the sensor system based on the determination that the display device possesses the authentication key when verifying that the second hash value and the fourth hash value are identical. This includes verifying the integrity of the display device by decrypting a signed second hash value using the display device's public key and determining that the display device possesses the display device's private key based on the determination that the decrypted signed second hash value is identical to the second hash value, and verifying whether the sensor system is trusted by the user, as well as the integrity of the sensor system based on the signed third hash value, by sending a third hash value and a signed third hash value to the display device and verifying whether the first hash value and the third hash value based on the authentication key and random number are identical.

[0019] Certain embodiments of the present disclosure provide a method for secure wireless communication between a sensor system for measuring blood glucose levels and a display device. The method includes, at the display device, implementing a device-centric mutual authentication protocol with the sensor system to verify whether the sensor system is trusted by a diabetes trust management system. Implementing the device-centric mutual authentication protocol with the sensor system includes transmitting, to the sensor system, one or more certificates of the display device, the one or more certificates of the display device including a certificate token of the display device. Implementing includes receiving one or more certificates of the sensor system and verifying whether the sensor system is trusted by a diabetes trust management system, the one or more certificate information of the sensor system further including a certificate token of the sensor system. Implementing includes verifying one or more certificates of the sensor system, and verifying further includes authenticating the certificate token of the sensor system. The method further includes, after successful implementation, at the display device, determining that the sensor system is trusted by a diabetes trust management system. The method further includes, at the display device, receiving analyte data from the sensor system based on the determination.

[0020] In the above method, the certificate token includes a signature and information. Authenticating the certificate token of the sensor system includes decrypting the signature of the certificate token using the public key of the diabetes trust management system and authenticating the certificate token when it is determined that the decrypted signature is identical to the information or a hash of the information.

[0021] In the method described above, one or more certificates of a sensor system include a message signed by the sensor system. The message includes an unencrypted first part and a signature. The signature corresponds to the encrypted first part, which is then encrypted using the sensor system's private key. Verifying one or more certificates of a sensor system includes verifying the integrity of the sensor system using the message by decrypting the signature using the sensor system's public key and determining that the decrypted signature is identical to the unencrypted part or a hash of the unencrypted part.

[0022] The above method further includes engaging with the server system and cryptographic key exchange algorithm and receiving a certificate token for the display device from the server system before implementing the sensor system and device-centric mutual authentication protocol, the certificate token for the display device being signed by the diabetes trust management system.

[0023] Certain embodiments of the present disclosure provide a method for secure wireless communication between a sensor system for measuring blood glucose levels and a display device, the method comprising: in the sensor system, calculating a sensor system identifier based on information associated with the sensor system; the method further comprises transmitting the sensor system identifier to the display device to identify whether the sensor system is associated with a user of the display device; when the method identifies that the sensor system is associated with a user of the display device, the method further comprises in the sensor system implementing a device-centric mutual authentication protocol with the display device to verify whether the display device is trusted by a diabetes trust management system; the method further comprises in the sensor system determining that the display device is trusted by a diabetes trust management system; the method further comprises in the sensor system implementing a user-centric mutual authentication protocol with the display device to verify whether the display device is trusted by a user of the sensor system; the method further comprises in the sensor system determining that the display device is trusted by a user of the sensor system; the method further comprises transmitting analytic data to the display device over a secure connection, the secure connection being protected using an encryption key.

[0024] In the above method, determining in the sensor system that a display device is trusted by the diabetes trust management system includes: in the sensor system, implementing a device-centric mutual authentication protocol with the display device to verify whether the display device is trusted by the diabetes trust management system; receiving one or more certificates of the display device, which include a certificate token of the display device; verifying one or more certificates of the display device, which includes authenticating the certificate token of the display device; and transmitting one or more certificates of the sensor system to the display device for the display device to verify one or more certificates of the sensor system; and determining in the sensor system that the display device is trusted based on the actions taken.

[0025] In the method described above, the certificate token includes a signature and information. Authenticating the certificate token of the display includes, in the sensor system, decrypting the signature of the certificate token using the public key of the diabetes trust management system, and authenticating the certificate token when it is determined that the decrypted signature is identical to the information or a hash of the information.

[0026] In the method described above, one or more certificates of a display device include a message signed by the display device. The message includes an unencrypted first part and a signature. The signature corresponds to the encrypted first part. The encrypted first part is encrypted using the display device's private key. Verifying one or more certificates of a display device includes verifying the integrity of the display device using the message by decrypting the signature using the display device's public key and determining that the decrypted signature is identical to the unencrypted first part or a hash of the unencrypted first part.

[0027] In the above method, determining that a display device is trusted by the user of the sensor system means that the sensor system implements a user-centric mutual authentication protocol with the display device to verify whether the display device is trusted by the user of the sensor system, and that implementing the user-centric mutual authentication protocol includes verification, which includes implementing a password-authenticated key exchange (PAKE) algorithm with the display device using a shared key, and after the verification is successful, the sensor system determines that the display device is trusted by the user of the sensor system. In the above method, the shared key is a pairing code associated with the sensor system. In the above method, implementing the PAKE algorithm includes deriving an authentication key. The above method further includes implementing a key verification protocol with the display device to verify whether the display device also possesses an authentication key.

[0028] In the above method, implementing a key verification protocol with a display device includes: receiving a first challenge value in the sensor system; hashing the first challenge value in the sensor system to generate a first hash value using a hashing algorithm and an authentication key; sending the first hash value and a second challenge value to the display device to the display device to verify whether the sensor system possesses an authentication key; hashing the second challenge value in the sensor system to generate a third hash value using a hashing algorithm and an authentication key; receiving a fourth hash value in the sensor system from the display device; verifying whether the third and fourth hash values ​​are identical in the sensor system; and determining that the display device possesses an authentication key when verifying that the third and fourth hash values ​​are identical, and that the display device is trusted by the user of the sensor system.

[0029] In the above method, implementing a key verification protocol with a display device includes: calculating an obfuscated key by hashing an authentication key and a random number; calculating a third hash value by hashing the obfuscated key; calculating a fourth hash value by hashing the third hash value; receiving a second hash value from the display device; verifying whether the second and fourth hash values ​​are identical; determining that the display device possesses the authentication key when verifying that the second and fourth hash values ​​are identical, and thus determining that the display device is trusted by the user of the sensor system; and transmitting a third hash value to the display device and verifying whether the sensor system is trusted by the user by verifying whether the first and third hash values ​​are identical based on the authentication key and a random number.

[0030] In the above method, implementing the display device and key verification protocol involves: calculating an obfuscated key by hashing the authentication key and a random number; calculating a third hash value by hashing the obfuscated key; calculating a fourth hash value by hashing the third hash value; receiving a second hash value and a signed second hash value from the display device; verifying whether the second hash value and the fourth hash value are identical; and determining that the display device is trusted by the user of the sensor system based on the determination that the display device possesses the authentication key when verifying that the second hash value and the fourth hash value are identical. The method includes verifying the integrity of the display device by: decrypting a signed second hash value using the display device's public key; determining that the display device possesses the display device's private key based on the determination that the decrypted signed second hash value and the second hash value are identical; transmitting a third hash value and a signed third hash value to the display device to the display device; verifying whether the sensor system is trusted by the user based on the verification of whether the first hash value and the third hash value based on the authentication key and random numbers are identical; and verifying the integrity of the sensor system based on the signed third hash value.

[0031] Certain embodiments of the present disclosure provide a method for secure wireless communication between a sensor system for measuring blood glucose levels and a display device, the method comprising: in the sensor system, calculating a sensor system identifier based on information associated with the sensor system; the method further comprising transmitting the sensor system identifier to the display device to identify whether the sensor system is associated with a user of the display device; the method further comprising in the sensor system, implementing a mutual authentication protocol with the display device to verify whether the display device is trusted by the diabetes trust management system and the user of the sensor system; the method further comprises in the sensor system, determining, based on the actions taken, that the display device is trusted by the diabetes trust management system and the user of the sensor system; the method further comprises transmitting analytic data to the display device over a secure connection, the secure connection being protected using an encryption key.

[0032] In the above method, implementing a mutual authentication protocol with the display device includes implementing the Password Authentication Key Exchange (PAKE) algorithm with the display device using a shared key. Implementing the PAKE algorithm further includes, in the sensor system, sending a signed certificate token of the sensor system to the display device so that the display device can verify whether the sensor system is trusted by the diabetes management system, and in the sensor system, receiving the signed certificate token of the display device to verify whether the display device is trusted by the diabetes management system. In the above method, determining that the display device is trusted by the diabetes trust management system and the user of the sensor system is based on the successful implementation of the PAKE algorithm.

[0033] Certain embodiments of this disclosure provide a method for secure wireless communication between a sensor system for measuring blood glucose levels and a display device, the method comprising: in the sensor system, implementing a user-centric mutual authentication protocol with the display device to verify whether the display device is trusted by the user of the sensor system. Implementing the user-centric mutual authentication protocol comprises implementing a password-authenticated key exchange (PAKE) algorithm with the display device using a shared key, and implementing the PAKE algorithm comprises deriving an authentication key. After determining that the display device is trusted by the user of the sensor system, the method further comprises: in the sensor system, implementing a device-centric mutual authentication protocol with the display device to verify whether the display device is trusted by a diabetes trust management system. Implementing includes receiving one or more certificates from the display device to verify whether the display device is trusted by the diabetes trust management system, the one or more certificates of the display device comprising a certificate token of the display device. Implementing further includes verifying one or more certificates of the display device, and verifying includes authenticating the certificate token of the display device. Implementing further includes transmitting one or more certificates of the sensor system to the display device for verification of one or more certificates of the sensor system by the display device. The implementation further includes, in the sensor system, determining, based on the implementation, that the display device is trusted by the diabetes trust management system. The method further includes, after the implementation of the device-centric mutual authentication protocol is successful, transmitting the analyte data to the display device in the sensor system.

[0034] The above method further includes, before implementing the device-centric mutual authentication protocol, the sensor system implementing a key verification protocol with the display device to verify whether the display device also possesses an authentication key, the implementation of the key verification protocol with the display device including, in the sensor system, receiving a first challenge value; in the sensor system, hashing the first challenge value to generate a first hash value using a hashing algorithm and an authentication key; sending the first hash value and a second challenge value to the display device to the display device to verify whether the sensor system possesses an authentication key; in the sensor system, hashing the second challenge value to generate a third hash value using a hashing algorithm and an authentication key; in the sensor system, receiving a fourth hash value from the display device; in the sensor system, verifying whether the third and fourth hash values ​​are identical; and in determining that the display device possesses an authentication key when verifying that the third and fourth hash values ​​are identical, the sensor system determining that the display device is trusted by the user of the sensor system.

[0035] In the above method, one or more certificates of the display device include issuer certificate tokens of the issuer of the certificate token of the display device, and verifying one or more certificates of the display device includes authenticating the issuer certificate tokens. The above method further includes sending first challenge data to the display device, receiving a signed version of the first challenge data including a digital signature generated by the display device using a private key associated with the display device, and decrypting the digital signature by verifying the authenticity of the digital signature using a public key associated with the display device. In the above method, sending analyte data to the display device includes encrypting the analyte data with an authentication key or a portion of an authentication key.

[0036] In the above method, the sensor system receives encrypted communications with an authentication key from the second display device without engaging with a second display device and a user-centric authentication protocol, and the second display device is configured with an authentication key by the display device. In the above method, transmitting analyte data to the display device includes generating a first MAC using the analyte data, a first message authentication code (MAC) algorithm, and the authentication key or a portion of the authentication key, and transmitting the analyte data having the first MAC to the display device. The display device receives the analyte data and the first MAC, generates a second MAC using the analyte data and the authentication key or a portion of the authentication key, and verifies the authenticity and integrity of the analyte data by determining that the first MAC and the second MAC are the same.

[0037] In the above method, the implementation of the user-centric mutual authentication protocol is initiated only after the sensor system has received multiple tactile taps. In the above method, the implementation of the user-centric mutual authentication protocol is initiated only if at least one of the sensor system or the display device is in the designated location. The above method further includes hashing a first SIN of the sensor system using a serial identification number (SIN) hashing algorithm and transmitting the hash of the first SIN to the display device. The display device hashs a second SIN obtained by the display device through scanning a Quick Response (QR) code (registered trademark, hereafter the same) on the sensor system using a SIN hashing algorithm, compares the hash of the first SIN received from the sensor system with the hash of the second SIN generated by hashing the second SIN obtained by the display device through scanning a QR code (registered trademark, hereafter the same), and verifies the identification of the sensor system when it determines that the hashes of the first SIN and the hashes of the second SIN are the same. [Brief explanation of the drawing]

[0038] [Figure 1A] This specification illustrates exemplary diabetes management systems according to several embodiments disclosed herein. [Figure 1B] The exemplary diabetes management system shown in Figure 1A is illustrated in more detail by some embodiments disclosed herein. [Figure 2A] This is a sequence diagram illustrating exemplary operations performed by a diabetes trust management system and a display device according to some embodiments disclosed herein. [Figure 2B] This is a sequence diagram illustrating exemplary operations performed by a diabetes trust management system and a display device according to some embodiments disclosed herein. [Figure 3]This is a sequence diagram illustrating exemplary secure diabetes device identification protocols according to some embodiments disclosed herein. [Figure 4A] This is a sequence diagram illustrating exemplary device-centric mutual authentication protocols (synonymously referred to as "device-centric authentication protocols") according to some embodiments disclosed herein. [Figure 4B] An exemplary chain of authorizations associated with an analyte sensor system ("SS") according to some embodiments disclosed herein. [Figure 4C] This is a sequence diagram illustrating an exemplary device-centric mutual authentication protocol according to some embodiments disclosed herein. [Figure 4D] This is a sequence diagram illustrating an exemplary device-centric mutual authentication protocol according to some embodiments disclosed herein. [Figure 5] This is a sequence diagram illustrating exemplary user-centered mutual authentication protocols (synonymously referred to as "user-centered authentication protocols") according to some embodiments disclosed herein. [Figure 6A] This is a sequence diagram illustrating an exemplary key verification protocol according to some embodiments disclosed herein. [Figure 6B] This is a sequence diagram illustrating an exemplary key verification protocol according to some embodiments disclosed herein. [Figure 6C] This is a sequence diagram illustrating an exemplary key verification protocol according to some embodiments disclosed herein. [Figure 7] This is a sequence diagram showing a display device and SS engaged in pairing and bonding according to some embodiments disclosed herein. [Figure 8] This is a sequence diagram showing that the display device and SS periodically reconnect according to some embodiments disclosed herein. [Figure 9]This is a sequence diagram illustrating, according to some embodiments disclosed herein, that a display device (configured to scan a QR code) and an SS engage in a user-centric mutual authentication protocol and a subsequent device-centric protocol. [Figure 10] This is a sequence diagram showing that a display device and SS (not configured to scan QR codes) engage in a user-centric mutual authentication protocol and a subsequent device-centric authentication protocol, according to some embodiments disclosed herein. [Figure 11] This specification discloses several embodiments of display devices and SSs, and / or other entities, that engage in device-centric mutual authentication protocols. [Figure 12] This is a sequence diagram showing a display device and SS using an authentication key (K-auth) for data encryption and / or data authenticity / integrity verification, according to some embodiments disclosed herein. [Modes for carrying out the invention]

[0039] The specific embodiments described herein relate to several different security protocols used by display devices, sensor systems, medical devices (e.g., medical delivery devices), and / or server systems to establish secure wireless connections and thereby mitigate the security, integrity, privacy, and / or availability issues associated with wireless communication in diabetes management systems. While the specific embodiments described herein relate to diabetes management, glucose sensor systems, and the transmission of glucose measurements between devices, it should be noted that the protocols and techniques described herein are equally applicable to any type of health management system, including any type of analyte sensor (e.g., lactate sensors, ketone sensors, etc.).

[0040] Figure 1A illustrates a disease management system 100 ("System 100"), such as a diabetes management system, which may be used in connection with embodiments of the present disclosure that involve collecting, monitoring, and / or providing information regarding the values ​​of analytes present in a user's body, such as the user's blood glucose level. System 100 shows an embodiment of an analyte sensor system 8 (hereinafter, "SS8") that can be communicatively coupled to display devices 110, 120, 130, and 140, and / or a server system 134.

[0041] In some embodiments, SS8 is provided for measuring analytes in a host or user. Outline and as an example, SS8 may be implemented as an encapsulated microcontroller that performs sensor measurements, generates analyte data (e.g., by calculating values ​​of continuous glucose monitoring data), and engages in wireless communication (e.g., via Bluetooth and / or other radio protocols) to send such data to remote devices such as display devices 110, 120, 130, 140, and / or server system 134. Paragraphs

[0137] to

[0140] of U.S. Patent Application No. 2019 / 0336053 and Figures 3A, 3B, and 4 further describe on-skin sensor assemblies that may be used in conjunction with SS8 in certain embodiments. Paragraphs

[0137] to

[0140] of U.S. Patent Application No. 2019 / 0336053 and Figures 3A, 3B, and 4 are incorporated herein by reference.

[0042] In certain embodiments, SS8 includes an analyte sensor electronic module 12 and an analyte sensor 10 associated with the analyte sensor electronic module 12. In certain embodiments, the analyte sensor electronic module 12 includes electronic circuitry associated with measuring and processing analyte sensor data or information, including algorithms associated with processing and / or calibration of analyte sensor data / information. The analyte sensor electronic module 12 is physically / mechanically connected to the analyte sensor 10 and integrated with the analyte sensor 10 (i.e., permanently mounted) or can be permanently mounted.

[0043] Furthermore, the analyte sensor electronic module 12 may be electrically coupled to the analyte sensor 10 so that its components can be electromechanically coupled to one another (for example, (a) before insertion into the patient's body, or (b) while insertion into the patient's body). The analyte sensor electronic module 12 may include hardware, firmware, and / or software that enables measurement and / or estimation of analyte levels in the host / user via the analyte sensor 10 (which may / may include, for example, a glucose sensor). For example, the analyte sensor electronic module 12 may include one or more potentiostats, a power supply for providing power to the analyte sensor 10, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronic module to one or more display devices. The electronic equipment can be fixed to a printed circuit board (PCB) or platform within the SS8 and can take various forms. For example, the electronic equipment circuit may take the form of an integrated circuit (IC), such as an application-specific integrated circuit (ASIC), microcontroller, processor, and / or state machine.

[0044] The analyte sensor electronic module 12 may include sensor electronic circuitry configured to process sensor information, such as sensor data, and generate converted sensor data and displayable sensor information. Examples of systems and methods for processing sensor analyte data are described in this specification and in U.S. Patents Nos. 7,310,544 and 6,931,327, and U.S. Patent Publications 2005 / 0043598, 2007 / 0032706, 2007 / 0016381, 2008 / 0033254, 2005 / 0203360, 2005 / 0154271, 2005 / 0192557, 2006 / 0222566, 2007 / 0203966 and 2007 / 0208245, all of which are incorporated herein by reference in their entirety.

[0045] The analyte sensor 10 is configured to measure the concentration or level of an analyte within a host. The term analyte is further defined in paragraph

[0117] of U.S. Patent Application No. 2019 / 0336053, which is incorporated herein by reference. In some embodiments, the analyte sensor 10 includes a continuous glucose sensor, such as a subcutaneous, transdermal (e.g., transcutaneous), or intravascular device. In some embodiments, the analyte sensor 10 can analyze multiple intermittent blood samples. The analyte sensor 10 can use any glucose measurement method, including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, ionophoretic, radiometric, immunochemical, and the like. Further details regarding continuous glucose sensors are provided in paragraphs

[0072] -

[0076] of U.S. Patent Application No. 13 / 827,577. Paragraphs

[0072] to

[0076] of U.S. Patent Application No. 13 / 827,577 are incorporated herein by reference.

[0046] Referring further to Figure 1A, the display devices 110, 120, 130, and / or 140 are configured to display (and / or warn) displayable sensor information that can be transmitted by the sensor electronic module 12 (for example, in customized data packages transmitted to the display devices based on their respective basic settings). Each of the display devices 110, 120, 130, or 140 may include a display such as a touchscreen display 112, 122, 132, and / or 142 for displaying sensor information and / or analyte data to the user and / or receiving input from the user. For example, a graphical user interface (GUI) may be presented to the user for such purposes. In certain embodiments, the display devices may include, instead of or in addition to, a touchscreen display, other types of user interfaces, such as a voice user interface, for communicating sensor information to the user of the display device and / or receiving user input. In certain embodiments, one, some, or all of the display devices 110, 120, 130, 140 may be configured to display, or otherwise communicate, sensor information when it is communicated from the sensor electronic module 12 (for example, in data packages sent to each display device) without any additional processing that is necessary for the calibration and / or real-time display of sensor data.

[0047] The plurality of display devices 110, 120, 130, 140 illustrated in Figure 1A may include, for example, a custom or proprietary display device, e.g., an analyte display device 110, specifically designed to display certain types of displayable sensor information (e.g., numerical values ​​and / or arrows in a particular embodiment) associated with analyte data received from the sensor electronic module 12. In a particular embodiment, one of the plurality of display devices 110, 120, 130, 140 includes a smartphone, such as a mobile phone 120, based on Android®, iOS, or another operating system, configured to provide a graphical display of sequential sensor data (e.g., including current and / or historical data). In a particular embodiment, the disease management system 100 further includes a medical delivery device (e.g., an insulin pump or pen). The sensor electronic module 12 may be configured to transmit sensor information and / or analyte data to the medical delivery device. The medical delivery device (not shown) may be configured to administer a specific dose of insulin or another drug to the user based on sensor information and / or analyte data (e.g., which may include a recommended insulin dosage) received from the sensor electronic module 12.

[0048] The server system 134 may be used, for example, to directly or indirectly collect analyte data from SS8 and / or multiple display devices, perform analysis thereof, generate universal or individual models for glucose levels and profiles, provide services or feedback including those from individuals or systems remotely monitoring analyte data, and perform or assist in performing identification, authentication, etc. of SS8 and display device 150 in accordance with the embodiments described herein. Note that in certain embodiments, the server system 134 may represent multiple systems or computing devices performing the functions of the server system 134 (e.g., in a distributed manner).

[0049] Figure 1B shows a more detailed diagram of system 100, including a display device 150 communicatively coupled to SS8. In certain embodiments, the display device 150 may be one of the display devices 110, 120, 130, and 140 in Figure 1A. The communication path between SS8 and the display device 150 is shown as communication path 180. In certain embodiments, SS8 and the display device 150 are configured to communicate wirelessly over communication path 180 using a narrow-range and / or short-range wireless communication protocol. Examples of narrow-range and / or short-range wireless communication protocols include Bluetooth and Bluetooth Low Energy (BLE) protocols. In certain embodiments, other narrow-range wireless communication may include near-field communication (NFC), radio frequency identification (RFID) communication, infrared (IR) communication, and optical communication. In certain embodiments, wireless communication protocols other than narrow-range and / or short-range wireless communication protocols, such as WiFi Direct, may be used on communication path 180. The display device 150 may be configured to connect to a network 190 (e.g., a local area network (LAN), a wide area network (WAN), or the internet). For example, the display device 150 may connect to the network 190 via a wired (e.g., Ethernet) or wireless (e.g., a WLAN, wireless WAN, cellular, mesh network, or personal area network (PAN)) interface. The display device 150 can communicate with the server system 134 through the network 190. The communication path between the display device 150 and the server system 134 is shown as a communication path 181 through the network 190.

[0050] It should be noted that in certain embodiments, SS8 may be able to communicate independently (e.g., wirelessly) with the server system 134 via the network 190. An independent communication path between SS8 and the server system 134 is shown as communication path 182. However, in other specific embodiments, SS8 may not be configured with the hardware / software necessary to establish an independent wireless communication path with the server system 134 via the network 190, for example. In such embodiments, SS8 may communicate with the server system 134 via the display device 150. An indirect or pass-through communication path between SS8 and the server system 134 is shown as communication path 183.

[0051] In embodiments where the display device 150 is a proprietary display device, such as display device 110, specifically designed for communication of analyte data, the display device 150 does not need to be configured with the hardware / software necessary to connect independently to the network 190. Instead, in certain such embodiments, the display device 150 is configured to establish a wired or wireless communication path 184 (e.g., via a Universal System Bus (USB) connection) with a computer device 103 configured to communicate with a server system 134 over the network 190. For example, the computer device 103 may connect to the network 190 via a wired (e.g., Ethernet) or wireless (e.g., WLAN, wireless WAN, cellular, etc.) interface. Note that in embodiments described in relation to Figures 2A-8, unless otherwise specified, it is assumed that the display device 150 can communicate independently of the computer device 103 and independently of the server system 134 over the network 190.

[0052] System 100 further includes a server system 134, which includes a server 135 coupled to storage 136 (e.g., one or more computer storage systems, cloud-based storage systems and / or services). In certain embodiments, the server system 134 may be located or implemented in a public or private cloud. In certain embodiments, the server system 134 may be located or implemented on-premises ("on-prem"). As considered, the server system 134 is configured to receive, collect, and / or monitor information including analytic data and related information, as well as encrypted / authenticated information from SS8 and / or display device 150. Such information may include inputs in response to analytic data or inputs (e.g., user glucose measurements and other physiological / behavioral information) received in connection with an analytic monitoring or sensor application operating on SS8 or display device 150. This information may be stored in storage 136 and processed by an analysis engine, etc., which can perform analysis on the information. An example of an analyte sensor application that may be run on display device 150 is analyte sensor application 121, as further described below.

[0053] In certain embodiments, the server system 134 at least partially guides communication between the SS8 and the display device 150 to facilitate, for example, authentication between them. Such communication includes messaging (e.g., advertisements, commands, or other messaging), message delivery, and analytic data. In certain embodiments, for example, the server system 134 may process messages related to frequency band, transmission timing, security, alarms, and other matters between the SS8 and the display device 150 and exchange these messages between them. In certain embodiments, the server system 134 may update information stored in the SS8 and / or the display device 150. In certain embodiments, the server system 134 may send and receive information to and from the SS8 and / or the display device 150 in real time or sporadically. Furthermore, in certain embodiments, the server system 134 may implement cloud computing capabilities for the SS8 and / or the display device 150.

[0054] Figure 1B also shows the components of the SS8 in more detail. As shown, in certain embodiments, the SS8 includes an analyte sensor 10 coupled to a sensor electronic module 12. The sensor electronic module 12 includes a sensor measurement circuit 13 coupled to the analyte sensor 10 for processing and managing sensor data. The sensor measurement circuit 13 may also be coupled to a processor 11. In some embodiments, the processor 11 may perform some or all of the functions of the sensor measurement circuit 13 for acquiring sensor measurements from the sensor 10 and processing them. The processor 11 may also be coupled to storage 14 and a real-time clock (RTC) 17 for storing and tracking sensor data. Furthermore, the processor 11 may be further coupled to a connectivity interface 15 including a radio unit or transceiver (TRX) 16 for transmitting sensor data and receiving requests and commands from external devices such as a display device 150. As used herein, the term transceiver generally refers to a device or set of devices that enables the SS8 to send and receive data (e.g., wirelessly). SS8 may further include storage 14 for storing and tracking sensor data and a real-time clock (RTC) 17. In some embodiments, it is assumed that SMC 13 can perform all the functions of processor 11, and vice versa.

[0055] The transceiver 16 may consist of the hardware and radio communication protocols necessary to enable radio communication between the SS8 and other devices such as the display device 150 and / or the server system 134. For example, as described above, the transceiver 16 may consist of the hardware and communication protocols necessary to establish a Bluetooth or BLE connection with the display device 150. As those skilled in the art will understand, in such examples, the necessary hardware may include a Bluetooth or BLE security manager and / or other Bluetooth or BLE-related hardware / software modules configured for the Bluetooth or BLE communication standard. In some embodiments where the SS8 is configured to establish an independent communication path with the server system 134, the transceiver 16 may consist of the hardware and communication protocols necessary to establish a radio connection to the network 190 for connecting with the server system 134 (e.g., wide-range radio cellular communication protocols such as GSM, CDMA, LTE, VoLTE, 3G, 4G, and 5G communication protocols). As considered elsewhere, other short-range protocols may also be used for communication between the display device 150 and the SS8, such as NFC, RFID, etc.

[0056] Figure 1B similarly shows the components of the display device 150 in more detail. As shown, the display device 150 includes a connectivity interface 128, a processor 126, memory 127, a real-time clock 163, a display 125 for presenting a graphical user interface (GUI), and storage 123. Various elements of the display device 150 can be interconnected using a bus (not shown) and data can be transferred between these elements. The connectivity interface 128 includes a transceiver (TRX) 129 used to receive sensor data from SS8 and to send requests, commands, and / or data to SS8 and the server system 134. The transceiver 129 is coupled to other elements of the display device 150 via the connectivity interface 128 and / or the bus. The transceiver 129 may include multiple transceiver modules capable of operating on different radio standards. For example, the transceiver 129 may consist of one or more communication protocols, such as a wireless communication protocol for establishing a wireless communication path with the network 190 and / or a narrow-range wireless communication protocol (e.g., Bluetooth or BLE) for establishing a wireless communication path 180 with SS8. In addition, the connectivity interface 128 may, in some cases, include additional components for controlling wireless and / or wired connections, such as baseband and / or Ethernet modems and audio / video codecs.

[0057] In some embodiments, when a standardized communication protocol is used between the display device 150 and the SS8, commercially available transceiver circuits can be utilized, which incorporate processing circuits to handle low-level data communication functions such as data encoding, transmission frequency, handshake protocol, and similar. In such embodiments, the processor 126 of the display device 150 and / or the processor 11 of the SS8 do not need to manage these functions, but rather provide the desired data values ​​for transmission and manage high-level functions such as increasing or decreasing power, setting the rate at which messages are transmitted, and similar. Instructions and data values ​​for performing these high-level functions may be provided to the transceiver circuits via data bus and transfer protocols established by the manufacturers of the transceivers 129 and 16. However, in embodiments where a standardized communication protocol is not used between the transceivers 129 and 16 (e.g., when a non-standardized or modified protocol is used), the processors 126 and 11 may be configured to implement instructions associated with their own communication protocol (e.g., one or more of the communication protocols described herein) and to control and manage their respective transceivers. Furthermore, if non-standardized or modified protocols are used, customized circuits may be used to present such protocols.

[0058] The processor 126 may include, for example, a processor submodule that includes an application processor that interfaces with other elements of the display device 150 (e.g., connectivity interface 128, analyte sensor application 121 (hereinafter "sensor application 121"), display 125, RTC 163, memory 127, storage 123, etc.). In certain embodiments, the processor 126 is configured to perform device management-related functions, such as managing information related to a list of available or previously paired devices, network conditions (e.g., link quality), and the timing, type, and / or structure of messaging exchanged between the SS8 and the display device 150. The processor 126 may be further configured to receive and process user input, such as user biometric information, such as a user's fingerprint, and analyte data, (for example, to authorize user access to data or to use for authorization / encryption of data including analyte data).

[0059] The processor 126 may include and / or be coupled with logic circuits for peripheral and audio components, memory, battery and power circuits, and other circuit drivers. The processor 126 and any subprocessors may include logic circuits for receiving, processing, and / or storing data received and / or input to the display device 150, and data transmitted or delivered by the display device 150. As described above, the processor 126 may be coupled by bus to the display 125, connectivity interface 128, storage 123, etc. Therefore, the processor 126 may receive and process electrical signals generated by each of these elements and thus perform a variety of functions. As an example, the processor 126 may, at the direction of a sensor application 121, access stored content from storage 123 and memory 127 and process the stored content to be displayed by the display 125. Furthermore, the processor 126 may process stored content for transmission via the connectivity interface 128 to the SS8 and / or server system 134. The display device 150 may include other peripheral components not shown in detail in Figure 1B.

[0060] In certain embodiments, memory 127 may include volatile memory, such as random access memory (RAM), for storing data and / or instructions for software programs and applications, such as the analyte sensor application 121. Display 125 presents a GUI associated with the operating system 162 and / or the analyte sensor application 121. In various embodiments, a user may interact with the analyte sensor application 121 via the corresponding GUI presented on display 125. As an example, display 125 may be a touchscreen display that accepts touch input. The analyte sensor application 121 may process and / or present analyte-related data received by the display device 150 and present such data via display 125. Furthermore, as described in more detail herein, the analyte sensor application 121 may be used to acquire, access, display, control, and / or interface with analyte data, as well as related messaging and processing associated with SS8 (and / or any other medical device, e.g., an insulin pump or pen, that is communicably coupled to, for example, the display device 150).

[0061] Storage 123 may be non-volatile storage for storing software programs, instructions, data, etc. For example, if Storage 123 is implemented using, for example, a processor 126, it may store an analyte sensor application 121 that receives input (e.g., by conventional hard / soft keys or touchscreen, voice detection, or other input mechanisms) and allows the user to interact with analyte data and related content via the display 125. In various embodiments, Storage 123 may store user input data collected by the display device 150 and / or other data (e.g., input from other users collected via the analyte sensor application 121). Storage 123 may be further used to store large amounts of analyte data received from SS8 (or any other medical data received from other medical devices (e.g., insulin pumps, pens, etc.)) for later retrieval and use, for example, for trend determination and triggering warnings.

[0062] As described above, in certain embodiments, the SS8 collects analyte data from the analyte sensor 10 and transmits the same or modified version of the collected data to the display device 150. Data points relating to analyte values ​​may be collected and transmitted over the lifetime of the sensor 10 (e.g., in the range of 1 to 30 days or more). New measurements may be transmitted at a frequency sufficient to adequately monitor glucose levels. In certain embodiments, rather than the respective transmit and receive circuits of the SS8 and the display device 150 communicating continuously, the SS8 and the display device 150 may establish a periodic and / or cyclical communication channel with each other. Thus, in such embodiments, the SS8 may communicate with the display device 150, for example, at predetermined time intervals. The duration of the predetermined time interval may be long enough so that the SS8 does not consume excessive power by transmitting data more frequently than necessary, and may be selected to be frequent enough to provide the display device 150 with substantially real-time sensor information (e.g., measured glucose values ​​or analyte data) to the user (e.g., via the display 125). In some embodiments, the predetermined time interval is every 5 minutes, but it is understood that this time interval can be changed to any desired time. In other embodiments, transceivers 129 and 16 can communicate continuously. For example, in certain embodiments, transceivers 129 and 16 can establish a session or connection between them and continue to communicate together until the connection is lost.

[0063] The analyte sensor application 121 can be downloaded, installed, and initially configured / set up on the display device 150. For example, the display device 150 may obtain the analyte sensor application 121 from the server system 134 via a network, e.g., network 190, or from another source such as an application store. Following installation and setup, the analyte sensor application 121 can be configured to access, process, and / or interface with analyte data (e.g., stored on the server system 134, stored locally from storage 123, from SS8, or from any other medical device). As an example, the analyte sensor application 121 may present a menu containing various controls or commands that may be performed in relation to the operation of SS8, the display device 150, one or more other display devices (e.g., display devices 110, 130, 140, etc.), and / or one or more other partner devices such as an insulin pump. For example, the analyte sensor application 121 may be used to interface with or control other displays and / or partner devices in order to distribute or make available analyte data, for example, by directly receiving / transmitting analyte data to other displays and / or partner devices, and / or by sending commands to connect SS8 with other displays and / or partner devices.

[0064] In certain embodiments, as one of the initial steps, after the user downloads the sensor application 121, the sensor application 121 may instruct the display device 150 to wirelessly connect to the user's SS8, which the user may already be wearing. A wireless communication path 180 between the display device 150 and the SS8 allows the SS8 to transmit analyte measurements to the display device 150, enabling the two devices to engage in any of the other interactions described above. However, as considered, using a wireless communication path between the display device 150 and the SS8 based on a specific existing wireless communication protocol could expose the display device 150, the SS8, and / or the server system 134 to security, integrity, privacy, and availability issues. Similarly, establishing other communication paths within the system 100 using a specific existing communication protocol (e.g., a communication path 181 between the display device 150 and the server system 134, and a communication path 183 between the SS8 and the server system 134) could also expose the display device 150, the SS8, and / or the server system 134 to security, integrity, privacy, and availability issues.

[0065] Accordingly, certain embodiments described herein relate to multiple different protocols, and by using them, the display device 150, SS8, and server system 134 can establish secure communication, thereby mitigating security, integrity, privacy, and availability issues related to communication in system 100. Figures 2A-4A and 4C-8 are sequence diagrams showing communication and data exchange between server system 134, display device 150, and / or SS8. More specifically, Figures 2A-2B show how the display device 150 obtains authentication data (e.g., authorization) from server system 134. Figure 3 shows an exemplary implementation of a secure diabetes device identification protocol. Figures 4A-4D relate to an exemplary implementation of a device-centric mutual authentication protocol. Figure 5 shows an exemplary implementation of a user-centric mutual authentication protocol. Figures 6A-6C relate to an exemplary implementation of a key verification protocol. Figure 7 shows an implementation of pairing and bonding between SS8 and display device 150. Figure 8 shows an exemplary data exchange between SS8 and display device during periodic reconnection.

[0066] Secure data exchange between display devices and server systems Figures 2A and 2B are sequence diagrams showing how the display device 150 obtains authentication data from the server system 134 during the setup process of the sensor application 121 performed by the display device 150. As described in relation to Figures 4A-4D, the sensor application 121 is composed of authentication data through a secure exchange of data between the display device 150 and the server system 134 based on any embodiment of any of the methods described in relation to Figures 2A-2B. This authentication data enables the display device 150 to sequentially authenticate and establish a secure connection with SS8. In a particular embodiment, the authentication data obtained by the sensor application 121 from the server system 134 includes a set of digital authentication authorizations, also referred to as public key authorizations (hereinafter referred to as "authorizations"), for use by the display device 150 to authenticate SS8 using what is referred to herein as a device-centric mutual authentication protocol (described in relation to Figures 4A-4D). As further described below, SS8 is similarly composed of a set of authorizations, thereby enabling SS8 to authenticate the display device 150 using the same device-centric mutual authentication protocol. In certain embodiments, the SS8 is comprised of these authorizations during the manufacturing process. In some examples, it is intended that authorizations, tokens, and / or encryption keys may be used to authenticate partner devices (e.g., medical delivery devices such as insulin pumps and / or pens). Furthermore, it is intended that authorizations, tokens, and / or encryption keys may also be obtained from the partner device to authenticate the SS8 and / or display devices or other partner devices.

[0067] In certain embodiments, a license is an electronic document generated for the authentication of a device compliant with a public key infrastructure (PKI) scheme. Here, licenses may be referred to as certificate tokens. PKI refers to a set of roles, policies, hardware, software, and procedures for creating the management, distribution, use, storage, revocation, and public key cryptography of licenses. In a typical PKI scheme, each device may generate or consist of a key pair containing a public key and a private key. If information is encrypted using the private key, that information can only be decrypted using the corresponding public key, and vice versa. A device's public key may be widely distributed, but a device's private key is usually made public only to that device and not shared with other devices. For example, in certain embodiments, each of the display device 150, SS8, and server system 134 may generate or consist of separate key pairs.

[0068] One of its roles is to bind public keys to the respective device identities. This binding is established through the process of registering and issuing authorizations at a Certificate Authority (CA). The CA's primary role is to digitally sign and publish the public keys bound to specific devices. Since this is done using the CA's own private key, trust in the user key depends on trust in the validity of the CA's key. In certain embodiments, server system 134 performs the function of a root CA (RCA) by issuing and directly or indirectly signing authorizations for display devices 150 and SS8. The RCA is the entity that verifies all other entities in the system. Thus, server system 134 may be referred to as a diabetes trust management system, and by issuing and signing authorizations for display devices 150 and SS8 or any other partner devices, they become capable of engaging in a device-centric trust management protocol and authenticating each other.

[0069] In certain embodiments, the server system 134, as an RCA, directly signs the device authorization (e.g., the authorization for display device 150 and / or SS8) using its private key. Alternatively, in some embodiments, indirect authorization signing may be used, thereby the server system 134 signing an intermediate certificate of a dependent certification authority ("SCA"), and then the SCA signing the device authorization using its private key. When the SCA is involved in signing the authorization, a chain of trust is created, as further shown and described in relation to Figure 4B. In certain embodiments, one SCA may be involved, while in other specific embodiments, multiple SCAs may be involved.

[0070] The sequence diagrams shown in Figures 2A and 2B illustrate communication between the display device 150 and the server system 134, resulting in the display device 150 securely obtaining one or more signed authorizations from the server system 134. Communication between the display device 150 and the server system 134 can be triggered by a user downloading the sensor application 121 or any other application (not shown) related to the sensor application. Then, as part of the setup process, the sensor application 121 connects with the server system 134 to obtain any necessary information that can later be used for interaction between the display device 150 and SS8.

[0071] In step 202, the user downloads the sensor application 121. For example, the user downloads the sensor application 121 from an application store (e.g., the App Store) and starts the setup process.

[0072] In step 204, the display device 150 and the server system 134 engage in cryptographic key exchange. In certain embodiments, during the setup process, the display device 150 engages in or initiates a cryptographic key exchange (e.g., a key agreement protocol such as the Diffie-Hellman (DH) key exchange algorithm) with the server system 134 to generate an encryption key to be used to encrypt any further communication between the display device 150 and the server system 134, based on instructions provided by the analyte sensor application 121. In certain embodiments, engaging in a cryptographic key exchange may involve the display device 150 proving to the server system 134 that it possesses a shared secret (e.g., a cryptographic key exchange algorithm, a key, etc.), and vice versa. Possessing a shared secret is evidence that the display device 150 can be trusted by the server system 134, and vice versa. After the display device 150 and the server system 134 have completed the implementation of the cryptographic key exchange algorithm, each of the display device 150 and the server system 134 possesses the encryption key used to encrypt subsequent data transmitted between them (e.g., steps 206-212).

[0073] In certain embodiments, a cryptographic key exchange algorithm includes a key-sharing protocol. A key-sharing protocol is a protocol that enables two or more parties to agree on a key in a manner that affects the outcome for both parties. An example of a key-sharing protocol may be an exponential key exchange algorithm such as the Diffie-Hellman (DH) key exchange algorithm. DH key exchange is a method for securely exchanging cryptographic keys over an insecure channel. Various versions of DH key exchange are also within the scope of this disclosure. For example, in certain embodiments, a cryptographic key exchange algorithm may include elliptic curve DH (ECDH), which is a key agreement protocol that enables two parties, each possessing an elliptic curve public-private key pair, to establish an encryption key over an insecure channel.

[0074] In certain embodiments, during the setup process, the display device 150 engages in or initiates cryptographic key exchange based on instructions provided by the sensor application 121 to prove to the server system 134 that the display device 150 possesses a shared secret (e.g., a cryptographic key exchange algorithm). In other specific embodiments, the server system 134 and the display device 150 engage in cryptographic key exchange that does not generate an encryption key but simply functions to enable the server system 134 and the display device 150 to authenticate each other. In such embodiments, the sensor application 121 is already configured with a shared secret that may be a cryptographic key exchange algorithm. In other words, since the display device 150 can engage in a cryptographic key exchange algorithm, the server system 134 can conclude that the display device 150 is trustworthy. Otherwise, the display device 150 would not be configured with such a cryptographic key exchange algorithm and would not be able to engage in cryptographic key exchange using that algorithm.

[0075] If the server system 134 can determine that the display device 150 knows the shared secret, the server system 134 determines that the display device 150 is trustworthy. The reverse is also true. In other words, the display device 150 is authenticated by the server system 134. The reverse is also true. In certain embodiments, the shared secret is an encryption key that can also be used to encrypt subsequent data transmitted between the server system 134 and the display device 150 (for example, in steps 206-212).

[0076] In step 206, the display device 150 sends an encrypted authorization signature request to the server system 134. In certain embodiments, the display device 150 encrypts the authorization signature request using the encryption key of the display device 150 obtained in step 204 or already configured. In certain embodiments, the display device 150 is configured with a first authorization for use in authentication between the display device 150 and SS8, and a second authorization for use in authentication between the display device 150 and the server system 134. In certain embodiments, the display device 150 is similarly configured with a first key pair (i.e., a first public key and a first private key) for use in authentication between the display device 150 and SS8, and a second key pair (i.e., a second public key and a second private key) for use in authentication between the display device 150 and the server system 134.

[0077] In certain embodiments, the authorization signing request includes a first authorization and a second authorization. In certain embodiments, the first authorization includes a first public key, and the second authorization includes a second public key. The authorization signing request represents a request to sign the first and second authorizations to the server system 134 that performs the RCA function.

[0078] It should be noted that in certain embodiments, by engaging in the cryptographic key exchange in step 204, the display device 150 and the server system 134 have already authenticated each other before step 206. More specifically, each device may conclude that the other party is trustworthy if it determines that the other party is similarly configured with the same cryptographic key exchange algorithm, which may be a custom cryptographic key exchange algorithm. This is because if the other party's device is malicious, it is likely that it will not be configured with the same exact cryptographic key exchange algorithm, or at least a custom cryptographic key exchange algorithm.

[0079] However, in other specific embodiments, a second key pair and a second authorization may be used, or instead, for authentication in subsequent connections between the server system 134 and the display device 150. However, in other specific embodiments, additional authentication may not be performed between the display device 150 and the server system 134 (for example, to improve resource efficiency such as computing and storage efficiency). Thus, the display device 150 may consist of a second key pair and a second authorization. In such embodiments, the authorization signing request does not include a second certificate.

[0080] In step 208, the server system 134 transmits the signed license to the display device 150. As described above, in certain embodiments, the server system 134 directly signs the license, and in other specific embodiments, the server system 134 indirectly signs the license. In certain embodiments, signing the license involves encrypting the information contained in the license (or encrypting its hash), so that a digital signature is included in the license. An example of a signed license is shown in Figure 4B, which is described further below.

[0081] In certain embodiments, if the authorization signing request includes first and second authorizations, the server system 134 may sign the authorizations using the server system 134's private key. In such embodiments, the server system 134 may send the display device 150 an authorization signed by the server system 134 itself (i.e., signed with the server system 134's private key), as well as the first and second authorizations for the display device 150 signed by the server system 134. In other specific embodiments, the server system 134 may send the display device 150 an authorization signed by the server system 134 itself, as well as the first and second authorizations for the display device 150 signed by the SCA. In other words, in such embodiments, the first and second authorizations are not directly signed by the server system 134 (for example, to add an additional layer of security and reduce the risk of any information about the server system 134 or its keys / authorizations being exposed). In a particular embodiment, the transmission of one or more signed authorizations from the server system 134 to the display device 150 is encrypted using an encryption key that the server system 134 may obtain, generate, or configure in step 204.

[0082] In an optional step 210, the display device 150 sends a request to the server system 134 for an intermediate license and / or a license on the blacklist. For example, if in step 208 the server system 134 sends a license for the display device 150 that is not directly signed by the server system 134, the display device 150 may request any intermediate licenses associated with any SCA involved in step 210. Furthermore, the request from the display device 150 in step 210 may include a request for a license on the blacklist. A license on the blacklist refers to a license for an entity (e.g., a device, SCA, etc.) that should no longer be trusted by the display device 150. For example, a license on the blacklist may indicate an unauthorized partner device (e.g., a pump device) or any unauthorized and / or faulty transmitter.

[0083] In an optional step 212, the server system 134 sends to the display device 150 any intermediate certificate and / or blacklisted authorization that is requested by the display device 150 and is also available to the server system 134. In some embodiments, the server system is intended to be a partner device or partner server system with which the display device communicates for authentication. It is further intended that the partner device may communicate with the server system 134 for authentication.

[0084] Therefore, Figure 2A shows how the display device 150 sends a license signing request to the server system 134, which may contain a first and / or second license.

[0085] Figure 2B illustrates an alternative method by which the display device 150 obtains authentication data from the server system 134. Step 201 is similar to step 202 in Figure 2A. Once step 201 (or the user downloading the application) is performed, steps 203-209 are triggered. In the example in Figure 2B, the display device 150 does not consist of the first key pair, the second key pair, the first unsigned authorization, and / or the second unsigned authorization before engaging in step 203. This is also true in step 204 in Figure 2B. Thus, in such embodiments, in step 205, the server system 134 is configured to send the first and second signed authorizations, as well as the first and second key pairs, to the display device 150. Similar to Figure 2A, in Figure 2B, in certain embodiments, the first and / or second authorizations may be directly signed by the server system 134 as RCAs. In some such embodiments, in step 205, the server system 134 sends its own signed (i.e., signed with the server system 134's private key) authorization, as well as two signed authorizations for the display device 150, to the display device 150. In other specific embodiments, as described above, the first and / or second authorizations are indirectly signed by the server system 134, in which case the server system 134 may send its own signed authorization, as well as the first and second authorizations for the display device 150 signed by the SCA. Steps 207 and 209 are also similar to steps 210 and 212 in Figure 2A. In step 209, the server system 134 sends the SCA's signed intermediate authorization, as well as any other SCAs involved in the chain of trust.

[0086] It should be noted that steps 210 and 212 in Figure 2A, and steps 207 and 209 in Figure 2B, are optional. In certain embodiments, the display device 150 may be configured to obtain any intermediate and / or blacklisted authorizations from SS8. In some such embodiments, SS8 is configured with intermediate and / or blacklisted authorizations during the manufacturing process, and further configured to send a certificate to the display device 150 after all authentication has been performed between the two devices. In certain embodiments, SS8 may consist only of intermediate authorizations during the manufacturing process. Thus, in some such embodiments, the display device 150 may obtain intermediate authorizations from SS8, but may still request and obtain blacklisted authorizations from the server system 134. In certain embodiments where SS8 is not configured with any required intermediate and / or blacklisted authorizations, the display device 150 performs steps 210 and 212 in Figure 2A or steps 207 and 209 in Figure 2B, depending on which operations the display device 150 and the server system 134 are engaged in.

[0087] As described above, in certain embodiments, the display device 150 obtains a signed authorization and / or any private key from the server system 134 during the setup process of the sensor application 121, which the display device 150 has not yet configured. Once the display device 150 possesses this authentication data and the setup process is complete, the display device 150 may be ready to connect to the user's SS8. At this point, the user may place the SS8 on their body and confirm that the SS8 is also ready to connect to the display device 150. However, for the display device 150 and the SS8 to connect, the display device 150 would first need to identify the SS8 from among several different SSs potentially present in the vicinity. These several different SSs in the vicinity may include the SSs of other users nearby, such as when the user is in a clinic and there is a group of users nearby, all of whom have SSs. In such cases, it is crucial that the user's display device 150 does not inadvertently connect to another user's SS. Among the several different SSs in the vicinity, there may be further or alternatively malicious devices attempting to impersonate the user's SS8. For example, an attacker could use a malicious device to connect to the display device 150 and transmit inaccurate data (e.g., inaccurate blood glucose readings) to it, thereby harming the patient. Furthermore, as will be further described below, it is crucial that the display device 150 securely identifies the SS8 so that data exchanged between the two devices for identification purposes cannot be used by an attacker later in the authentication process.

[0088] Therefore, in certain embodiments, the display device 150 and the SS8 engage in one of a set of identification protocols or methods, thereby enabling the display device 150 to securely identify the correct SS8 to connect to. The set of identification protocols may also be referred to as a secure diabetes identification protocol.

[0089] identification In certain embodiments, the SS consists of a serial identification (ID) number (hereinafter referred to as "SIN" or token ID). In some cases, this SIN may be displayed (e.g., printed or placed) on the SS itself or its packaging. When a user obtains this SIN, they provide it as input to a sensor application performed on the display device during the setup process. Upon receiving this SIN, the display device initiates a search for an SS with the same SIN, based on the determination that the correct SS to connect must have the same SIN. Based on a specific identification protocol, the SS may be configured to advertise its SIN after the user has placed the SS on their body and activated the SS. Note that in some cases, the SIN may include modified or derived versions of the SIN. However, advertising the SIN in plain text could, in some cases, give an attacker (depending on the authentication protocol configured for the SS and display device) the opportunity to intercept the advertised SIN in transmission and, possibly later, use the same SIN to impersonate the SS and authenticate the display. Here, transmitting data in plain text means transmitting data in an unencrypted form.

[0090] Advertising only a portion of a SIN can cause problems, especially if the SIN has low entropy. Password entropy measures how unpredictable or identifiable a password is. Therefore, a low-entropy SIN is a highly identifiable SIN. For example, a low-entropy SIN may be 6 characters long. If an attacker can determine, for example, the first two characters of the SIN, and the SS advertises the last two characters in plaintext during the identification phase, then, given a certain existing authentication protocol, the attacker could potentially authenticate the display device simply by guessing the remaining two characters.

[0091] It should be noted that, in some cases, the first two characters of all SSs on the market may be identical, meaning an attacker could determine the first two characters. Furthermore, during certain authentication protocols that the SS and display device may later engage in, the hash of the SIN may be exchanged between the SS and the display device. In such a case, if an attacker has access to the hash algorithm used to hash the SIN, they could combine the six characters with a hash value equal to the SIN hash value obtained through eavesdropping during authentication between the SS and the display device with the other four characters to determine the remaining two characters.

[0092] Accordingly, the specific embodiments described herein relate to a set of identification protocols designed to enable the display device 150 to effectively identify SS8 and reduce or eliminate the possibility that an attacker could obtain any information during the identification process that could help them impersonate SS8 or the display device 150.

[0093] In certain embodiments, one of several proximity-based identification protocols may be used by SS8 and display device 150. A proximity-based identification protocol helps ensure that only two devices in close proximity to each other can communicate and complete the identification process. For example, in certain embodiments, a proximity-based identification protocol may include configuring devices (e.g., display device 150 and / or SS8) to communicate only with other devices that have a Received Signal Strength Indicator (RSSI) above a certain threshold (e.g., for the purposes of identification, authentication, bonding, and / or pairing), meaning that a device (e.g., display device 150) receives a signal from the other device (e.g., SS8) that has a signal strength measured by that device and satisfying the threshold (e.g., advertising a SIN). Utilizing RSSI in a proximity-based identification protocol helps, for example, during the identification phase, ensure that display device 150 can reliably identify SS8 only if SS8 has an RSSI higher than a minimum threshold. Thus, SSs with RSSIs below the threshold are not included in the search of display device 150. It should be noted that malicious devices attempting to impersonate SS8 are not very close to the user, or at least not as close to display device 150 as SS8. Therefore, malicious devices with an RSSI below the threshold are excluded from the search for display device 150.

[0094] In certain embodiments, RSSI may be used by proximity-based identification protocols to generate a signature usable for identification. For example, display device 150 may instruct the user to move SS8 closer to and further away from display device 150. This change in RSSI generates or communicates a unique signature already stored by display device 150. If the two signatures match, display device 150 can conclude that SS8 is a suitable SS to connect to.

[0095] In certain embodiments, proximity-based identification protocols may involve configuring display devices 150 and SS8 to reduce their transmit power (e.g., the signal transmit power of their antennas) during the identification stage. Using this approach helps display device 150 not identify SS8 unless they are relatively close to each other. In certain embodiments, proximity-based identification protocols may include the use of both RSSI and transmit power, for example, based on one or more of the approaches described above. Further details regarding protocols involving the use of RSSI are described in U.S. Patent Application No. 15 / 782702, which is incorporated herein by reference in whole for all purposes.

[0096] In certain embodiments, a visual identification protocol may be used for identification. For example, in certain embodiments, the display device 150 may be configured to scan or read identifiers associated with the SS8. For example, identifiers associated with the SS8 may include a SIN visibly inscribed on the SS8 or its packaging, or a SIN, QR code, and / or symbol placed or printed using (human-invisible) ink.

[0097] In certain embodiments, an auditory-based identification protocol may be used for identification. For example, SS8 may be configured to play a sound that the user can hear and identify. When the user identifies the sound, they can determine that the display device 150 has identified the correct SS. In certain embodiments, a vibration-based identification protocol may be used for identification. For example, SS8 may be configured to vibrate in a specific way that alerts the user whether the display device 150 has identified the correct SS.

[0098] In certain embodiments, during the identification step, the SIN may be hashed, truncated, or a combination of both. Figure 3 shows an SS8 and display device 150 that perform an exemplary identification protocol based on hashing, truncation, and / or a combination of both.

[0099] In step 302, the display device 150 obtains a SIN and a pairing code (e.g., a Bluetooth pairing code). In certain embodiments, the user may input the SIN and the pairing code for SS8 into the user interface of the sensor application 121 implemented on the display device 150. In certain embodiments, the display device may obtain them by scanning the pairing code which may be located on the SIN and SS8. In certain embodiments, the pairing code refers to a Bluetooth pairing code which may be used later for authentication between the display device 150 and SS8, and for actual pairing between the two devices. In certain embodiments, instead of a pairing code, another code or password (see, for example, Figure 5) may be used for the purposes described herein. In certain embodiments, the SIN may be a high-entropy SIN. For example, the length of the SIN may be 14 ± 2 characters, and each character may have, for example, 32 possible values. In the embodiment of Figure 3, both SS8 and the display device 150 are configured with an algorithm for calculating an SS identifier based on the SIN, as will be further discussed below.

[0100] In step 304, SS8 uses an algorithm to calculate an SS identifier based on the SIN. In a particular embodiment, the algorithm for calculating the SS identifier may be a hashing algorithm that hashes the SIN to a hash value, e.g., the SS identifier. In a particular embodiment, the algorithm for calculating the SS identifier may be a truncation algorithm that truncates the SIN to produce the SS identifier. In such an embodiment, the SS identifier has fewer characters than the SIN. For example, the truncation algorithm may truncate the SIN from 14 characters to 5 characters. In a particular embodiment, instead of using a truncation algorithm, the user may be asked to input only a portion of the SIN into the user interface of the display device 150. In other words, in such an embodiment, the user manually truncates the SIN. In such an embodiment, the portion of the SIN entered by the user is used as the SS identifier.

[0101] In certain embodiments, the algorithm for calculating the SS identifier may use a combination of hashing and truncation. For example, in certain embodiments, SS8 may first hash SIN using a hashing algorithm, then take the hash value as input and use a truncation algorithm to output the truncated version of the hash value (e.g., the last two characters of the hash value). For example, in certain embodiments, if an algorithm using both hashing and truncation is used, the calculated SS identifier may be as follows: SS identifier = "Manufacturer name" + Last_N_Chars(hash function (SIN))

[0102] In the above formula, Last_N_Chars refers to a truncation algorithm that takes an input (e.g., a hash function (SIN)) and truncates the input to the last N characters, where N can be any number greater than "1". In certain embodiments, the manufacturer name is an optional parameter. The manufacturer name is the manufacturer name of the SS and can be represented in characters. The hash function () refers to a hashing algorithm that takes SIN as input and outputs a hash value. In other specific embodiments, the computed SS identifier may be as follows: SS identifier = "Manufacturer name" + hash function (Last_N_Chars(SIN))

[0103] After calculating the SS identifier, SS8 is ready to begin advertising the SS identifier (for example, periodically).

[0104] In step 306, the display device 150 calculates an SS identifier based on SIN, using the same algorithm as that used by SS8 in step 304. After calculating the SS identifier, the display device 150 is ready to begin searching for the SS identifier.

[0105] In step 308, SS8 advertises the SS identifier. In certain embodiments, SS8 begins to periodically advertise the SS identifier immediately after it has been calculated.

[0106] In step 310, the display device 150 compares the SS identifier calculated by the display device 150 in step 306 with the SS identifier advertised by SS8 in step 308.

[0107] In step 312, the display device 150 identifies that SS8, which transmitted the SS identifier in step 308, is the correct SS for connection.

[0108] It should be noted that in certain embodiments, several combinations of the above identification protocols may be used. For example, the display device 150 and SS8 may be configured to engage in the identification step using an algorithm that employs a combination of hashing and truncation, while simultaneously the display device 150 and SS8 may be further configured with one of the proximity-based techniques described above.

[0109] The identification protocols described herein help protect the SIN of SS8 which may be considered Personal Identification Information (PII) and / or Personal Health Information (PHI). The identification protocols described herein thereby reduce the possibility that an attacker could obtain any information during the identification phase that could be used, for example, to impersonate SS8 for the purpose of subsequently authenticating and connecting to the display device 150. In certain embodiments, the display device 150 may not use an in-band or out-of-band identification protocol to identify the correct SS. In such embodiments, the display device 150 may connect to any SS within range until the correct SS is identified.

[0110] certification In some cases, once a display device identifies a SS, the two devices may be configured to authenticate each other. For example, based on a specific authentication protocol, a display device may engage in a challenge-response mechanism with the SS to verify that the SS possesses the shared secret, and vice versa. In some cases, the shared secret may be a SIN. For example, in certain cases, a display device may send a hashed version of the SIN, such as H(H(SIN)), to the SS. An SS configured with the same hashing algorithm can similarly calculate H(H(SIN)) and compare it to what it received from the display device. If the received value and the calculated value are identical, the SS determines that the display device possesses the SIN. Subsequently, the SS sends H(SIN) back to the display device, and based on this, the display device determines that the transmitter also possesses the SIN. Once this challenge-response mechanism is complete, the SS and the display device determine that they trust each other.

[0111] However, as mentioned above, an attacker eavesdropping during this challenge-response mechanism may attempt to obtain H(SIN) and then determine what the SIN is. In such a situation, it may be possible to determine the SIN using H(SIN) because the attacker may possess a hash function (for example, by hacking another SS or display device) and already know most of the characters of the SIN. The attacker may know most of the characters of the SIN based on the SINs of other SSs on the market and by eavesdropping during the identification procedure described above. As mentioned above, during certain identification protocols, the SS transmits certain characters of the SIN in plaintext. If the attacker obtains the SIN, the attacker can impersonate the SS and use the SIN to authenticate and connect to the display device. The attacker may also impersonate the display device in order to connect to the SS using the SIN.

[0112] Using the challenge-response mechanisms described above (e.g., types of authentication protocols) could further expose the system to risks associated with the improper use or access of the SS, display device, and / or the server system communicating with the SS and display device. For example, in certain cases, instead of using a secure SS compatible with the sensor application running on the display device, a patient might use a potentially insecure third-party sensor to connect to a trusted sensor application, whether or not it is compatible with the third-party sensor. In such an example, the third-party sensor might generate inaccurate data that could be stored in the server-provided storage. In another example, a patient might use a potentially insecure sensor application to access analytics or services provided by the server.

[0113] Accordingly, the specific embodiments described herein relate to several authentication protocols that the SS8 and the display device 150 may engage in to address the above-mentioned issues after the identification step. More specifically, the SS8 and the display device 150 may be configured to perform one of several device-centric mutual authentication protocols and / or several user-centric mutual authentication protocols. As described in relation to Figures 4A-4D, the device-centric mutual authentication protocol enables the display device 150 to verify whether the SS8 is trusted by the RCA, e.g., the server system 134, and vice versa. By engaging in the device-centric mutual authentication protocol, for example, even if an untrusted device could obtain the SS8's SIN or another shared secret (e.g., a pairing code), it is possible to prevent untrusted devices from accessing the SS8 or the display device 150.

[0114] As described in relation to Figure 5, the user-centric mutual authentication protocol enables each of the display device 150 and SS8 to generate an authentication key ("K-auth") based on a shared secret (e.g., a pairing code). In certain embodiments, K-auth is an Advanced Cryptographic Standard (AES) key. If both the display device 150 and SS8 generate the same K-auth, and the K-auth is then verified using a key verification protocol, the display device 150 and SS8 can conclude that the other possesses the shared secret and is therefore trusted by the user. Note that, for example, when a user purchases a trusted SS8 and downloads a trusted sensor application 121, the user enters the SIN and SS8's pairing code (or any other kind of secret information) into the user interface of the sensor application 121. This is because the user trusts both the SS8 and the display device 150. For example, if the user did not trust the display device 150 or the sensor application 121, the user would not share the SS8's SIN and pairing code with the display device 150. In certain embodiments, a user sharing the SS8's SIN and pairing code with the display device 150 includes or refers to the user entering the SS8's SIN and pairing code into the user interface of the display device 150. Thus, by using a user-centric authentication protocol, SS8 can verify whether the patient trusts the display device 150 based on whether the display device 150 possesses the shared secret. In certain embodiments, the pairing code is used as the shared secret. In other specific embodiments, any other identifier related to SS8 may be used as the shared secret instead.

[0115] In certain embodiments, after the identification step, the display device 150 and SS8 first execute a device-centric mutual authentication protocol, and then execute a user-centric mutual authentication protocol. In other specific embodiments, after the identification step, the display device 150 and SS8 first execute a user-centric mutual authentication protocol, and then execute a device-centric authentication protocol. In certain embodiments, after the identification step, the display device 150 and SS8 may execute only one of the user-centric and device-centric mutual authentication protocols.

[0116] Device-Centric Authentication Protocol Figure 4A is a sequence diagram showing display device 150 and SS8 engaged in the device-centric authentication protocol. Figure 4B shows an exemplary chain authorization that may be used as part of the device-centric authentication protocol. Figures 4C and 4D show alternative and / or additional embodiments for performing the device-centric authentication protocol. Therefore, Figures 4A, 4B, 4C, and 4D are presented together for clarity.

[0117] In step 402 of Figure 4A, the display device 150 transmits its certificate or authentication data to SS8. In certain embodiments, as shown in step 402 of Figure 4C, the certificate of the display device 150 includes the authorization of the display device 150, as well as a message signed by the display device 150. In certain embodiments, as shown in Figure 4D of step 402, the certificate of the display device 150 may include the authorization of the display device 150. In certain embodiments, the authorization of the display device 150 includes additional information such as the public key of the display device 150 ("DD-Pub") and / or the name of the display device 150, and authorization expiration information. In certain embodiments, the authorization of the display device 150 also includes a digital signature from the server system 134 or SCA.

[0118] In certain embodiments, the message signed by the display device 150 refers to a message comprising a first unencrypted portion and a second portion containing a digital signature. In certain embodiments, the digital signature refers to an encrypted hash of the first portion. In certain embodiments, the display device 150 encrypts the hash of the first portion using its private key ("DD-Priv").

[0119] In certain embodiments where the authorization for display device 150 is not directly signed by the private key of server system 134, display device 150 may also be configured to transmit any intermediate authorizations of SCAs associated with the authorization chain of display device 150. However, in certain embodiments, SS8 may already be configured with such intermediate authorizations, in which case display device 150 may refrain from transmitting such intermediate authorizations to SS8.

[0120] In step 404 of Figure 4A, SS8 verifies the certificate of display device 150. In a particular embodiment, SS8 consists of (for example, stores) a signed license of server system 134, which includes the public key of server system 134 ("RCA-Pub"). In a particular embodiment, where the license for display device 150 is signed by the private key of server system 134 ("RCA-Priv"), SS8 uses RCA-Pub to decrypt or verify the digital signature contained in the license for display device 150. Note that RCA-Pub can decrypt anything signed with RCA-Priv. Therefore, if SS8 can decrypt the digital signature and the resulting information is equal to the hash of the first unencrypted portion of the license for display device 150, SS8 can conclude that display device 150 is trusted by server system 134. This is because RCA-Priv was used to sign the license for display device 150. If SS8 fails to decrypt the digital signature, SS8 concludes that the display device 150 is not trusted and terminates the device-centric mutual authentication protocol. Note that in certain embodiments, SS8 may communicate directly with and be authenticated by the server system 134 (via WiFi, cellular, etc.), and vice versa.

[0121] In a particular embodiment in which one or more intermediate licenses are involved in the license chain for display device 150, SS8 authenticates each of the involved intermediate certificates, starting with an intermediate license signed by RCA-Priv (i.e., an intermediate license of the SCA directly under server system 134 in the license chain) and ending with an intermediate license that uses a private key to sign the license for display device 150. Once all intermediate licenses are authenticated, SS8 authenticates the license for display device 150. Further details regarding the authentication of the license chain are described in step 408 and with reference to Figure 4B, which shows the license chain of SS8.

[0122] As described above, Figures 4C and 4D illustrate alternative embodiments for implementing a device-centric authentication protocol, including step 404 shown in Figure 4A. In a particular embodiment, if the certificate for display device 150 in Figure 4C includes a message signed by display device 150, in step 404, SS8 determines whether it was actually display device 150 itself that sent the certificate for display device 150 using the signed message in step 402. In other words, SS8 verifies the integrity of the sending entity for the certificate of display device 150, including verifying that the transmitter owns the DD-priv. Note that the sending entity for the certificate of display device 150 is the entity that sent the certificate for display device 150. Since no device other than display device 150 can own the DD-priv, by ensuring that the sending entity owns the DD-priv, SS8 can conclude that the sending entity for the certificate of display device 150 is indeed display device 150.

[0123] To verify whether the sending entity possesses DD-Priv, SS8 uses DD-Pub from the Display Device 150 authorization (which SS8 has already authenticated in step 404) to decrypt the encrypted portion (i.e., the second portion) of the signed message. If the unencrypted version of the second portion is equal to the hash of the first portion of the signed message, it means that the signed message was signed by DD-Priv. Thus, SS8 concludes that the sending entity that sent the Display Device 150 certificate was actually the Display Device 150 itself. Performing this integrity verification may be advantageous in protecting against attackers who might improperly obtain the Display Device 150 authorization and attempt to impersonate the Display Device 150 (for example, an attacker in the middle who intercepted the Display Device 150 while it was sending the Display Device 150 certificate).

[0124] In a particular embodiment of Figure 4D, if the certificate of the display device 150 does not contain a message signed by the display device 150, the integrity of the sending entity of the certificate of the display device 150 may be verified during the implementation of the key verification protocol, as described in relation to Figure 6C.

[0125] Returning to Figure 4A, in step 406, SS8 transmits its certificate to the display device 150. In certain embodiments, as shown in step 406 of Figure 4C, the SS8 authorization includes the SS8 certificate, as well as a message signed by SS8. In certain embodiments, as shown in step 406 of Figure 4D, the SS8 certificate includes only the SS8 authorization. In certain embodiments, the SS8 authorization is signed directly by the server system 134, and in other specific embodiments, the SS8 certificate is signed by the SCA. In certain embodiments where the SS8 authorization is signed by the SCA, in step 406, SS8 may transmit any intermediate authorization in the chain of SS8 authorizations. Note that steps 404-408 are triggered because the display device 105 transmitted its certificate to SS8 in step 402.

[0126] Moving on to Figure 4B, which shows a chain of licenses related to SS8. In the example in Figure 4B, two SCAs (which may be, or include, one or more servers or computing devices) having intermediate licenses 422 and 424 are involved in the chain of licenses for SS8. As shown, the chain of licenses for SS8 begins with SS8's own license 420 and ends with the license 426 of server system 134. In certain embodiments, the license for SS8 includes additional information such as the public key of SS8 ("SS-Pub") and / or the name of SS8, and license expiration information. The license for SS8 also includes a digital signature, which points to a hash of the information in the license for SS8 420 (e.g., the name of SS8, SS-Pub, and license expiration information) encrypted with the private key of SCA2 (which may be, or include, one or more servers or computing devices). Similarly, intermediate license 422 is signed by the private key of SCA1, and intermediate license 424 is signed by the RCA-Priv of server system 134.

[0127] Returning to Figure 4A, in step 408, the display device 150 verifies the certificate of SS8. For example, first, the display device 150 may verify the identity of the authorization document 424 by decrypting the digital signature in the authorization document 424 using RCA-Pub. Then, the display device 150 hashes the information (excluding the digital signature) contained in the authorization document 424. If the hashing and decryption results are identical, the reliability of the authorization document 424 is determined. The display device 150 similarly verifies the reliability of authorization documents 422 and 420. Once authorization document 420 has also been verified, the display device 150 can conclude that SS8 is trusted by the server system 134.

[0128] In a particular embodiment of Figure 4C, if the SS8 certificate contains a message signed by SS8, the display device 150 uses the signed message to determine whether it was actually SS8 that sent the SS8 certificate in step 406. Verification of the integrity of the sending entity of the SS8 certificate is performed in the same manner as described above. More specifically, verifying the integrity of the sending entity of the SS8 certificate includes decrypting the signed message using SS-Pub and hashing the information in the message. If the results of decryption and hashing are identical, the display device 150 concludes that the sending entity of the SS8 certificate was actually SS8 itself.

[0129] When the display device 150 and SS8 verify each other's certificates, each of them authenticates that the other is trusted by the server system 134, for example, the diabetes trust management system.

[0130] Figure 4C shows a device-centric authentication protocol as described above, in which the display device 150 and SS8 are configured to send signed messages to each other for the purpose of verifying integrity. Figure 4D shows a device-centric authentication protocol as described above, in which the display device 150 and SS8 are configured not to send signed messages to each other for the purpose of verifying integrity.

[0131] User-centered authentication protocol Figure 5 shows display devices 150 and SS8 engaging in a user-centric mutual authentication protocol. As described above, by engaging in the user-centric mutual authentication protocol, each of the display devices 150 and SS8 can generate an authentication key (e.g., K-auth) based on a shared secret (e.g., a pairing code). If both the display device 150 and SS8 generate the same K-auth, and it is then verified using a key verification protocol, each of the display devices 150 and SS8 can conclude that the other possesses the shared secret and is therefore trusted by the user. The user-centric authentication protocol may include one of various password authentication key exchange (PAKE) algorithms. PAKE is a cryptographic key exchange protocol. A notable feature of PAKE is that one device (e.g., SS8) can authenticate itself to the other device (e.g., display device 150) using a password or a shared secret (e.g., a pairing code). PAKE is further designed so that two parties (e.g., display device 150 and SS8) can generate or derive a high-entropy authentication key (e.g., K-auth) from a shared low-entropy secret (e.g., pairing code). If an attacker engages with the device and the PAKE protocol, the attacker can only guess about the shared secret once and then know that their guess was wrong. No other information is disclosed.

[0132] One of the various PAKE algorithms can be used as part of a user-centric authentication protocol. Examples include Juggling PAKE (or J-PAKE), EC-J-PAKE (Elliptic Curve Cryptography), SPEKE (Simple Password Index Key Exchange), CRS-J-PAKE (Common Reference Column-J-PAKE), AuCPace (Extensible Composable Password Authenticated Connection Establishment), BSPEKE (SPEKE with a "B" extension), zkPAKE (Zero Knowledge PAKE), C2C-PAKE (Client-to-Client PAKE), and EKE (Encryption Key Exchange).

[0133] An example of how to execute the J-PAKE algorithm between two devices is described on page 10 of F. Hao and P. Ryan's *J-PAKE: Authenticated Key Exchange Without PKI*, *Springer Transactions on Computational Science XI*, *Special Issue on Security in Computing*, Part II, Vol. 6480, pp. 192-206, 2010 (hereinafter referred to as "Hao").

[0134] As described on page 10 of Hao, G is Z of order q. * p This shows a subgroup of the Diffie-Hellman problem (DDH) that is difficult to handle. g is the generator of G. Two communicating parties, SS8 and display device 150, both agree on (G, g). s (pairing code, etc.) is a shared password, and s≠0 if the password is not empty. The value of s is in the range \[1, q-1]. Display device 150 randomly selects two secret values ​​x1 and x2. x1∈ R \[0, q-1] and x2∈ R [1, q-1] Similarly, SS8 is x3∈ R \[0, q-1] and x4∈ R Select [1, q-1]. Note that x2, x4 ≠ 0.

[0135] In Round 1 of J-PAKE, the display device 150 sends proofs of knowledge for g x1 , g x2 , and x1 and x2. Similarly, SS8 sends proofs of knowledge for g x3 , g x4 , and x3 and x4. Since the above communications are independent of each other for both parties, they can be completed in one round. When Round 1 ends, SS8 and the display device 150 verify the received proofs of knowledge and also check that g x2 , g x4 ≠1.

[0136] In Round 2 of J-PAKE, the display device 150 sends proofs of knowledge for DD = g (x1+x3+x4)·x2·s and x2·s. Similarly, SS8 sends proofs of knowledge for SS = g (x1+x2+x3)·x4·s and x4·s. When this round ends, the display device 150 calculates K=(SS / g x2·x4·s ) x2 = g (x1+x3)·x2·x4·s , and SS8 calculates K=(A / g x2·x4·s ) x4 = g (x1+x3)·x2·x4·s Using the same keying material K, a session key (e.g., K-auth) can be derived. κ = H(K), where H is a hash function. Thus, by following a user-centric authentication protocol that may include one of various PAKE algorithms, each of the display device 150 and SS8 can derive K authentication (e.g., a session key). The details of the remaining PAKE algorithms are not described here for the sake of brevity.

[0137] In certain embodiments, one or more techniques can be used to configure SS8 and / or the display device 150 to engage in the user-centric authentication protocol described herein in response to the occurrence of a specific event or action. For example, SS8 may be configured to engage in the user-centric authentication protocol when it receives a specific trigger, such as when SS8 is physically tapped more than a certain number of times. In one example, SS8 may be configured to engage in the user-centric authentication protocol when SS8 is tapped three times. In this case, SS8 sends a request to the display device 150 to engage in the user-centric authentication protocol. In certain embodiments, it may be advantageous to configure SS8 to engage in the user-centric authentication protocol when it is tapped multiple times or when it receives a specific predetermined action, in order to avoid SS8 accidentally engaging in the protocol (for example, when a user is playing a game and a ball hits SS8, causing it to tap accidentally). In certain embodiments, SS8 may consist of haptic-related hardware and software for performing the above techniques, as is known to those skilled in the art.

[0138] In certain embodiments, the occurrence of a particular event may include the presence of SS8 and / or the display device 150 at a specific, pre-specified location. For example, when SS8 and / or the display device 150 are present at a specific location, SS8 may be configured to engage in a user-centric authentication protocol. In certain embodiments, that location may be configurable by the user. In certain embodiments, when SS8 and / or the display device 150 are present at a pre-specified location, the two devices may be able to share secrets in plain text to authenticate each other without engaging in a user-centric protocol for deriving K-auth. In certain embodiments, the user may, via an app on the display device 150, instruct the selection of preferred geographical locations for the display 150 and SS8. In other embodiments, the preferred location may be determined (e.g., by a server) and provided to the display.

[0139] In certain embodiments, the SS8 and the display device 150 (both of which may consist of hardware and software for Bluetooth and / or NFC-related communications) may be configured to engage in or initiate a user-centric authentication protocol and / or a device-centric authentication protocol when the two devices are in close proximity to each other (for example, when the proximity requirement of the signal strength threshold between the two devices is met).

[0140] As described above, it should be noted that in certain embodiments, the display device 150 and SS8 may first engage in a device-centric authentication protocol, and only after that protocol has successfully completed may they then engage in a user-centric authentication protocol. In other specific embodiments, the display device 150 and SS8 may first engage in a user-centric authentication protocol, and only after that protocol has successfully completed may they then engage in a device-centric authentication protocol. In some cases, using a user-centric authentication protocol can be computationally intensive. In such cases, if authentication ultimately fails, using a device-centric authentication protocol first may improve the resource efficiency of each device.

[0141] Furthermore, it should be noted that in certain embodiments, instead of configuring SS8 and the display device 150 to execute a user-centric authentication protocol to derive K-auth, the QR code placed on SS8 or its package may directly function as K-auth. In such embodiments, the display device 150 (e.g., mobile device 120) is configured with appropriate hardware and software for scanning the QR code. After the user scans the QR code using the display device 150, the display device 150 and SS8 engage in a key verification protocol (e.g., steps 914-919 in Figure 9, steps 1014-1019 in Figure 10, etc.) to confirm that both possess K-auth. Once each device confirms that the other possesses K-auth, they are authenticated.

[0142] A combination of user-centric authentication protocols and device-centric authentication protocols. In certain embodiments, a user-centric authentication protocol and a device-centric authentication protocol can be combined to obtain a single protocol. In such embodiments, instead of running user-centric and device-centric mutual authentication protocols separately, the display device 150 and SS8 (or any other partner device described above) may engage in a single protocol to verify whether each party is trusted by the server system 134 and whether the user trusts each device. User-centric and device-centric mutual authentication protocols can be combined in several ways.

[0143] In the first embodiment, a user-centric and device-centric mutual authentication protocol is combined by configuring the first device to send its authorization to the other as part of the data exchange that takes place when the first and second devices engage in the PAKE algorithm. For example, display device 150 may send its authorization instead of the random exponent that display device 150 normally sends to SS8 initially (e.g., in what is called "Round 1" of the J-PAKE algorithm, as described on page 10 of Hao) (i.e., instead of X1 or X2). Similarly, display device 150 may send its authorization instead of the random exponent that SS8 normally sends to display device 150 in the first rounding (e.g., Round 1) as described above (e.g., instead of X3 or X4). Therefore, in certain such embodiments, for example, while two devices are engaged in the J-PAKE algorithm (in which each of the two devices helps determine whether the other is trusted by the user), the two devices transmit their signed licenses to each other, thereby allowing each of the two devices to determine whether the other is trusted by the RCA (for example, by verifying the signing authority).

[0144] In the second set of embodiments, user-centric and device-centric authentication protocols are combined by configuring the first device to sign at least a portion of the information sent to the second device during Round 1 of the J-PAKE algorithm using its public key, as described on page 10 of Hao. In the second set of embodiments, in the same transmission, the first device is also configured to send its authorization to the second device. For example, display device 150, g x1 and g x2 Sign one or both of them and send them to SS8 along with the zero-knowledge certificates for X1 or X2, and the authorization for the display device 150. Similarly, SS8 will x3 and g x4 Sign one or both of the documents and send the X3 or X4 zero-knowledge proof, as well as the SS8 authorization, to the display device 150. Thus, in the embodiment of the second formula, each of the two devices can perform integrity verification, verify whether the other is trusted by RCA, and verify whether the user trusts the other device.

[0145] Implementing a combination of user-centric and device-centric authentication protocols according to embodiments of the first and second formulas may lead to greater resource and time efficiency. After engaging in the user-centric authentication protocol, each of the display devices 150 and SS8 is further configured to engage in a key verification protocol to verify whether the other party was able to derive the same K authentication. Figures 6A-6C show three alternative key verification protocols. After engaging in the key verification protocol, if each of the display devices 150 and SS8 can verify that the other party possesses the same K authentication, then it is concluded that each device can trust the other device because the user trusts the other device.

[0146] Key Verification Protocol Figure 6A shows an exemplary key verification protocol 600A in several embodiments. Note that some steps of the key verification protocol 600A may be performed in parallel or overlapping in time. Therefore, the reference numbers assigned to different steps of the key verification protocol 600A may not indicate the order in which they are performed. In certain embodiments, the exemplary key verification protocol 600 is associated with user-centric authentication and / or a combination of user and device-centric authentication. In some embodiments, the key verification process is performed after a key has been generated based on the exchange of a shared secret.

[0147] In step 602, the display device 150 transmits a first challenge value to SS8. In a particular embodiment, the first challenge value is a randomly selected number.

[0148] In step 604, SS8 hashes the first challenge value using the hashing algorithm and shared key to generate a first hash value. In the example in Figure 6A, the shared key is K-auth, which is the key derived during the user-centric authentication protocol (for example, based on a pairing code).

[0149] In step 606, the display device 150 hashes the first challenge value using a hashing algorithm and a shared key to generate a second hash value. The shared key used by the display device 150 is K-auth. In an alternative embodiment, the shared key may be a key from a partner device that can be shared with SS8 and the display device 150.

[0150] In step 608, SS8 transmits the first hash value and the second challenge value to the display device 150. In a particular embodiment, the second challenge value is a randomly selected number.

[0151] In step 610, the display device 150 verifies whether the first hash value and the second hash value are identical. If they are not identical, the display device 150 concludes that SS8 does not possess K-auth and that the key verification protocol 600A has failed. If YES, the display device 150 can conclude that SS8 possesses K-auth and is therefore trustworthy. If the key verification protocol 600A fails, the display device 150 notifies the user that SS8 was not authenticated. In certain embodiments, if a failure occurs, the display device 150 prompts the user to retry the authentication process.

[0152] In step 612, SS8 hashes the second challenge value using the hash algorithm and shared key to generate a third hash value.

[0153] In step 614, the display device 150 sends a fourth hash value to SS8. For example, the display device 150 generates a fourth hash value by hashing the second challenge value received from SS8 using a hashing algorithm and K-auth.

[0154] In step 616, SS8 verifies whether the third and fourth hash values ​​are identical. If they are not identical, SS8 fails the key verification protocol 600A. If YES, SS8 can conclude that the display device 150 owns K-auth and is therefore trustworthy. In certain embodiments, SS8 does not have a display (and therefore cannot display failure notifications), so failures must be identified by the display device 150.

[0155] Figure 6B shows exemplary key verification protocol 600B in several embodiments. Note that some steps of key verification protocol 600B may be performed in parallel or overlapping in time. Therefore, the reference numbers assigned to different steps of key verification protocol 600B may not indicate the order in which they are performed. Also note that in certain embodiments, key verification protocol 600B may utilize the SPEKE protocol.

[0156] In step 620, the display device 150 calculates K' by hashing K-auth and a random number R, where K' = H(K, R). In this equation, H() is a cryptographic hashing algorithm or function, which constitutes both the display device 150 and SS8. H() takes K-auth and R as inputs and K' as its output. K' can be called an obfuscated key because it is generated for the purpose of obfuscating K-auth.

[0157] In step 622, the display device 150 calculates a first hash value whose first hash value is H(K'), and further calculates a second hash value whose second hash value is H(H(K')). In other specific embodiments, instead of rehashing the first hash value to generate the second hash value, the display device 150 may encrypt the first hash value that produces the second hash value E(H(K')), where E is the encryption, and E(H(K')) is the encrypted version of (H(K')).

[0158] In step 624, SS8 calculates K' by hashing K-auth and R, where K' = H(K, R), where H() is the same hashing algorithm used by the display device 150 in step 620. R is also the same R used by the display device 150 in step 620.

[0159] In step 626, SS8 calculates a third hash value which is the third hash value (H(K')), and further calculates a fourth hash value which is the fourth hash value H(H(K')). In other specific embodiments, instead of re-bashing the third hash value to generate the fourth hash value, SS8 may encrypt the third hash value which produces the fourth hash value E(H(K')).

[0160] In step 628, the display device 150 sends a second hash value to SS8.

[0161] In step 630, SS8 verifies whether the second and fourth hash values ​​are identical. If yes, SS8 can conclude that the display device 150 possesses K-auth. Otherwise, SS8 concludes that the display device 150 does not possess K-auth and that the key verification protocol 600B has failed. If the key verification protocol 600B fails, the display device 150 notifies the user that authentication failed. In certain embodiments, in case of failure, the display device 150 prompts the user to retry the authentication process.

[0162] In step 632, SS8 transmits a third hash value H(K') to the display device 150. In other specific embodiments, instead of transmitting a third hash value, SS8 may encrypt K' to generate E(K') and transmit the encrypted version of K' to the display device 150.

[0163] In step 634, the display device 150 verifies whether the first hash value and the third hash value are identical. If yes, the display device 150 can conclude that it owns K-auth. Otherwise, the display device 150 concludes that SS8 does not own K-auth and that the key verification protocol 600B has failed. In a particular embodiment, in step 632, SS8 sends E(K') to the display device 150, then in step 634, the display device 150 is also configured to calculate E(K') to compare the one sent by SS8 in step 632 with the one calculated by the display device 150. If the key verification protocol 600A fails, the display device 150 notifies the user that SS8 was not authenticated. In a particular embodiment, in case of failure, the display device 150 prompts the user to retry the authentication process.

[0164] Figure 6C shows exemplary key verification protocol 600C in several embodiments. Key verification protocol 600C can be used in conjunction with embodiments of the device-centric authentication protocol described in relation to Figure 4D. As described above, in contrast to Figure 4C, in Figure 4D, the display devices 150 and SS8 are not configured to send signed messages to each other for integrity verification purposes. Therefore, in embodiments in which the display devices 150 and SS8 use the device-centric authentication protocol of Figure 4D, the devices may use key verification protocol 600C, thereby enabling each device to perform integrity verification during the key verification stage. It should be noted that some steps of key verification protocol 600C may be performed in parallel or overlapping in time. Therefore, the reference numbers assigned to different steps of key verification protocol 600C may not indicate the order in which they are performed.

[0165] Steps 640 to 646 are the same as steps 620 to 626 in Figure 6B.

[0166] In step 648, the display device 150 sends the second hash value H(H(K')) and the signed version of the second hash value to SS8. The signed version of the second hash value refers to the second hash value encrypted with DD-Priv on the display device 150.

[0167] In step 650, SS8 verifies whether the second and fourth hash values ​​are identical. If yes, SS8 can conclude that display device 150 possesses K-auth. Otherwise, SS8 concludes that display device 150 does not possess K-auth and that key verification protocol 600C has failed. If key verification protocol 600C fails, display device 150 notifies SS8 that authentication was not successful. In certain embodiments, in case of failure, display device 150 prompts the user to retry the authentication process. SS8 also verifies the integrity of the sending entity of the second hash value. For example, SS8 decrypts the signed second hash value using the DD-pub of display device 150 from the verified authorization of display device 150 (verified in step 404 of Figure 4D, for example). If the result of decrypting the signed second hash value is equal to the second hash value sent in step 648, SS8 can conclude that the entity that sent the second hash value is actually the display device 150 and not the attacker (for example, SS8 then sends a confirmation message to the display device 150).

[0168] In step 652, SS8 transmits the third hash value H(K'), as well as a signed version of the third hash value, to the display device 150. The signed version of the third hash value refers to the third hash value encrypted with SS-Priv of SS8. Similar to Figure 6B, in other specific embodiments, instead of transmitting the third hash value, SS8 may encrypt K' to produce E(K') and transmit the encrypted version of K' to the display device 150.

[0169] In step 654, the display device 150 verifies whether the first hash value and the third hash value are identical. If yes, the display device 150 can conclude that SS8 possesses K-auth. Otherwise, the display device 150 concludes that SS8 does not possess K-auth and that the key verification protocol 600C has failed. If the key verification protocol 600C fails, the display device 150 notifies the user that SS8 was not authenticated. In certain embodiments, in case of failure, the display device 150 prompts the user to retry the authentication process.

[0170] The display device 150 also verifies the integrity of the entity that sent the third hash value. For example, the display device 150 decrypts the signed third hash value using SS8's SS-Pub from SS8's verified authorization (verified, for example, in step 408 in Figure 4D). If the result of decrypting the signed first hash value is equal to the third hash value sent in step 652, the display device 150 can conclude that the entity that sent the third hash value is indeed SS8 and not an attacker. In an embodiment where, similar to Figure 6B, SS8 sends E(K') to the display device 150 in step 652, then in step 654, the display device 150 is also configured to calculate E(K') and compare the one sent by SS8 in step 652 with the one calculated by the display device 150.

[0171] Each of the display device 150 and SS8 can determine that the other is trusted by the RCA, for example, the server system 134, and the user, after engaging in user-centric, device-centric authentication, and / or key verification protocols, or a combination thereof. Subsequently, the SS8 and the display device 150 can establish a communication link for data exchange. In embodiments where the SS8 and the display device 150 are configured with the BLE protocol, the two devices engage in pairing and bonding, as further described with respect to Figure 7.

[0172] It is advantageous to implement both user-centric mutual authentication protocols and device-centric mutual authentication protocols. This is because if only user-centric mutual authentication protocols are used for authentication, an attacker may repeatedly attempt to engage with either SS8 or display device 150 in the user-centric mutual authentication protocol until they can guess the correct K-auth through brute force (also known as a brute-force attack). In such a situation, by configuring each of SS8 and display device 150 to further engage in device-centric mutual authentication protocols, the attacker will lose trust from the server system 134 and ultimately be unable to complete the authentication process. Furthermore, in certain embodiments, to reduce the success rate of brute-force attacks, the two devices may be configured with a throttling mechanism, as further described below.

[0173] On the other hand, in some examples, the display device 150 and SS8 may be configured to perform a device-centric mutual authentication protocol. In such examples, for instance, an attacker who improperly obtains the authorization and private key of the display device 150 could authenticate the SS8 and gain access to it. In such a situation, by configuring each of the SS8 and the display device 150 to further engage in a user-centric mutual authentication protocol, the attacker would ultimately be unable to complete the authentication process because they do not possess the shared secret (e.g., pairing code) used as part of the user-centric mutual authentication protocol.

[0174] While it may be advantageous to implement both user-centric and device-centric authentication protocols, it should be noted that in certain embodiments, one of the protocols is implemented for authentication purposes.

[0175] throttle To reduce the success rate of the brute-force attack described above, with respect to repeated attempts by an attacker to engage in user-centric authentication protocols, each of the SS8 and display device 150 may be configured with a throttling mechanism. This controls or limits the number of times a device can engage in user-centric authentication protocols with a potentially malicious device. For example, a first device (e.g., the attacker's device) may continue to attempt to authenticate a second device (e.g., display device 150 or SS8). However, in certain embodiments, the second device may use the throttling mechanism to throttle the number of times the first device can initiate authentication with a false K-auth, i.e., the number of times the second device can approve the authentication request or participate in authentication. For example, the second device may throttle the number of attempts by the first device to a defined number (e.g., 1, 2, etc.) and / or within a certain period of time. In certain embodiments, if the first device provides a false K-auth once, the second device may refrain from engaging in any form of authentication with the first device for a certain period (e.g., 5 minutes). For example, if the first device provides a false K-auth twice after 5 minutes, the first device may refrain from engaging in authentication with the first device for a longer period (e.g., 10 minutes). In this example, the second device reduces the number of times the first device can initiate authentication with a false K-auth to two in 15 minutes. In certain embodiments, for example, if the first device (e.g., an attacker) provides a authorization or signature that cannot be authenticated by the second device, a similar throttling mechanism may be used with respect to the device-centric authentication protocol. In some examples, the second device (e.g., display device 150 or SS8) may provide a notification to the user about the failure of the authentication attempt. For example, the DD150 may notify the user on its display that it was unable to perform authentication, and further notify the user that another method for authenticating the device will be performed within a specified time.The above notification related to a failed attempt may be provided when SS8, display device 150, and / or any other trusted partner device initiate an authentication process and an attacker attempts to compromise that authentication process. It is assumed that the user can take any necessary initiatives to mitigate such malicious attacks (e.g., shutting down the device, notifying legal authorities).

[0176] It should be noted that in certain embodiments, there is a wireless address associated with each device (e.g., a BLEMAC (Media Access Card) address or another identifier). In certain embodiments, when two devices engage in an authentication protocol, such as a user-centric or device-centric authentication protocol, the data transmitted by each device includes the wireless identifier. Thus, for example, if the first device fails to authenticate the second device once, the second device caches or remembers the wireless address of the first device, and as a result, the second device can throttle further authentication attempts by the first device for a certain period (e.g., 5 minutes), as described above.

[0177] Single device rule In certain cases, an attacker may use a malicious display device to engage in mutual authentication (e.g., user-centric and / or device-centric protocols) and / or key verification protocols with SS8, while, for example, display device 150 (e.g., the user's display device) is already engaged with SS8 in one of such protocols. To prevent an attacker from interfering with the authentication and / or key verification process between SS8 and display device 150, SS8 may be configured to engage in such protocols with only one display device at a time. Thus, in certain embodiments, SS8 may be configured to cache the radio address of display device 150, e.g., the BLEMAC address, after the identification stage. Subsequently, if data packets with different radio addresses are received from different display devices, SS8 may conclude that a device other than display device 150 is attempting to connect to SS8, in which case SS8 may delete such packets based on the single-device rule.

[0178] Further verification of SS ID by the server In certain embodiments, after and / or during mutual authentication between the display device 150 and the SS8, the display device 150 further verifies the identity of the SS8 by sharing the SS-Pub or authorization (including the SS-Pub) of the SS8 with the server system 134. In certain embodiments, the server system 134 stores the public keys associated with marketed SSs, including the SS8. Therefore, the server system 134 may be configured to determine that the public key of the SS8 is in a dangerous situation if it receives the public key or authorization of the SS8 from multiple display devices, or from untrusted display devices or untrusted partner devices, or from the same display device for multiple SSs (at least some of whose public keys may or may not be stored on the server) within a short period of time. For example, if the server system 134 receives the public key of the SS8 from the display device 150, it may determine that another display device has also previously sent the public key of the SS8 to the server system 134. In these situations, the server system 134 may be configured to take one or more security measures, such as revoking the compromised SS8 license and issuing a new license. In such scenarios, the display device 150 may need to initiate a new authentication process with SS8 and the server system 134.

[0179] Pairing and bonding Once the display device 150 and SS8 authenticate each other using one or more authentication protocols, such as the user-centric and / or device-centric authentication protocols described above, the devices engage in pairing and / or bonding. In certain embodiments, the SS8 and display device 150 comply with various radio protocols and standards (e.g., Bluetooth®, Bluetooth Low Energy (BLE), ANT protocol, Wi-Fi, Near Field Communication (NFC), etc.). In one example, the pairing and / or bonding performed between the SS8 and the display device 150 conforms to the BLE standard. In some examples, according to radio protocols and standards (e.g., BLE Secure Mode Pairing and Bonding Standards), pairing is the exchange of security features such as input / output (IO) capabilities and man-in-the-middle (MITM) protection requirements. During pairing between two communication devices, the two devices may agree on a temporary key (TK), the value of which may depend on the pairing method used. Two devices engage in protecting the subsequent communication link for analyte data communication by generating various communication keys (e.g., short-term key (STK), long-term key (LTK)) for encrypting the communication link. In some examples, devices may store additional information about each other, for example, during the bonding process after pairing. For example, after the exchange of security functions and encryption of the connection, devices bond by exchanging LTKs and storing the LTKs for later use. In other words, bonding refers to the creation of persistent security between devices. Further details regarding pairing and bonding are described in the various specifications of such technologies (e.g., the Bluetooth specification), which are incorporated herein by reference in their entirety. Specifications may be provided by governing bodies of such technologies.

[0180] Figure 7 is a sequence diagram showing the SS8 and display device 150 engaging in pairing and bonding according to the BLE standard. In step 702, the SS8 and display device 150 engage in pairing. In certain embodiments, during the pairing procedure (e.g., step 702), the two devices may engage in authenticated pairing for the purpose of providing protection against man-in-the-middle attacks. Typically, a display device 150 configured to perform authenticated pairing may prompt the user to manually enter a key (e.g., a 6-digit master key) to engage in pairing with the SS8. However, in certain embodiments, the display device 150 may be configured to pair with the SS8 using an application-level security (e.g., pairing) protocol instead of using the BLE protocol. For example, an application-level pairing protocol may include a pairing protocol stored by the device as a result of instructions provided by an application running on the device. In certain embodiments, when an application-level pairing protocol is used, the display device 150 may use K-auth or a version thereof generated as a result of the two devices engaging in the above-mentioned user-centric authentication protocol, instead of prompting the user to manually enter a 6-digit master key.

[0181] In step 704, the SS8 and the display device 150 engage in bonding. After pairing and bonding, the SS8 and the display device 150 are ready to exchange data over a secure connection. For example, the SS8 may use LTK to encrypt data, including user-related analyte measurements, for transmission to the display device 150. The display device 150 may similarly encrypt data for transmission to the SS8. In other words, using LTK, the SS8 and the display device 150 can establish a secure connection for data exchange.

[0182] As described above, in certain embodiments, the display device 150 may be configured to pair and / or bond with the SS8 using an application-level pairing and / or bonding protocol instead of, or in addition to, the BLE protocol. In certain such embodiments, the display device 150 and the SS8 may be configured to use K-auth as the encryption key, or to use K-auth to derive an encryption key to be used for encryption, instead of, or in addition to, using the BLE protocol to establish the LTK. As described in relation to Figure 12, K-auth may be used not only for encryption (e.g., confidentiality) but also for data integrity and reliability when the SS8 and the display device 150 exchange data (e.g., glucose data, sensor data, analyte data, commands, responses, etc.). In certain embodiments, when K-auth is used by the two devices for data encryption, the key verification steps shown in Figures 6A-6C, steps 914-919 in Figure 9, and steps 1014-1019 in Figure 10 may not be performed. Therefore, the two devices can directly engage in encrypted data exchange (using K-auth). For example, if display device 150 does not possess K-auth, then display device 150 cannot decrypt / encrypt communication with K-auth, and SS8 can determine that display device 150 does not possess K-auth without performing a key verification protocol with display device 150. Therefore, the key verification step can be skipped. Skipping the key verification step can lead to resource (computation and battery) efficiency, among other things. In certain embodiments, the key verification step is performed even if K-auth is used for encryption.

[0183] In certain embodiments, the first display device 150 (e.g., mobile device 120) may be configured to share K-auth (which may be used by the first display device 150 and SS8 for encryption, data reliability, and / or data integrity) with the second display device 150 (e.g., a smartwatch such as smartwatch 140, or any other type of display device described herein). For example, the first and second display devices 150 may be configured to connect with each other using a specific communication protocol. In such embodiments, all application-level security commands associated with the first display device 150's communication with SS8 (e.g., agreed K-auth) may be communicated directly (or indirectly via a server) to the second display device 150 using a preferred communication protocol. In such embodiments, the second display device 150 can communicate with SS8 using the same security commands without requiring the second display device 150 and SS8 to re-establish the same security commands and agreements with each other. For example, the second display device 150 may use K-auth or a part thereof for confidentiality (encrypting data using K-auth) and data integrity / reliability (using MAC, for example), as described in more detail with respect to Figure 12. In another example, the second display device 150 may directly engage in encrypted data communication with SS8 instead of, or in addition to, key verification.

[0184] Pass-through communication between the server system and SS In certain embodiments, the SS8 and the server system 134 may be configured to communicate through a pass-through communication path 183. As described above, the pass-through communication path 183 refers to a communication path established between the server system 134 and the SS8 through the display device 150. In certain embodiments, communication over the communication path 183 is encrypted so that the display device 150 cannot read or access the data exchanged over the communication path 183. In certain embodiments, communication over the communication path 183 may be continuous, and in other specific embodiments, communication over the communication path 183 may be periodic. In certain embodiments, communication over the communication path 183 is encrypted with a key. In certain embodiments, the key is an AES key. In certain embodiments, both the SS8 and the server system 134 are composed of or store this key. In certain embodiments, both the SS8 and the server system 134 may store a plurality of keys, as well as a plurality of corresponding index numbers, each index number corresponding to a different key. In such an embodiment, SS8 may select one key from a plurality of keys, encrypt the data for transmission to the server system 134, and then transmit the encrypted data along with an unencrypted index number that identifies the key. In such an embodiment, upon receiving the encrypted data and the unencrypted index number, the server system 134 identifies the key associated with the unencrypted index number and then uses that key to decrypt the data.

[0185] In certain embodiments, instead of storing one or more keys, or in addition to that, SS8 and server system 134 may engage in a specific key exchange algorithm to derive a key for encrypting data exchanged between SS8 and server system 134. In certain embodiments, SS8 and server system 134 engage in a DH key exchange algorithm. In certain embodiments, each of SS8 and server system 134 may be configured to perform a portion (e.g., half) of the DH key exchange algorithm. For example, SS8 may store secret integers "t" and "b". SS8 may store "g" in server system 134. t " can be sent, where g is the modulo primitive root of p. "g t Along with this, SS8 also sends an index for how "b" stored in server system 134 can be found by server system 134. Server system 134 sends "g t When an index number is received, it finds "b" based on the index number and then "g tb The following is calculated: At this point, both SS8 and server system 134 are "g tb It possesses a key which can then be used to encrypt data exchanged between the two devices. In certain embodiments, instead of SS8 and server system 134 engaging in the DH key exchange algorithm, they may engage in the elliptic curve DH ("ECDH") key exchange algorithm. In certain embodiments, each of SS8 and server system 134 may be configured to perform a portion (e.g., half) of the ECDH key exchange algorithm. In yet another embodiment, each of SS8 and server system 134 may perform the complete ECDH key exchange algorithm.

[0186] Security measures for reconnection In certain embodiments, for power-saving purposes, SS8 may periodically exchange data with the display device 150 (for example, by periodically switching between sleep mode and operating mode). For example, in certain embodiments, SS8 may "wake up" every few minutes (e.g., 5 minutes) to exchange data with the display device 150, but may enter sleep mode at 5-minute intervals. To reduce the possibility of an attacker attempting to communicate with SS8, for example, by replaying certain data transmissions previously sent to SS8 by the display device 150, the two devices may be configured to perform one or more security measures between these periodic reconnections.

[0187] Figure 8 is a sequence diagram showing several security measures that the SS8 and the display device 150 may take during periodic reconnection in a particular embodiment.

[0188] In step 802, the SS8 and the display device 150 engage in a key verification protocol during periodic reconnection (for example, at the start of a periodic reconnection). For example, in a particular embodiment, every 5 minutes, the SS8 and the display device 150 engage in the same key verification protocol that the two devices previously engaged in, or a different key verification protocol. As an example, the SS8 and the display device 150 may be configured to engage in key verification protocol 600A during their first connection (i.e., when they first perform key verification), and then engage in key verification protocol 600B during subsequent reconnections. This deters an attacker who might attempt an attack on the first connection (possibly successfully) but fail on a second connection, because the SS8 and the display device 150 use different key verification protocols.

[0189] In step 804, the SS8 and the display device 150 may optionally re-enter K-auth (i.e., derive new K-auth) on connections at periodic intervals, for example. K-auth can be re-entered in one of several ways. In certain embodiments, on a protected connection (encrypted by LTK), the SS8 and the display device 150 may re-enter K-auth by generating a random key or by using an application-level K-auth from a set of keys reserved for this purpose (e.g., stored on the device). Application-level K-auth refers to K-auth stored on the device as a result of instructions provided by an application running on the device, and not generated as a result of the device deriving a key by engaging with other devices in a user-centric authentication protocol (such as J-PAKE). In certain embodiments, only one of the SS8 and the display device 150 may store one or more K-auths, in which case the device storing the one or more K-auths may select one of those K-auths and send it to the other device over a secure connection. In other specific embodiments, both devices may be configured to store one or more K-auths. In such embodiments, the devices may be configured to select the same K-auth on different reconnections by, for example, using a counter or some other mechanism. In other specific embodiments, instead of using, or in addition to using, random or application-level K-auths for re-entry, the SS8 and the display device 150 may engage in a user-centric authentication protocol to derive new K-auths. Periodic re-entry of K-auths may be advantageous if an attacker can obtain the current K-auth by engaging in a brute-force attack.

[0190] After re-entering the K-auth key, the new K-auth key will be used in the key verification protocol that the device is configured to engage with during the next periodic reconnection.

[0191] In step 806, SS8 and display device 150 engage in the exchange of information over a secure connection. For example, every few minutes, SS8 and display device 150 engage in a key verification protocol, optionally re-enter K-auth, and then exchange data (e.g., analyte measurements) that are encrypted with LTK.

[0192] Nance In certain embodiments, to mitigate the possibility of a replay attack, both the SS8 and the display device 150 may be configured to include a nonce in each transmission to the other device (for example, in one or more data packets). A nonce refers to a number used only once. For example, in certain embodiments, each of the display device 150 and the SS8 may consist of a counter. With each transmission, the counter may be incremented by "1". So, in this example, each time a device sends data to the other device, its counter is incremented, and the value of the counter is used as a nonce in the next transmission. Thus, if a receiving device receives the nonce twice, it may be determined that a replay attack has occurred. [Examples]

[0193] Figures 9-12 illustrate exemplary embodiments of how the protocols (or modified versions thereof) discussed above are used by SS8 and the display device 150, as well as other entities within the system 100, to securely identify and authenticate each other, thereby enabling the two devices to exchange data in a secure and confidential manner.

[0194] Figure 9 illustrates the use of a user-centric mutual authentication protocol by SS8 and display device 150, followed by the use of a device-centric mutual authentication protocol. Display device 150 is configured with software and hardware (e.g., a camera) for scanning QR codes (e.g., barcodes that may include the SS8's SIN, pairing code, etc.). For example, in a particular embodiment of Figure 9, display device 150 may be a mobile device such as mobile device 120 having a camera for scanning information such as QR codes.

[0195] In step 901, the display device 150 obtains the pairing code and, optionally, the SIN associated with the SS8. For example, as described above, the SIN and pairing code may be located on the SS8, or on the SS8's package, or on other devices associated with the SS8. In certain embodiments, the user may obtain the SIN and / or pairing code by using the display device 150, for example, by scanning a QR code. In other specific embodiments, the user may choose not to use the scanning function of the display device 150 and instead manually enter the information. However, in such embodiments, the user may be permitted or able to enter the pairing code instead of the SIN. As a result, in embodiments where the user does not scan a QR code, the display device 105 may obtain the pairing code through its user interface. In some embodiments, the SIN may also be entered using the user interface of the display device 150.

[0196] In step 902, SS8 advertises a hash of SIN. For example, SS8 may use a hashing algorithm to generate a hash of SIN that can be advertised periodically (for example, after being installed in a user's body and activated). SS8 may advertise a hash of SIN by including the hash of SIN in a data packet containing additional information, such as manufacturer-related information.

[0197] In the optional step 903, the display device 150 identifies (or verifies the identification of) the SS8. For example, the display device 150 hashes the SIN obtained in step 901 (using the same hashing algorithm SS8 used to generate the hash of the SIN) and determines whether the hashed version of the scanned SIN is identical to the hash of the SIN received from the SS8 in step 902. If they match, the display device 150 can identify the SS8 as the correct SS from among a number of other devices that may be advertising those SINs or their versions. Note that in embodiments where the user chooses not to scan for SINs and instead manually enters a pairing code, step 904 may not be performed.

[0198] In step 904, the display device 150 sends a connection request to SS8.

[0199] In step 906, SS8 confirms the connection request.

[0200] In step 908, the display device 150 sends a message request to SS8 in order to engage in a user-centric authentication protocol. For example, the message request indicates that the display device 150 wants to engage in the PAKE protocol (for example, a type of user-centric mutual authentication protocol) with SS8. The PAKE protocol has various stages (for example, stages 0, 1, 2, etc.), and in one example, the message may indicate a stage (for example, stage 0).

[0201] In step 910, SS8 confirms the request.

[0202] In step 912, the display device 150 and SS8 engage in a user-centric authentication protocol (e.g., PAKE), as previously discussed in relation to Figure 5. Note that SS8 and the display device 150 use a pairing code to engage in the PAKE protocol, for example, to generate K-auth. The display device 150 has obtained a pairing code in step 901, as described above, and SS8 is pre-configured with the pairing code during the manufacturing process. In some cases, SIN may also be used to generate K-auth.

[0203] Steps 914-919 are performed so that each of the two devices can verify that the other device possesses K-auth.

[0204] In step 914, the display device 150 transmits a first challenge value ("challenge value 1") to SS8. In some embodiments, challenge value 1 is a randomly generated number.

[0205] In step 915, SS8 hashes challenge value 1 to generate a hash value ("hash value 1"). For example, SS8 hashes challenge value 1 using a hashing algorithm and K-auth to generate hash value 1. The hashing algorithm is known to both SS8 and the display device 150. In some cases, k-auth may also be referred to as the application key.

[0206] In step 916, SS8 transmits hash value 1 and a second challenge value ("challenge value 2") to the display device 150. In some embodiments, challenge value 2 is a randomly generated number.

[0207] In step 917, the display device 150 verifies whether K-auth is owned by SS8 and also generates hash value 2 to send to SS8. More specifically, the display device 150 hashes challenge value 1 (already known to the display device 150) using the same hashing algorithm and K-auth known to SS8. If the resulting hash value is the same as hash value 1 received from SS8 in step 916, the display device 150 has verified that K-auth is owned by SS8 and that the display device 150 is communicating with the correct device. Otherwise, the display device 150 terminates the protocol. If the display device 150 verifies that K-auth is owned by SS8, the display device 150 hashes challenge value 2 (received from SS8) using the same hashing algorithm and K-auth, and as a result obtains a hash value ("hash value 2") to send to SS8.

[0208] In step 918, the display device 150 sends the hash value 2 to SS8.

[0209] In step 919, SS8 verifies whether the display device 150 possesses K-auth. More specifically, SS8 hashes the challenge value 2 (already known to SS8) using the same hashing algorithm and K-auth. If the resulting hash value is identical to the hash value 2 received from the display device 150 in step 918, SS8 has verified that the display device 150 possesses K-auth and therefore SS8 is communicating with the correct device. Otherwise, SS8 terminates the protocol.

[0210] In step 920, once the display device 150 and SS8 have engaged in a user-centric mutual authentication protocol (e.g., the PAKE protocol) and confirmed that each possesses K-auth, the two devices then engage in executing a device-centric authentication protocol, such as a protocol conforming to the PKI scheme described above. Detailed examples of such device-centric authentication protocols are provided in Figure 11 (and specific parts of Figures 4A-4C and their corresponding descriptions).

[0211] Figure 10 illustrates the use of a user-centric mutual authentication protocol, followed by the use of a device-centric protocol, by a display device 150 that is not configured with any hardware for scanning SS8 and the SIN of SS8. An example of such a display device 150 is display device 110, or any other type of display device that is not capable of scanning the SIN of SS8.

[0212] In step 1001, the display device 150 obtains the pairing code for SS8. The user may manually enter the SS8 pairing code into the user interface of the display device 150.

[0213] In step 1002, SS8 advertises the hash of SIN. Step 1002 is the same as step 902 in Figure 9. However, in the embodiment of Figure 10, the display device 150 cannot access SS8's SIN, so the display device 150 can ignore the hash of SIN received from SS8 in step 1002. In such an embodiment, the display device 150 cannot determine whether SS8 is the correct device from among multiple devices advertising its SIN.

[0214] Steps 1004-1020 are the same as steps 904-920 in Figure 9.

[0215] Figure 11 shows a display device 150, SS8, and / or other entities within system 100 engaged in a device-centric mutual authentication protocol.

[0216] In step 1102, the display device 150 transmits a signed authorization of the issuer of the authorization of the display device 150 (also referred to as a digital authorization or token). The issuer may be an SCA (subordinate certificate authority) with an intermediate authorization signed by an RCA (root certificate authority, e.g., server system 134). The issuer's authorization includes the issuer's public key. Note that the issuer's authorization is signed with RCA-Priv (e.g., the private key of server system 134, as described above). In certain embodiments, the issuer's authorization, as well as the authorization of the display device 150 itself (including the display device 150's public key (DD-Pub)) and private key (DD-Priv), are stored in the display device 150 during the manufacturing process. In certain embodiments, the display device 150 may receive, in response to a user downloading the analyte sensor application 121 and subsequently signing up (for example, by providing the user's email address), an issuer-signed RCA, as well as the display device 150's own license (including the display device 150's public key) and private key from the server system 134 (for example, on the network 190 in Figure 1). In some embodiments, various licenses and keys may be provided to the device during the manufacturing process.

[0217] In step 1104, SS8 authenticates or verifies the issuer's (e.g., the manufacturer of System 100) signed license. For example, SS8 uses RCA-PUB to decrypt the digital signature (in the issuer's signed license) generated using RCA-priv. Additional details on how to authenticate the intermediate license are provided in relation to Figure 4B and its respective descriptions. Authenticating the issuer's license means confirming that the issuer's certificate was indeed signed by RCA.

[0218] In step 1106, SS8 extracts the issuer's public key from the issuer's authorization document.

[0219] In step 1108, the display device 150 sends its own authorization form, signed by the issuer (e.g., the manufacturer), to SS8.

[0220] In step 1110, SS8 verifies the authorization for display device 150 using the issuer's public key. Details on how the authorization for display device 150 may be verified by SS8 may be provided in connection with Figures 4A (e.g., step 404) and 4B and their respective descriptions.

[0221] Steps 1112 to 1118 are performed on two devices so that SS8 can determine whether the display device 150 possesses a private key (DD-Priv) that matches the public key (DD-Pub) authorization for the display device 150 that the display device 150 sent to SS8 in step 1108.

[0222] In step 1112, SS8 sends challenge data (e.g., random data) to the display device 150 in order to determine whether the display device 150 was actually the one that sent the authorization for the display device 150 in step 1108 (i.e., whether the display device 150 possesses a private key (DD-Priv) that matches the public key (DD-Pub) authorization for the display device 150 that it sent to SS8 in step 1108).

[0223] In step 1114, the display device 150 signs the challenge data using the private key (DD-Priv) of the display device 105.

[0224] In step 1116, the display device 150 sends the signed challenged data to SS8.

[0225] In step 1118, SS8 uses the public key of display device 150 from a previously received public key authorization for the device to verify the digital signature associated with the signed challenge data. By verifying or authenticating the digital signature of display device 150 as described above, SS8 can determine whether it was actually display device 150 itself that sent the authorization for display device 150 in step 1108. In other words, SS8 verifies the integrity of the sending entity for the authorization for display device 150, along with verification that the sender owns the DD-priv. Note that the sending entity for the authorization for display device 150 is the entity that sent the certificate for display device 150 in step 1108. Since no device other than display device 150 can own the DD-priv, by ensuring that the sending entity owns the DD-priv, SS8 can conclude that the sending entity for the certificate for display device 150 is indeed display device 150. Additional details regarding the verification of the digital signature of display device 105 are provided in Figure 4C and its corresponding description.

[0226] Although not illustrated, in a symmetrical manner, SS8 similarly transmits any relevant authorizations (e.g., SS8 authorization, authorization of the issuer of SS8 authorization) to the display device 150, thereby enabling the display device 150 to verify whether SS8 is trusted by the RCA. Furthermore, the display device 150 transmits SS8 challenge data for signing using SS8's private key. Upon receiving the signed challenge data, the display device 150 can similarly verify the integrity of the entity transmitting SS8 authorization, which involves verifying that the sender possesses SS-Priv (i.e., verifying that SS8 itself actually transmitted SS8 authorization). Note that device-centric authentication (e.g., the PKI authorization exchange process described in Figure 11) may occur once per user-centric authentication (e.g., the PAKE process).

[0227] Figure 12 illustrates the use of K-auth exemplifies when SS8 and display device 150 begin exchanging information (e.g., glucose values, sensor data, analyte data, etc.) to verify the authenticity / integrity of the data and provide confidentiality. For example, after display device 150 and SS8 authenticate each other using one or more authentication protocols, such as the user-centric and / or device-centric authentication protocols described above, the two devices may engage in pairing and / or bonding, as shown in Figure 7. As part of pairing and / or bonding (which can be performed using the BLE protocol or an application-level protocol), the two devices may agree to encrypt the data exchanged between the two devices through the use of a Message Authentication Code (MAC), as described below, and utilize K-auth to verify the authenticity / integrity of the exchanged data. As considered, in some embodiments, K-auth may be derived as a result of display device 150 and SS8 engaging in a user-centric mutual authentication protocol (e.g., the PAKE protocol), as shown in Figures 5, 9, and 10.

[0228] In step 1201, the display device 150 uses a MAC algorithm that receives a first message and K-auth to generate a first MAC as input. In certain embodiments, the first message may include any data that the display device 150 can configure to communicate with SS8 (e.g., data request commands, sensor status requests, calibration data requests, algorithm status requests, etc.). In certain embodiments, the display device 150 may encrypt the first message using K-auth. In certain embodiments, the display device 150 and SS8 may agree to use a portion (e.g., half) of K-auth to generate a MAC and the other portion (e.g., half) to encrypt the corresponding message. For example, the display device 150 may use half of K-auth to generate a first MAC based on the first message and the other half to encrypt the first message.

[0229] In step 1202, the display device 150 sends the first message to SS8 along with the first MAC.

[0230] In step 1204, SS8 uses K-auth to verify the authenticity and integrity of the first message. In embodiments where the first message is encrypted using K-auth or a part thereof, SS8 first decrypts the first message. Then, using the same MAC algorithm that SS8 may be configured with during the manufacturing process, SS8 takes the first message and K-auth as input and generates a MAC as output. If the generated MAC is identical to the first MAC received in step 1202, SS8 can verify that the first message actually came from the display device 150 (since only the display device 150 should possess K-auth) and that the message was not tampered with during transmission.

[0231] In embodiments where the first message is not encrypted using K-auth, SS8 does not need to decrypt the first message before verifying its authenticity and integrity. In embodiments where a portion of K-auth is used by the display device 150 to encrypt the first message and the other portion is used to generate the first MAC, SS8 first decrypts the first message using the same portion of K-auth used for encryption, and then verifies the authenticity and integrity of the first message using the other portion of K-auth. In certain embodiments, both the display device 150 and SS8 are configured with the same algorithm that enables each device to determine which portion of K-auth is used for encryption and which portion is used to generate the MAC.

[0232] In step 1206, SS8 generates a second MAC using K-auth and the second message. SS8 performs the same operation as the display device 150 in step 1201, using the same MAC algorithm as described above. The second message may contain any data that SS8 would normally send to the display device 150 as part of its operation (e.g., analyte data, sensor data, or any data requested by the display device 150 using the MAC).

[0233] In step 1208, SS8 sends a second message along with a second MAC to the display device 150.

[0234] In step 12010, the display device 150 verifies the reliability and integrity of the second message by performing an operation similar to the operation performed by SS8 in step 1204.

[0235] The embodiments described herein provide technical solutions to technical challenges related to specific prior art security protocols used for purposes such as identification, authentication, and key verification. For example, specific embodiments described herein relate to a set of identification protocols aimed at enabling a display device to effectively identify a Security Service (SS) and reducing the likelihood that an attacker could obtain any information useful to impersonate the SS or display device during the identification process. Furthermore, specific embodiments described herein relate to a set of authentication and key verification protocols that the SS and display device may engage in after the identification stage, enabling each device to verify whether the other device is trusted by the RCA and / or the device's user.

[0236] Each of these non-limiting examples may stand on its own or be combined with one or more of the other examples in various permutations or combinations. The above detailed description includes references to the accompanying drawings, which constitute part of the detailed description. The drawings illustrate specific embodiments that can put the invention into practice. These embodiments are also referred to herein as “Examples.” Such embodiments may include elements in addition to those shown or described. However, the inventors also envision embodiments in which only the shown or described elements are provided. Furthermore, the inventors also envision embodiments that use any combination or permutation of the shown or described elements (or one or more embodiments thereof), either relating to a specific embodiment (or one or more aspects thereof) or to other embodiments (or one or more aspects thereof) shown or described herein.

[0237] In the event of any inconsistency in usage between this document and any of the documents incorporated by reference, the usage in this document shall prevail.

[0238] In this document, the terms “a” or “an” are used to mean one or more, as is common in patent documents, regardless of other instances or uses of “at least one” or “one or more.” In this document, the term “or” is used to mean non-exclusive “or,” such that “A or B” includes “A but not B,” “B but not A,” and “A and B.” In this document, the terms “include” and “in which” are used as plain English equivalents of the terms “equip” and “therefore.” Furthermore, in the following claims, the terms “include” and “equip” are unrestricted; that is, any system, device, article, composition, formula, or process that includes elements in addition to those listed after such terms in the claims is still considered to be within the scope of the claims. In addition, in the following claims, terms such as “first,” “second,” and “third” are used merely as designations and are not intended to impose numerical requirements on those objects.

[0239] Geometric terms such as "parallel," "perpendicular," "circular," or "quadrilateral" are not intended to require absolute mathematical precision unless otherwise indicated in the context. Instead, such geometric terms allow for variations due to manufacturing or equivalent function. For example, if an element is described as "circular" or "generally circular," elements that are not exactly circular (e.g., somewhat rectangular or multi-sided polygons) are also included in this description.

[0240] Examples of methods described herein can be implemented at least partially by machine or computer. Some examples may include computer-readable or machine-readable media encoded with instructions that can be operated to configure an electronic device to perform the methods described in the above examples. Implementations of such methods may include code, such as microcode, assembly language code, or higher-level language code. Such code may include computer-readable instructions for performing various methods. The code may form part of a computer program product. Furthermore, in one example, the code may be tangibly stored in one or more volatile, non-temporary, or non-volatile tangible computer-readable media during execution or at other times. Examples of these tangible computer-readable media may include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memory (RAM), read-only memory (ROM), and the like.

[0241] The above description is intended to be illustrative and not limiting. For example, the above embodiments (or one or more embodiments thereof) may be used in combination with each other. A person skilled in the art may, for example, use other embodiments by considering the above description. The abstract is provided in accordance with Section 1.72(b) of the U.S. Patent Law Enforcement Rules to enable the reader to quickly confirm the nature of the technical disclosure. It is submitted with the understanding that it is not to be used to interpret or limit the scope or meaning of the claims. Also, in the above detailed description, various features may be grouped together in order to simplify the disclosure. This should not be interpreted as meaning that any disclosed features not claimed are essential to any patent claim. Rather, the subject matter of the invention may be less than all the features of a particular disclosed embodiment. Consequently, the following claims are incorporated into the detailed description as examples or embodiments, and each claim stands independently as a separate embodiment, and it is assumed that such embodiments may be combined with each other in various combinations or substitutions. The scope of the invention should be determined by referring to the appended claims, along with the entire scope of the equivalent to which such claims are granted.

[0242] 8. Analytical Sensor System 10 Analytical Sensor 11 processors 12 Sensor Electronic Modules 13 Sensor Measurement Circuit 14 Storage 15 Connectivity Interfaces 16 transceivers 17. Real-time clock 103 Computer Devices 121 Analytical Sensor Applications 123 Storage 125 displays 126 processors 127 memory 128 connectivity interfaces 134 Server Systems 180 Communication Paths 181 Communication Path 183 Communication Path

Claims

1. A method for performing a diabetes device identification protocol between a sensor system for measuring blood glucose levels and a display device, The display device implements the diabetes device identification protocol for identifying the sensor system, In the aforementioned display device, To obtain the token ID of the aforementioned sensor system, Based on the aforementioned token ID, a first sensor system identifier is calculated, Receiving a second sensor system identifier from the aforementioned sensor system, To determine whether the first sensor system identifier and the second sensor system identifier are the same, Based on the determination that the first sensor system identifier and the second sensor system identifier are the same, it is identified that the sensor system is associated with the user of the display device, This includes implementing, In the aforementioned sensor system, with increased power compared to when the diabetes device identification protocol is implemented, analyte data indicating blood glucose levels is transmitted at predetermined time intervals to appropriately monitor glucose levels. In the aforementioned display device, in response to the identification, the device receives the analyte data from the sensor system, Methods that include...

2. The calculation of the first sensor system identifier is The token ID is hashed by performing a hash function, The method according to claim 1, comprising truncating a hash value by performing a truncation function, wherein the hash value is the first sensor system identifier.

3. The calculation of the first sensor system identifier is The truncation function is performed to truncate the aforementioned token ID and obtain the truncated token ID, The method according to claim 1, comprising hashing the truncated token ID by performing a hash function, wherein the hash value is the first sensor system identifier.

4. The method according to claim 1, wherein the display device is configured to communicate with the sensor system only when the signal received from the sensor system has a received signal strength that exceeds a threshold.

5. The method according to claim 1, further comprising reducing the transmission power when implementing the diabetes device identification protocol in each of the sensor system and the display device.

Images