A privacy-preserving remote heart rate monitoring system model and method

Abstract

The application discloses a privacy-protecting remote heart rate monitoring system model and method, which comprises a patient, a server and a hospital; the patient is connected with the server, the server is connected with the hospital, the server comprises a server CS1 and a server CS2; the patient transmits encrypted heart rate data to the server CS1, the server CS2 is connected with the patient through a distributed public key PK1, the server CS2 is connected with the hospital through the distributed public key PK1, the hospital transmits encrypted health indexes to the server CS1, and the hospital is connected with the server CS2 through a distributed public key PK2; real-time monitoring of the heart rate of the patient is realized, and in order to realize the privacy security of each link in the whole monitoring process, a privacy comparison protocol is proposed based on the double servers, and the query result is calculated by the two servers, so that the two servers cannot calculate the query result alone without collusion between the two servers, and the safety of the heart rate information of the patient is improved.

Description

Technical Field

[0001] This invention relates to the field of heart rate information, and in particular to a privacy-preserving remote heart rate monitoring system model and method. Background Technology

[0002] In telemedicine, doctors typically monitor patients' health based on physiological indicators, among which heart rate is a crucial physiological marker reflecting overall health. Generally, a healthy heart rate is within a reasonable range, such as 60-100 beats per minute. However, abnormal heart rates can lead to numerous potential health problems, including cardiovascular disease, stroke, and heart failure, with cardiovascular disease being the most serious. According to the World Health Organization, the mortality rate from cardiovascular disease remains high and is showing a trend towards affecting younger people, seriously threatening human life and health and imposing a significant economic burden on society and families. Furthermore, the insidious, sudden, and rapidly changing nature of cardiovascular disease makes it difficult for patients to receive timely treatment. Therefore, real-time heart rate monitoring is essential for both working professionals and the elderly.

[0003] Wearable devices are crucial tools for real-time monitoring in telemedicine. With wearable devices, telemedicine systems can monitor patients' heart rates in real time, promptly detecting abnormalities and enabling early diagnosis or preventative measures. However, smart wearable devices typically have limited storage and computing power, which may restrict their functionality and performance. Therefore, some existing solutions address this issue by uploading patient data to cloud servers to reduce power consumption and improve efficiency. However, cloud servers, as untrusted entities, can pose security risks to patient data privacy while processing heart rate information. While some existing solutions offer privacy protection for medical data, they often outsource data to a single cloud server, which offers less protection compared to dual-server systems. Furthermore, some existing solutions only ensure privacy of input data but not output data. Privacy leaks at any stage of the monitoring process can cause numerous problems. In medicine, patient information is highly sensitive; therefore, privacy protection in telemedicine urgently needs to be addressed.

[0004] Heart rate information is typically presented in plaintext, which poses a privacy risk for patients. Encryption is a good solution to this problem. Common methods for encrypting heart rate information include symmetric-key encryption algorithms (such as AES), asymmetric-key encryption algorithms (such as RSA), and elliptic curve cryptography algorithms (such as ECC). These algorithms can all be used to encrypt heart rate information, thereby protecting personal privacy. However, compared to homomorphic encryption, the main drawback of these methods is that they do not support computation in the ciphertext state. This means that if you want to perform calculations on encrypted heart rate data, you must first decrypt it, which may lead to security issues. In addition, these encryption methods may also have problems with key management and distribution, such as how to securely generate and distribute keys, and how to protect keys from being leaked.

[0005] To address the above issues, we propose a privacy-preserving remote heart rate monitoring system. This system employs homomorphic encryption to achieve real-time monitoring of patient heart rate data while protecting the privacy of hospital health indicators. Furthermore, to ensure privacy and security at every stage of the monitoring process, we propose a privacy comparison protocol based on dual servers. The query result is calculated collaboratively by both servers. Therefore, without collusion between the two servers, neither can calculate the query result independently, thus improving the security of patient heart rate information.

[0006] Technical solution of existing technology 1

[0007] Currently, common methods for encrypting heart rate information include symmetric-key encryption algorithms such as AES, asymmetric-key encryption algorithms such as RSA, and elliptic curve cryptography algorithms such as ECC. These algorithms can all be used to encrypt heart rate information, thereby protecting personal privacy.

[0008] Disadvantages of existing technology 1

[0009] To perform calculations on encrypted heart rate data, it must first be decrypted, which may lead to security issues. Furthermore, these encryption methods may also present problems with key management and distribution, such as how to securely generate and distribute keys, and how to protect keys from being leaked.

[0010] Technical solution of existing technology 2

[0011] Another way to process heart rate data is to outsource its management to a single server.

[0012] Disadvantages of existing technology 2

[0013] Compared to dual servers, a single server can only ensure the privacy of input data, but cannot ensure the privacy of output results. Its processing results for heart rate are more likely to be leaked, making it less secure than a dual server. Summary of the Invention

[0014] To address the problems existing in the prior art, this invention proposes a privacy-preserving remote heart rate monitoring system model and method. This method employs homomorphic encryption to achieve real-time monitoring of patient heart rate data while protecting the privacy of hospital health indicators. Furthermore, to ensure privacy and security at every stage of the monitoring process, this invention proposes a privacy comparison protocol based on dual servers. The query result is collaboratively calculated by both servers, so neither server can independently calculate the query result without collusion, thus improving the security of patient heart rate information.

[0015] A privacy-preserving remote heart rate monitoring system model includes a patient, a server, and a hospital. The patient connects to the server, and the server connects to the hospital. The server includes server CS1 and server CS2. The patient transmits encrypted heart rate data to server CS1. Server CS2 connects to the patient via a distributed public key PK1 and connects to the hospital via the same distributed public key PK1. The hospital transmits encrypted health indicators to server CS1 and connects to server CS2 via a distributed public key PK2. Server CS1 connects to server CS2 based on anomaly data calculations.

[0016] Preferably, a privacy-preserving remote heart rate monitoring method is characterized by comprising the following steps:

[0017] Step S1: Based on the system model, establish a security model;

[0018] Step S2: Based on the system model and security model, propose four design objectives;

[0019] Step S3: Based on the security model and design goals, propose a comparison protocol for privacy protection schemes;

[0020] Step S4: Based on the comparison protocol of privacy protection schemes, propose the details of the privacy protection scheme.

[0021] Preferably, the four design goals of step S2 include privacy protection, efficiency, accuracy, and resistance to replay attacks.

[0022] Preferably, the comparison protocol for privacy protection schemes in step S3 includes the following sub-steps:

[0023] Step S31: Convert the determination of whether the heart rate value is within the normal heart rate range into a comparison of the heart rate value with the upper and lower limits of the normal heart rate range;

[0024] Step S32: Cloud server CS1 includes E(A) and E(B). The PC protocol determines whether B < A and uses z i To express the comparison results without disclosing A, B, and z to any party. i A represents the patient's heart rate data, B represents the upper limit of the normal heart rate range, and z i The judgment result representing a single data point of the patient;

[0025] Step S33: If B < A, then z i =1 indicates that the patient's heart rate is abnormal; otherwise z i =0;

[0026] in Represents the XOR operation. The value indicates that it was generated by cloud server CS1, by p i The size determines, The value indicates that it was generated by the cloud server CS2, and is derived from θ. i The size is determined by.

[0027] Preferably, step S33 includes the following sub-steps:

[0028] Step S331: Cloud server CS1 generates a random number p i ∈{1, -1}, and perform difference operations on encrypted values ​​from patients and hospitals;

[0029]

[0030] If p i =-1, then on the contrary,

[0031] Where, E(θ) i E(B) represents the encrypted form of the result after multiplying the difference between health indicators and patient data by a random number; E(A) represents the encrypted form of the formal parameter B; E(Pi(BA)) represents the encrypted form of the result after multiplying the difference between B and A by a random number pi.

[0032] Step S332: Cloud server CS1 uses the hospital's PK2 against... Encrypt to obtain CS1 sends E(θ) i )and Give CS2, and CS2 uses sk1 to decrypt E(θ) i To recover θi And determine θ i The size of θ. i ≤0, otherwise,

[0033] Step S333: Cloud server CS2 uses the hospital's PK2 against... Encrypt to obtain The calculation formula is as follows:

[0034]

[0035] When pi = 1, if θ i ≤0, BA<0. In this case,

[0036] in, This indicates that the value is generated by CS1 and is determined by the size of pi. The value is generated by CS2, from θ. i The size of the data determines its size.

[0037] Preferably, step S4 includes the following sub-steps:

[0038] Step S41: Server and hospital initialization;

[0039] Step S42: Upload encrypted data;

[0040] Step S43: Calculate outlier data;

[0041] Step S44: Based on the abnormal data, return the query response and send it to the hospital.

[0042] Preferably, the server initialization calculation formula in step S41 is:

[0043] Server CS2 selects two large prime numbers p and q. Server CS2 calculates n = pq, g = n+1, and λ = (p-1, q-1). The function is defined as follows.

[0044]

[0045] L(X) represents the Euler totient function as defined in CS2;

[0046] Server CS2 is based on the formula μ=(L(g) λ mod n 2 )) -1 After calculating μ mod n, server CS2 will obtain the public key pk1 = (n, g) and the private key sk1 = (λ, μ). Server CS2 will publish the public key and keep the private key.

[0047] The calculation formula for hospital initialization is as follows:

[0048] The hospital selects two large prime numbers p′ and q′, calculates n′=p′q′, g′=n′+1, λ′=lcm(p′-1,q′-1), and defines the function as follows.

[0049]

[0050] L′(x) represents the Euler's totient function defined by the hospital.

[0051] The hospital uses the formula μ′=(L′(g′) λ′ mod n′ 2 )) -1 To calculate μ′ mod n′, the hospital will obtain the public key pk2=(n′,g′) and the private key sk2=(λ′,μ′). The hospital will issue the public key and keep the private key.

[0052] mod means modulo.

[0053] Preferably, the formula for calculating abnormal data is:

[0054] The formula for calculating abnormal data in step S43 is as follows:

[0055]

[0056] in, If the formula is true, the server continues to execute the cloud server computing algorithm; otherwise, it proves that the user data is not valid information and the ciphertext is discarded.

[0057] The beneficial effects of the privacy-preserving remote heart rate monitoring system model and method of the present invention are as follows:

[0058] 1. This invention achieves privacy and security at every step of the entire monitoring process by proposing a dual-server privacy comparison protocol (PC), which provides better protection for results than a single-server approach. In this protocol, the number of abnormal heart rates can be calculated, and this data can be used to monitor the patient's health status during this period. Because the results are calculated collaboratively by two servers, neither server can calculate the results independently without collusion, thus enhancing the security of the patient's heart rate information.

[0059] 2. This invention enables real-time monitoring of a patient's heart rate while utilizing homomorphic encryption technology to protect the privacy of patient heart rate data and hospital health indicators. This method overcomes the limitations of time and space, enabling patients to receive rapid diagnosis and treatment.

[0060] 3. Through detailed security analysis, this invention demonstrates that the solution effectively protects the privacy and security of patient heart rate data and hospital health indicators. Furthermore, the performance of the solution was analyzed, and the results show that this invention is effective and feasible. Attached Figure Description

[0061] Figure 1 This is a model diagram of the present invention. Detailed Implementation

[0062] The specific embodiments of the present invention are described below to enable those skilled in the art to understand the present invention. However, it should be understood that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the present invention as defined and determined by the appended claims. All inventions utilizing the concept of the present invention are protected.

[0063] System Model

[0064] like Figure 1 As shown, the system model of this invention mainly consists of the following three entities: patient (P), hospital (H), and cloud servers (CS1, CS2), as follows: Figure 1 As shown.

[0065] Patient (P): In our model, the patient collects their own heart rate data via a smart wearable device, encrypts it, and uploads it to CS1. Because the collected heart rate information is considered the patient's private information, it can only be disclosed to the patient themselves. The patient can only manage the heart rate data uploaded to the cloud server and cannot access the heart rate data of other patients. Therefore, the patient is the authorized user of their own heart rate information and an unauthorized user of the heart rate information of other patients.

[0066] Cloud Servers (CS1, CS2): We deployed two powerful cloud servers, CS1 and CS2, to jointly monitor patients' abnormal heart rate data. Specifically, CS1 stores encrypted heart rate data and hospital health indicators. With the assistance of CS2, it calculates the patient's heart rate status within a specific time period and returns it to the hospital.

[0067] Hospital (H): Hospitals are data providers for the normal heart rate range. Authorized hospitals can monitor patients' heart rate information in real time and provide timely medical assistance to patients.

[0068] Security Model

[0069] In our security model, both hospitals and patients are considered honest but curious. Specifically, they will faithfully follow the designed protocols, but hospitals may try to obtain patients' heart rate data, while patients may be curious about other patients' heart rate data.

[0070] Furthermore, since medical data and initiated query requests often involve sensitive personal information, the cloud servers CS1 and CS2 need to be kept confidential. Therefore, we assume that the cloud servers are honest but curious; that is, they will honestly follow the underlying scheme but may be curious about sensitive information, including medical data, normal heart rate ranges, and health status information. We also assume that the cloud servers do not collude with each other. This assumption is reasonable given the reputational loss resulting from collusion and is widely accepted in secure two-sided computation models. It is worth noting that, since our focus is on secure computation techniques, other proactive attacks, such as injection attacks, are beyond the scope of this paper and will be discussed in our future work.

[0071] Design Goals

[0072] Under the aforementioned system and security models, our design goal is to propose a privacy-preserving remote heart rate monitoring system. Specifically, it should achieve the following four objectives:

[0073] Privacy Protection: Throughout the remote monitoring process, we need to ensure security at every step, and heart rate data and normal heart rate ranges should be kept confidential from the cloud server. Furthermore, we need to protect the privacy of the access mode, meaning the cloud server should not know the patient's heart rate returned to the doctor.

[0074] Efficiency: Achieving the above privacy goals will incur additional communication overhead. Our goal is to achieve privacy-preserving conditions while also minimizing the computational costs for users, cloud servers, and querying users.

[0075] Accuracy: The accuracy of the monitoring results should be guaranteed. To provide high-quality remote heart rate anomaly monitoring services, the designed privacy protection strategy cannot sacrifice the accuracy of the monitoring results. Therefore, the proposed framework should also achieve a high accuracy rate.

[0076] Resisting replay attacks: This invention should be able to resist replay attacks by malicious users.

[0077] Proposed Privacy Comparison Protocol (PC)

[0078] We will transform the determination of whether a heart rate value is within the normal heart rate range into a comparison of the heart rate value with the upper and lower limits of the normal heart rate range. The comparison process and the proof of its correctness are as follows:

[0079] CS1 has E(A) and E(B). The PC protocol determines whether B < A and uses z. i To express the comparison results without disclosing A, B, and z to any party. i .

[0080] Let's take the comparison of a patient's heart rate data with the upper limit of the normal heart rate range as an example. Let A represent the patient's heart rate data and B represent the upper limit of the normal heart rate range. If B < A, then... i =1 indicates that the patient's heart rate is abnormal; otherwise z i =0, where This represents the XOR operation.

[0081] Therefore, the algorithm is invoked using PC(A, B), where A > B. The working principle and specific algorithm of the PC protocol are as follows:

[0082] Algorithm 1, also known as the privacy comparison protocol

[0083] Step 1: CS1 generates a random number p i Given the values ​​∈ {1, -1}, perform a difference operation on the encrypted values ​​from the patient and the hospital. The result is:

[0084]

[0085] If p i =-1, then on the contrary,

[0086] Step 2: CS1 uses the hospital's pk2 against Encrypt to obtain CS1 sends E(θ) i )and Give CS2, and CS2 uses sk1 to decrypt E(θ) i To recover θ i And determine θ i The size of θ. i ≤0, otherwise,

[0087] Step 3: CS2 uses the hospital's PK2 against... Encrypt to obtain Because CS2 has It can calculate:

[0088]

[0089] Correctness.

[0090] When p i When θ = 1, if θ i If ≤0, we have BA<0. In this case,

[0091] Let's take the comparison of a patient's heart rate data with the upper limit of the normal heart rate range as an example. Let A represent the patient's heart rate data and B represent the upper limit of the normal heart rate range. At this moment, the patient's heart rate is abnormal, and BA < 0 perfectly fits this situation. If θ i >0, This means BA > 0. The patient's heart rate is normal at this moment. In the same way, we can verify when p... i When the value is -1, the privacy comparison protocol is also correct. Similarly, the privacy comparison protocol also applies to cases where patient heart rate data is compared to the lower limit of the normal heart rate range.

[0092] Design Overview

[0093] This invention provides a privacy-preserving remote heart rate abnormality monitoring system method, which mainly includes: system initialization, encrypted data upload, abnormal data calculation, and returning a query response to the hospital.

[0094] Main architecture

[0095] Step 1: System Initialization

[0096] CS2 initialization: CS2 selects two large prime numbers p and q, then CS2 calculates n = pq, g = n + 1, λ = (p - 1, q - 1), and defines the function as follows.

[0097]

[0098] Then, CS2 is based on the formula μ=(L(g) λ mod n 2 )) -1 Calculate μ modulo n. CS2 will obtain the public key pk1 = (n, g) and the private key sk1 = (λ, μ). CS2 publishes the public key and keeps the private key secret.

[0099] Hospital initialization: The hospital chooses two large prime numbers p′ and q′. The hospital calculates n′=p′q′, g′=n′+1, λ′=lcm(p′-1, q′-1), and defines the function as follows.

[0100]

[0101] Then, the hospital used the formula μ′=(L′(g′) λ′ mod n′ 2 )) -1 The modulo operation is used to calculate μ′. (mod means modulo operation.) The hospital will obtain the public key pk2 = (n′, g′) and the private key sk2 = (λ′, μ′). The hospital publishes the public key and keeps the private key secret.

[0102] Step 2: Upload encrypted data

[0103] The hospital generates a normal heart rate range [t1, t2] and a heart rate value h that is unattainable by humans, encrypting them with the CS2-distributed public key pk1 to generate E(t1), E(t2), and E(h). The patient uploads data collected by the device, d = {d1, d2, d3, ..., d...}. l}, i∈[1,l], (Note: d is in numerical form), the patient encrypts each value in d to generate E(d i The data is then uploaded to CS1 along with the patient's generated timestamp T1.

[0104] Step 3: Anomaly Data Calculation

[0105] First, before processing the ciphertext from the patient, the server needs to determine whether the ciphertext is a valid message at the current moment. Therefore, the server generates the current timestamp T2 and calculates the difference between it and the patient's timestamp T1, using the following formula:

[0106]

[0107] The threshold is used. If the formula holds true, the server continues to execute Algorithm 2; otherwise, it proves that the user data is not valid information and the ciphertext is discarded. Note: Algorithm 1 is a greater-than-the-first algorithm, so when it is called, the first parameter should be greater than the second parameter.

[0108] Algorithm 2, i.e., cloud server computing method

[0109] Step 1: Server initialization E′(Z) = E′(0)

[0110] Step Two: The cloud server processes the patient's heart rate information. i i∈[1,1], call function PC(E(d) one by one. i E(t2)) yields E′(z) i )

[0111] Step 3: The cloud server processes the calculated E′(z) i The summation yields E′(Z), with the formula: E′(Z)=E′(Z)·E′(z) i )

[0112] Step 4: The cloud server processes the patient's heart rate information. i i∈[1,1], then call the function PC(E(hd) one by one. i ), E(h-t1))

[0113] We obtain E′(z) i ).

[0114] Step 5: The cloud server processes the calculated E′(z)i The summation yields E′(Z), with the formula: E′(Z)=E′(Z)·E′(z) i )

[0115] Step 6: The final result E′(Z) is obtained.

[0116] Step 4: Return the query response to the hospital

[0117] E′(Z) is sent to the hospital, which can decrypt it using sk2 to obtain Z. In this way, we can obtain the number of abnormal heart rate data points for patients over a period of time.

[0118] Table 1 shows the meaning of each parameter.

[0119]

[0120]

[0121] In addition to the method used in this invention, differential privacy can also be used to determine whether a patient's heart rate is normal while protecting the user's personal privacy and security, thus achieving the same inventive purpose.

[0122] This invention addresses the privacy and security issues of patient heart rate information and normal heart rate range using Paillier homomorphic encryption. To further enhance the security of the solution, ensuring privacy at every stage of the monitoring process, we employ a dual-cloud server-assisted computation model and propose a privacy comparison protocol (PC) based on this model. In this protocol, the determination of whether a heart rate value is within the normal heart rate range is transformed into a comparison of the heart rate value with the upper and lower limits of the normal heart rate range. Since the result is calculated collaboratively by two servers, neither server can calculate the result independently without collusion, which provides better privacy protection than a single server.

[0123] The points to be protected are: the patient's heart rate information, the patient's normal heart rate range, and the monitoring results returned to the hospital.

Claims

1. A privacy-preserving remote heart rate monitoring method, characterized in that, Includes the following steps: Step S1: Based on the system model, establish a security model; Step S2: Based on the system model and security model, propose four design objectives; Step S3: Based on the security model and design goals, propose a comparison protocol for privacy protection schemes; Step S4: Based on the comparison protocol of privacy protection schemes, propose the details of the privacy protection scheme; The four design goals of step S2 include privacy protection, efficiency, accuracy, and resistance to replay attacks; The comparison protocol for privacy protection schemes in step S3 includes the following sub-steps: Step S31: Convert the determination of whether the heart rate value is within the normal heart rate range into a comparison of the heart rate value with the upper and lower limits of the normal heart rate range; Step S32: Cloud server CS1 includes E(A) and E(B). The PC protocol determines whether B < A and uses z i To express the comparison results without disclosing A, B, and z to any party. i A represents the patient's heart rate data, B represents the upper limit of the normal heart rate range, and z i The judgment result representing a single data point of the patient; Step S33: If B < A, then z i =1 indicates that the patient's heart rate is abnormal; otherwise, z i =0; in , Represents the XOR operation. The value indicates that it was generated by cloud server CS1, by p i The size determines, The value indicates that it was generated by the cloud server CS2, and is derived from θ. i The size determines; Step S33 includes the following sub-steps: Step S331: Cloud server CS1 generates random numbers And perform difference operations on encrypted values ​​from patients and hospitals; , if , Where, E(θ) i The difference between health indicators and patient data is multiplied by a random number p. i The encrypted form of the result; E(B) represents the encrypted form of parameter B; E(A) represents the encrypted form of parameter A; E(p i (BA) represents the difference between B and A multiplied by a random number p. i The encrypted form of the final result; Step S332: Cloud server CS1 uses the hospital's PK2 against... Encrypt to obtain CS1 sends E(θ) i )and Give CS2, and CS2 uses sk1 to decrypt E(θ). i To restore θ i And determine θ i Size, if Step S333: Cloud server CS2 uses the hospital's PK2 against... Encrypt to obtain The calculation formula is as follows: , When p i When θ = 1, if θ i ≤0, BA<0, in this case, , in, This indicates that the value is generated by CS1, and by p i The size determines the data. The value is generated by CS2, from θ. i The size of the data determines its size.

2. The privacy-preserving remote heart rate monitoring method according to claim 1, characterized in that, Step S4 includes the following sub-steps: Step S41: Server and hospital initialization; Step S42: Upload encrypted data; Step S43: Calculate outlier data; Step S44: Based on the abnormal data, return the query response and send it to the hospital.

3. The privacy-preserving remote heart rate monitoring method according to claim 2, characterized in that, The server initialization calculation formula in step S41 is as follows: Server CS2 selects two large prime numbers p and q, and server CS2 calculates... Define the function as , L(x) represents the Euler totient function as defined in CS2; Server CS2 according to the formula After calculating μ, server CS2 will obtain the public key. and private key The CS2 server publishes the public key and keeps the private key secret. The calculation formula for hospital initialization is as follows: The hospital chose two large prime numbers. and Hospital calculation Define the function as , This represents the Euler's totient function as defined by the hospital. According to the formula, the hospital Calculate μ ， The hospital will obtain the public key. and private key The hospital publishes the public key and keeps the private key; mod means modulo.

4. The privacy-preserving remote heart rate monitoring method according to claim 3, characterized in that, The formula for calculating the abnormal data is: The formula for calculating abnormal data in step S43 is as follows: , in, The threshold is used. If the formula is true, the server continues to execute the cloud server calculation algorithm; otherwise, it proves that the user data is not valid information and the ciphertext is discarded. T1 is the timestamp generated by the patient and uploaded along with the encrypted heart rate data, and T2 is the current timestamp generated by the server before processing the encrypted heart rate data.

Images