Abstract: This work focuses about the implementation of a secure data authentication model for the wireless body area network using the features of biological signals and the process of shared key establishment during the time of configuration. There is a need for a secure health monitoring system for Wireless body area network, but currently all the system engineered are working with complex key exchange system. Also the need for secure data exchange grows rapidly due the fact that the data exchanged are confined to the details of the ailing patient. A system that uses biometric details for security must also be able to provide a predictive outcome at the other end. The security system for health monitoring is proposed with low computational complexity for the secure transaction and with high power efficiency using key based cryptographic encryption technique. A system in place must ensure security with the use of limited amount of resources. This system also addresses the issues by considering the fact of limited availability of resources like power, bandwidth, thereby helping to achieve, more secure and time-efficient system in place for the effective health monitoring scheme.
Secure Data Authentication Model for Health Monitoring System
Description of the Project
Case 1: Design of Secure Data Authentication Model with the use of Biometric Data of the Patient:
The proposed Secure Authentication model (SAM) achieves confidentiality and authenticity with the help of the shared key that is distributed among both parties prior to the configuration. The accuracy which needs to be improved is achieved by comparing the message digest of Patient's Blood platelets count and the ECG of Patient from the warehouse of patients records (digest of the both) in the receiving end with that of the message obtained from the patient's wireless sensor node through their personal device. Though ECG is unique, the preprocessing technique applied may fail in likelihood estimation, where there is a chance for meaningful message to be discarded as malicious data received (in wireless body area network domain). Also, if biometric detail is alone used for authentication, then the entire message could be authenticated to be false and never would be rehashed to obtain the original message. But in the proposed model, the process of retrieval of Patient's medical data and the process of authentication are handled at different stages. The proposed solution act as a technique of applying the encryption technique, at a lower cost by just sharing a key prior to configuration with the use of biometric details of individuals, thus helping to achieve confidentiality and authenticity at a larger scale. Heart Rate Variability - which is recorded as ECG signals is having a unique characteristics and chaotic nature, which put up random characteristics, makes difficult for the hackers to predict its pattern, which is made use in secure communication. Heart Rate variability, is a physiological phenomenon where the time interval between heartbeats varies.
The heart beat varies in time interval, which analysis makes it useful for diagnosis of various cardiac-vascular diseases. Basically it has two components namely the sympathetic (Increase of Heart Beat) and parasympathetic (Decrease of Heart Beat). It satisfies the all requirements of the features that is absolutely necessary for all the biometric to be used as a tool for achieving authenticity, confidentiality and accuracy. It is universally available among all the individuals, being almost stable for years together until one is alive (Though pulse is distorted due to health ailments of individuals, still diacritical waves are observable) achieving permanency. It is also unique and could be collected with ease in real time. These properties of the ECG signals make it useful for its application in the domain of secure communication. The analysis of Heart Beat Rate is done through the time domain analysis of the ECG signals that are recorded in series of frequent time interval. This technique is proved to have reduced computational complexity and resources. The R peaks have the largest amplitudes and are easy to detect. Pre-processing of the RR interval time series is absolutely necessary to improve the accuracy of the R peak signal harnessed. Other Signals like Q, S and T are difficult to harness in presence of noise. The peak amplitudes are the R Signal of ECG.
Phases in the Proposed Model:
All the transactions in Secure Authentication Model happens only after the recognition of need for the medical data to be sent to the Health Care Unit (HCU) either during the case of emergency or during fixed time period check-up of the patient as recommended by the practitioner. There are usually two phases of transactions that happens before the patient's medical data could be received by the central Health Care monitoring Unit. It involves the three parameters to play a major role in both the sides, which are namely the ECG Signal, Stored (Previously recorded) Blood Platelets Count and the key Shared prior to the final transaction. There are three states that are being used to identify the course of transaction between the patient's Central Node or the Controlling Node (CN) controlling the entire sensor node planted in their body and the Central Server (CS) in the HCU. They are Transaction Accept State, Transaction Abort State and the Transaction Complete State. The phases that are incorporated in the proposed system are the Shared Key Establishment and the Medical Data Transfer.
Shared Key Establishment: The shared key establishment phase happens only for the first communication between the Central Node of the Patient and the Central server in the HCU. It then only happens after the key is expired as indicated by the Time to Live (TTL) field. The key expiry happens as instructed by the HCU officials, who determine the longevity of the key. The CN by looking into the TTL, once it receives determines the time period up to which it could be able to use the key. After that time period, the shared key establishment procedure is initiated by the CN. This procedure is illustrated in the Fig 2. Each CN is associated with a unique CNID, which could be used as the identification of the Controlling Node. The CNID is updated in the warehouse during the entry of a patient into the Online Health Monitoring System under specific Health Care Unit. The Sample ECG and the blood platelets count of the patient is collected during their registration for the Online health monitoring System and the Central Node is assigned an unique CNID. This CNID is utilized during the Shared Key Establishment phase. The patient's medical data obtained is not stored as it is in the Central Warehouse of CS. Both the ECG signal after proper preprocessing and the measured blood platelets count is hashed and their Digest is only allowed to be stored in the Central Warehouse of the CS. Also the CN that is being attached to the patient body is updated with the measured blood platelets count. The Control Node receives the data from the sensor nodes, which then initiates this phase by sending its Unique CNID with an Request for transmission (RF) message to the Central Server of the health care unit to which it is associated using the Personal Device Interface. Once the CS receives mis message from the CN node, it verifies its unique CNID, after the validation it generates the Shared Key that will be used for subsequent communication that whole day with a TTL field, hash it with the message digest and sends it to the Control Node. This message is called Clear for Transmission. Meanwhile in the CN, the senor nodes capture the ECG signals, pre-processes it based on the time domain and creates the digest of the ECG Signal and the stored blood platelets Count. When the CN receives the hash of the shared key and the digest (ECG Signal and the Blood Platelets count), it compares it with the digest it has created and retrieves the Shared key. It notes the time period up to which the key could be used with the help of TTL. The retrieval of the shared key brings the end of this phase.
Medical Data Transfer: The Medical data transfer is the patient's medical data transferred with authenticity, confidentiality being ensured and accuracy being at a higher level in the receivers end. The shared key obtained prior to the configuration in the key establishment phase is checked for its validity with help of TTL and the key is used for encryption of the message. The Digest of the Pre-processed recorded ECG signals and the Stored blood platelets count is hashed with the Patients medical data and the obtained digest at the second level is encrypted using the shared key and send as the medical data to the server node. Once the Shared Key for the particular CN node is generated, the key is stored until its expiry. There is a random key generator that assures no two CN shares a particular key. Once this message is obtained by the CS, then the key is used for decryption. If the decryption is impossible, then the message is discarded for the further usage. If authenticated, the confidentiality and the security is therefore ensured, the obtained digest is compared with the existing digest in the warehouse where the patient medical data is retrieved, similar to that of reverse hashing. Accuracy is achieved here as the recorded ECG signal may have been distorted due to pulse variation, but the hashing with the stored blood platelets value could be used as an additional advantage while applying comparison technique at the receiving end which would not discard the correct message. This is assured by using best likely occurrence of the match that could be assured with the help of hashing the value of stored blood platelets value along with even the distorted ECG signals. So the retrieved medical data could be sent to the practitioner's consultancy.
State Transfer: The process of state transfer in the Central Server happens after the three important processes - one the Request for Transmission reception, then the process of decryption and third the likely estimation process. All these states are helpful in the process of determining whether the transaction should be forwarded or aborted. The Request for transmission could make the CS for that particular session to enter into Transaction Accept State. The failure of the decryption would lead to the aborting of the further transaction and removal of shared key from the warehouse and corresponding intimation to the CN. The success of decryption leads transaction into Accept state wherein retrieval of the medical data after the likely estimation succeeds would lead to the Complete State of transaction. Thus the mismatch would again lead to the Abort state.
Failures Encountered in the Existing System:
The main failures associated with the current health monitoring system is that their failure in achieving accuracy along with authenticity, security at a lower cost of memory and computation. These systems could be utilized effectively for tele-medicine if all the above mentioned parameters are achieved at the expense of lower cost and memory utilization. The need for integration of biometric components for security is made essential. Also to ensure the authenticity at a higher level, a key is needed to encrypt this digest. At the same time, as key exchange could lead to high wastage of memory and power, key must be shared prior to configuration and should not be disclosed to public. Usage of different keys for different sensor nodes communicating with the central server is entertained.
Remedies to Failures Encountered:
The three main issues to be addressed in the secure authentication model are improving the accuracy in the reverse hashing - Comparison of the message digest obtained to extract the requisite patient medical data, improvisation in authenticity and confidentiality involved in the process. The authenticity involved is achieved by the use of the shared key concept, distributed prior to the configuration. Confidentiality is achieved with the encryption of the digest obtained by hashing the ECG signal and stored Blood platelets Count of the patient with the Patient's Medical data. All these processes does not need much higher computation power as most the information are obtained from the patient's body itself. Power form the battery of sensor nodes is sufficient for hashing and encryption as key exchange does not comes into the picture. The accuracy is also achieved by obtaining the digest of the ECG signals along with the Stored Patient's blood platelets and the patient's medical data.
The comparison done with reverse hashing done could be restricted in the receiving end by usage of only the corresponding entry of the digest with respect to the shared key used for the decryption process. Thus the major failures of security and accuracy addressed at an expense of lower power and memory consumption. The main advantage of these methods rest in the fact that the central warehouse (may be positioned at the Health care Units) contain only the hashed- message digest of the Patient's ECG Signal and the Blood platelets count estimated during the time of inception of the patient into online health monitoring system. So there is no data of the patient that is kept exposed even in the Central warehouse. The key is shared prior to the configuration i.e., prior to the need for medical assistance by the patient as indicated by the sensor node placed in the body of the patient, kept activated for that whole day using Time To Live Field (TTL) and thus complexity on key sharing for every time of the transaction is completely avoided.
Case 2: Design of Secure Data Authentication Model without the use of Biometric Data of the Patient:
The proposed Data Authentication Model (DAM) achieves confidentiality and audienticity with the help of the shared key that is distributed among both parties prior to the configuration. The shared private key is made unique by the process of its selection (16 digit secret key). The main aim is to achieve high degree of privacy of the shared key along with achieving the reduction in complexity for applying techniques that aims at achieving security. The entire process of the message transfer happens to be secure, authentic and confidential. The main data collected from the sensor nodes is hashed with the four digit of the unique CCN ID. Then the same is encrypted using the shared private key. Thus the obtained output from the central controlling node is the Message Authentication Code (MAC). This MAC is then decrypted using the same MAC in the receiving server and the comparison of the retrieved digest is performed with the stored hashed value of the health care unit's Unique CCN ID. The data is thus said to have transmitted securely over the network and received by the health care professional for further instant examination of the patient. The main advantage of this proposed DAM is that the key is no where shared and transmitted before communication and there is no need for sharing of the key each time prior to that of the message transfer.
Phases in the Proposed System:
All the transactions in DAM model happens only after the recognition of need for the medical data to be sent to the Health Care Unit (HCU) either during the case of emergency or during fixed time period check-up of the patient as recommended by the heath care unit professionals. There are usually two phases of transactions that happens before the patient's medical data could be received by the central Health Care monitoring Unit. It involves the three parameters to play a major role in both the sides, which are namely the predefined hashed Unique ID of the Central Coordinating node (CCN), Stored (Previously recorded) White Blood Platelets Count and the key Shared prior to the final transaction. There are three states that are being used to identify the course of transaction between the patient's Central Node or the Controlling Node (CN) controlling the entire sensor node planted in their body and the Central Server (CS) in the HCU. They are Transaction Sustain State, Transaction Reject State and the Transaction END State. The phases that are incorporated in the proposed system are the Shared Key Establishment and the Medical Data Transfer.
Shared Key Establishment: The shared key establishment phase happens prior to the configuration of the entire health monitoring system. It then only happens after the key is expired as indicated by the Time to Live (TTL) field. The key expiry happens as instructed by the HCU officials, who determine the longevity of the key. The CCN by looking into the TTL, once it receives determines the time period up to which it could be able to use the key. After that time period, the shared key establishment procedure is initiated by the Central Node (CCN). This procedure is illustrated in the Fig 7. Each CCN is associated with a unique CCNID, which could be used as the identification of the Controlling Node. The CCNID is updated in the warehouse during the entry of a patient into the Online Health Monitoring System under specific Health Care Unit. The sample white blood platelets count of the patient is collected during their registration for the online health monitoring System and the Central Node is assigned a unique CCNID. This CCNID is utilized during the Shared Key Establishment phase. The CCNID is hashed and stored in the warehouse for higher level of authenticity. Also the CCN that is being attached to the patient body is updated with the measured white blood platelets count. The Control Node or the Central Coordinating node receives the data from the sensor nodes, which then initiates this phase by sending its Unique CCNID with a Communication Request (CR) message to the Central Server of the health care unit to which it is associated using the Personal Device Interface. Once the CS receives this message from the CN node, it verifies its unique CCNID, after the validation it encrypts the same hashed CCNID using the Shared Key (Similar to signature) that will be used for subsequent communication and sends it to the Central Coordinating Node or the Control Node. This message is called Accept Transmission. When the CN receives the hash encrypted with the shared key it tries to decrypt and confirm that it is talking only to its legitimate central server. It notes the time period up to which the key could be used with the help of TTL. The both the authenticity of the CCN is achieved along with the confidentiality in the communication is achieved using the process of encryption with the shared key.
Medical Data Transfer: The Medical data transfer is the patient's medical data transferred with authenticity, confidentiality being ensured and accuracy being at a higher level in the receivers end. The shared key obtained prior to the configuration in the key establishment phase is checked for its validity with help of TTL and the key is used for encryption of the message. The hashed value of the CCNID is further hashed with the Patients medical data and the obtained digest at the second level is encrypted using the shared key and send as the medical data to the server node. Once the Shared Key for the particular CN node is generated, the key is stored until its expiry. There is a random key generator that assures no two CN shares a particular key. Once this message is obtained by the CS, then the key is used for decryption. If the decryption is impossible, then the message is discarded for the further usage. If authenticated, the confidentiality and the security is therefore ensured, the obtained digest is compared with the existing digest in the warehouse where the patient medical data is retrieved, similar to that of reverse hashing. This is assured by using best likely occurrence of the match that could be assured with the help of the stored hashed unique CCNID value. So the retrieved medical data could be sent to the practitioner's consultancy.
State Transition: The process of state transition in the Central Server happens after the three important processes - one the communication request reception, then the process of decryption and third the digest prediction process. All these states are helpful in the process of determining whether the transaction should sustain or get rejected. Continuous appearance of reject state of transition for a particular CCN would lead to the blocking of communication with that particular node with a suspect of that being malicious. The Communication request could make the Central Server for that particular session to enter into Transaction Sustain State. The failure of the decryption would lead to the rejecting of the further transaction and blockage of any further communication with that node with a corresponding intimation to that malicious node. The success of decryption leads transaction into Sustain state wherein retrieval of the medical data after the process of prediction succeeds would lead the same to the End State of transaction. Thus the mismatch would again lead to the reject state.
Key Generation: Each key is of twelve digits in total. The entire 16 digit key has three unique components. The first five digits represent the unique hospital code. The first two digits represent the province of a particular country to which the health care unit belongs to. The next three digits is a unique identifier to the particular health care unit. The next ten digits are divided into two categories of five each. The last five digit are randomly assigned in such a way that the randomly assigned digit seldom match within a particular health care unit. The rest five digits are the three digit white blood platelets count and the next two digits is the date of birth of the individual. This key is shifted 16 rounds to scramble all the digits. It is then hashed to obtain the final shared private key. This key expires with a certain TTL framework which is then refrained by a particular request from the Central Coordinating Nodes.
Remedies to Failures Encountered:
The main issues to be addressed are improving the accuracy - Comparison of the message digest obtained to extract the requisite patient medical data, improvisation in authenticity and confidentiality involved in the process. The authenticity involved is therefore achieved by the use of the shared key concept, distributed prior to the configuration. Confidentiality is achieved with the encryption of the digest obtained by hashing the Unique ID of the central coordinating server with the Patient's Medical data. Power form the battery of sensor nodes is sufficient for hashing and encryption as key exchange does not comes into the picture. The privacy is also maintained by the fact that the data is not just encrypted and communicated over the medium but hashed with the hashed value of the unique CCN. The comparison done with reverse hashing done could be restricted in the receiving end by usage of only the corresponding entry of the digest with respect to the shared key used for the decryption process. Thus the major failures of security and accuracy addressed at an expense of lower power and memory consumption. The main advantage of these methods rest in the fact that the central warehouse (may be positioned at the Health care Units) contains only the hashed unique ID of the CCN corresponding to its shared secret private key. So there is no data of the patient that is kept exposed even in the Central warehouse. The key is shared prior to the configuration i.e., prior to the need for medical assistance by the patient as indicated by the sensor node placed in the body of the patient, kept activated for a random Time To Live Field (TTL in years) and thus complexity on key sharing for every time of the transaction is completely avoided.
CLAIMS
1. We claim that our system provides a two tier Authentication that is implemented between the Patients' Data collecting Node and the Central Health Care Monitoring Server.
2. We claim that the authenticity involved is achieved by the use of the shared key concept, distributed prior to the configuration
3. We claim that the confidentiality is achieved with the encryption of the digest obtained by hashing the Unique ID of the central coordinating server with the Patient's Medical data
4. We claim that the privacy is also maintained by the fact that the data is not just encrypted and communicated over the medium but hashed with the unique value of Central Coordinating Node i.e., the central warehouse at the Health care Units contains only the hashed unique ID of the Central Coordinating Node corresponding to its shared secret private key.
5. We claim that the complexity on key sharing for every time of the transaction is completely avoided as the key is shared prior to the configuration i.e., prior to the need for medical assistance by the patient as indicated by the sensor node placed in the body of the patient, kept activated for a random Time To Live Field, thus also avoiding eavesdropping of the key.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | 3332-CHE-2013-US(14)-HearingNotice-(HearingDate-30-06-2021).pdf | 2021-10-17 |
| 1 | 3571-CHE-2013 ABSTRACT 26-07-2013.pdf | 2013-07-26 |
| 2 | 3332-CHE-2013 FORM-2 26-07-2013.pdf | 2013-07-26 |
| 2 | Abstract_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 3 | Amended Pages of Specification _Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 3 | 3332-CHE-2013 FORM-18 26-07-2013.pdf | 2013-07-26 |
| 4 | Claims_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 4 | 3332-CHE-2013 FORM-1 26-07-2013.pdf | 2013-07-26 |
| 5 | Correspondence by Applicant_Reply to Examination Report_20-08-2019.pdf | 2019-08-20 |
| 5 | 3332-CHE-2013 DRAWINGS 26-07-2013.pdf | 2013-07-26 |
| 6 | Drawing_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 6 | 3332-CHE-2013 DESCRIPTION (COMPLETE) 26-07-2013.pdf | 2013-07-26 |
| 7 | Form-2(Title Page)_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 7 | 3332-CHE-2013 CLAIMS 26-07-2013.pdf | 2013-07-26 |
| 8 | Form-3_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 9 | 3332-CHE-2013-FER.pdf | 2018-11-20 |
| 9 | Marked Up Copy_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 10 | Correspondence by Applicant_Request for Extension of Time_20-05-2019.pdf | 2019-05-20 |
| 11 | 3332-CHE-2013-FER.pdf | 2018-11-20 |
| 11 | Marked Up Copy_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 12 | Form-3_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 13 | 3332-CHE-2013 CLAIMS 26-07-2013.pdf | 2013-07-26 |
| 13 | Form-2(Title Page)_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 14 | 3332-CHE-2013 DESCRIPTION (COMPLETE) 26-07-2013.pdf | 2013-07-26 |
| 14 | Drawing_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 15 | 3332-CHE-2013 DRAWINGS 26-07-2013.pdf | 2013-07-26 |
| 15 | Correspondence by Applicant_Reply to Examination Report_20-08-2019.pdf | 2019-08-20 |
| 16 | 3332-CHE-2013 FORM-1 26-07-2013.pdf | 2013-07-26 |
| 16 | Claims_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 17 | 3332-CHE-2013 FORM-18 26-07-2013.pdf | 2013-07-26 |
| 17 | Amended Pages of Specification _Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 18 | 3332-CHE-2013 FORM-2 26-07-2013.pdf | 2013-07-26 |
| 18 | Abstract_Fer Reply_20-08-2019.pdf | 2019-08-20 |
| 19 | 3571-CHE-2013 ABSTRACT 26-07-2013.pdf | 2013-07-26 |
| 19 | 3332-CHE-2013-US(14)-HearingNotice-(HearingDate-30-06-2021).pdf | 2021-10-17 |
| 1 | searchAE_27-07-2020.pdf |
| 1 | Searchstrategy_08-06-2018.pdf |
| 2 | searchAE_27-07-2020.pdf |
| 2 | Searchstrategy_08-06-2018.pdf |