{'fraction_non_alphanumeric': 0.033411530532451834, 'fraction_numerical': 0.005864789933887823, 'mean_word_length': 4.679249091643117, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Freshness-Preserving Non-Interactive Hierarchical Key Agreement Protocol over WHMS

The digitization of patient health information (PHI) for wireless health monitoring systems (WHMSs) has brought many benefits and challenges for both patients and physicians. However, security, privacy and robustness have remained important challenges for WHMSs. Since the patient's PHI is sensitive and the communication channel, i.e., the Internet, is insecure, it is important to protect them against unauthorized entities, i.e., attackers. Otherwise, failure to do so will not only lead to the compromise of a patient's privacy, but will also put his/her life at risk. This paper proposes a freshness-preserving non-interactive hierarchical key agreement protocol (FNKAP) for WHMSs. The FNKAP is based on the concept of the non-interactive identity-based key agreement for communication efficiency. It achieves patient anonymity between a patient and physician, session key secrecy and resistance against various security attacks, especially including replay attacks.


Introduction
With an aging society, people are interested in health and desire to manage their healthy life by themselves. With the evolution of medical technology and information technology (IT) convergence, it is now possible for people to gather information on their health status anytime and anywhere easily using biometric information acquisition devices over wireless health monitoring systems (WHMSs) [1,2].

OPEN ACCESS
mobile ad hoc networks and tactical networks. However, their protocol could not be applied to wireless sensor networks (WSNs), due to the WSNs' uniqueness. Thereby, there are some research efforts on proposing hierarchical key agreement protocols in WSNs, including Lee et al. 's effort, which is a revised version of Guo et al.'s protocol for WSNs [20][21][22]. Lee et al.'s protocol is secure against the corruption of any number of nodes at any level in the hierarchy. However, their protocol could not be applied to the WHMS environment due to the WHMSs' unique properties and the different system requirements.
This paper proposes a secure and freshness-preserving non-interactive hierarchical key agreement protocol (FNKAP) for WHMS. The FNKAP is based on the IBC and the non-interactive identity-based key agreement for communication efficiency between any two entities in a WHMS. The FNKAP only requires one round of communication to establish a secure communication channel between any two entities in a WHMS. The FNKAP over a WHMS consists of three parties, including the patient with the WBAN, the u-Health server with the EHR database and the physician. It is based on the IBC to ensure the secure transmission, receiving, storing and access of the PHI. This could ensure the confidentiality of the PHI, which, in turn, is crucial for accurate diagnoses of a patient by his/her respective physician. The FNKAP inherits the advantages of the previous non-interactive key agreement protocols and removes the problems with them, which achieves patient anonymity between a patient and physician, session key secrecy and resistance against replay attacks. This paper is organized as follows. Section 2 reviews a WHMS configuration and basic security mechanisms. A new FNKAP is proposed over a WHMS in Section 3. Analyses, including correctness, security analysis, functionality and performance analyses, are provided in Section 4. Finally, Section 5 gives a brief conclusion.

Preliminaries
This section details the system architecture with the threat model in a WHMS and the mathematical background, which can be used as the basic difficulties of the FNKAP [18,[22][23][24].

WHMS Configuration and Threat Model
We consider a basic architecture, depicted in Figure 1, consisting of disparate devices and multiple access points. The main parties in our system are sensor nodes SNi, a gateway GWi and a back-end server, which are composed of a u-Health server SV with the EHR database and attending physicians PHi.
An at-home patient wears some wireless sensor devices SNi to read his/her blood pressure, electrocardiogram (ECG), etc., once per second. These readings are periodically communicated to a gateway, i.e., a smartphone or a smart watch, which may be incorporated with a utility to view the physiological readings, and the data stream is uploaded over the Internet to a centralized u-Health server SV. Authorized personnel PHi, such as doctors and nurses, accesses the database directly to diagnose and monitor patients. The data are also of interest to litigators for forensics, to investigate malpractice and assign liabilities. Our aim is to establish a secure channel by setting up a secure session key to cope with tampering throughout the WHMS network, while allowing it to be easily viewed by the legal entities. The WHMS usually consists of three tiers, as follows: -Tier 1 [SNi]: This is for sensor nodes, which are wearable or implantable devices placed on the patient's body. This is responsible for the sensing and transmitting of the PHI to the back-end u-Health server. -Tier 2 [GWi]: This is the gateway, which is the personal server, and this computer software that could be installed on a personal smart phone or smart watch. It is responsible for the collection of the PHI, as well as pretreatment and communication with the u-Health server SV or the attending physicians PHi. -Tier 3 [SV, PHi]: This is the back-end server, i.e., u-Health server, which has the role of private key generator (PKG) and has the EHR database located in the medical institution. It is mainly responsible for key setup, key management, data analysis, data management and data processing. It also includes attending physicians PHi, because PHi has a critical role for the patients in the WHMS via SV or EHR. The EHR is a database of medical data objects and health-related data managed by health professionals. The EHR is a subset of the electronic medical record maintained by each WHMS and is created and owned by the patient PAi. There are many threats to the WHMS. In the FNKAP, we assume that the u-Health server at Tier 3 is trustworthy. However, two communications are unsecure between SNi on Tier 1 and GWi on Tier 2 and between GWi and SV on Tier 3. The reasons are that SNi and GWi interact over wireless communication and GWi and SV transfer data over the public Internet. The FNKAP considers both active and passive threats for the WHMS. A passive threat involves an attack that attempts to gain access to information without affecting the communication; whereas an active threat attempts to change the communication that it is attacking. Some examples of each type of threat are the replay attack and modification attack. A replay attack captures information sent by an entity and later attempts to reuse (replay) that information in order to gain access to protected data. A modification attack changes the information included in messages being processed between two or more entities.
Furthermore, we consider privacy threats focused on anonymity and PHI data privacy against the insiders of the EHR [23]. Privacy is considered as information relating to an identified or identifiable individual. Privacy threats come in a number of forms, including threats to financial standing, reputation, solitude, autonomy and safety. Intrusion or interruption of an individual's life or activities can threaten the individual's ability to be left alone. Communications may be directed between the initiator and the recipient or additional entities may be involved in packet forwarding, which may interfere with privacy protection goals, as well. Although the additional entities may not generally be considered as attackers, they may all pose privacy threats, because they are able to observe and collect privacy-relevant data. From a privacy perspective, one important type of attacker is a passive attacker, who is an entity that passively observes the entity's communications without the entity's knowledge or authorization. Different kinds of attacks may be feasible at different points in the communications path. A passive attacker could mount surveillance or identification attacks between two communication participants.

Security Mechanisms
For the security mechanisms, including the bilinear map, Diffie-Hellman (DH) problem and non-interactive identity-based key agreement, we need to have some common assumptions as follows. Let G1 be an additive group of prime order q and G2 be a multiplicative cyclic group of the same order. In reality, G1 is a subgroup of points on an elliptic curve over Zq * , and G2 is a subgroup of the multiplicative group of a finite field * for some k ∈ Zq * . Let P denote a generator of G1.
-Computability: There exists an efficient algorithm to compute ê(P, Q) for any P, Q ∈ G1.

Diffie-Hellman Problem
There are two DH problems, bilinear DH (BDH) and computational DH (CDH). The BDH problem is to compute ê(P, P) a·b·c ∈ G2 given P ∈ G1 and elements a·P, b·P, c·P ∈ G1 for a, b, c ∈ Zq * . Computing such a problem is assumed to be hard on {G1, G2, ê}. The CDH problem is given as (P, a·P, b·P), and computing a·b·P is assumed to be hard.

Non-Interactive Identity-Based Key Agreement
For the non-interactive identity-based key agreement protocol, a central authority first generates two cyclic groups G1 and G2 and the bilinear map ê to setup the parameters for an IBC. The central authority also chooses a cryptographic collision-free hash function H(·):{0,1} * → G1. It then chooses a secret key s ∈ Zq * and computes a corresponding public key Ppub = s·P, where P is a generator of G1. Lastly, it publishes public parameters {G1, G2, ê, P, Ppub, H(·)}. For the registered party i, the central authority computes a private key Di = s·H(IDi) and sends it to him/her via a secure channel [18,22].

Freshness-Preserving Non-Interactive Hierarchical Key Agreement Protocol (FNKAP)
This section proposes a freshness-preserving non-interactive hierarchical key agreement protocol (FNKAP) for WHMSs. The FNKAP is based on the IBC to setup a secure channel between two entities, which is used for the secure communications over WHMSs. This ensures the security of the PHI, which, in turn, is crucial for accurate diagnoses of a patient by his/her respective physician. To achieve patient anonymity, we adopt pseudonyms, which are issued by the PKG to the patient upon successful registration via a secure channel. The FNKAP has three parties, namely the patient with WBAN, the u-Health server with the EHR database and the physician. It falls into three phases, a system initialization phase, physician and patient registration phase and non-interactive key agreement and secure communication phase. The first phase is for setting up the system, and the other two are to register participants, to establish a secure channel and to perform secure communications between the patient and the physician or any two parties in the hierarchy of a key tree in WHMSs.
We assume that all communications between the patient and the EHR, the EHR and the physician and the physician and the patient are carried out over an insecure channel, i.e., the Internet. In the FNKAP, the u-Health server plays the role of the registration server, system parameter generator or trusted authority and the authentication server. Furthermore, it is assumed that the network is formed in a hierarchy; one hop is considered between sensor nodes and a gateway node over the WBAN. We begin this section by discussing a permission hierarchy for the WHMS for the key setup and then detail the phases of the FNKAP.

Permission Hierarchy of WHMS
The FNKAP requires pre-established keys to secure WHMSs. Conceptually, the key setup for the FNKAP is based on a tree permission hierarchy, as shown in Figure 2. The tree is formed by considering permission level of entities of the WHMS, which are SV, PHi, GWi,j and SNi,j,d. The u-Health server performs the role of the PKG, which puts permission depending on their roles in a hierarchy. The most prominent entity is the u-Health server SV, which is classified as Tier 3 in Figure 2, but discrete permissions can be set at a much finer level. Note that the u-Health server could provide different permissions with the EHR depending on the system utilization. It is a natural way to implement a hierarchy, as in Figure 2, so as to reflect the role structure to show the line of authority and responsibility. Conventionally, more privilege is shown toward the top of the tree and less privilege toward the bottom. The privilege of the u-Health server contains the highest permission, which, in turn, contains the role of the others, PHi, GWi,j and SNi,j,d. Because of the transitive nature of permission hierarchies, PHi also contains the permission of GWi,j and SNi,j,d. Capabilities are granted to entities by their parents. Thus, SV grants capabilities to physicians PHi and PHi grant capabilities to patient PAi composed of GWi,j and SNi,j,d. Otherwise, The PKG could perform all roles for the granting of capabilities. The permission hierarchy, as shown in Figure 2, performs a very important role in the FNKAP in two ways that classify the capabilities of each entity in the hierarchy and could help one-round key establishment between two parties in the proposed protocol. Furthermore, note that most of the previous research assumed that the EHR collects the patient's PHI directly by establishing a secure channel between the EHR and the patient and keeps it for further use. After that, physicians log on to the EHR to access the PHI of patient. However, it is possible to expose the privacy data of a patient to the insiders of the EHR in that scenario. For example, in the absence of patient consent, an insider of the EHR may damage the patient's data and harm the patient for their own personal reasons. The FNKAP will cope with the problem by establishing a secure channel between the physician and the patient, not between the EHR and the patient. However, the patient needs to submit his/her PHI to the EHR, because it still needs to take the role of collecting and keeping the PHI from the patient. Thereby, only the legal physician with the proper permission could see the data in the EHR.

System Initialization
Similar to the other IBC-based protocols in [12][13][14] and the description in Section 2, the FNKAP requires a PKG for the system initialization [9]. Let k be the security parameter, G1 and G2 be two cyclic groups of prime order q and ê: G1 × G1 → G2 be a bilinear pairing. Let G1 * be the non-identity element set of G1. It is assumed that public keys, i.e., identities or amplified identities, at depth l are vectors of elements in (G1 * ) l . The j-th component corresponds to the identity at level j. The system later extends the construction to public keys over {0, 1} * by first hashing each component Ij using a collision-resistant hash H(·): {0,1} * → G1 * .
The u-Health server with identity IDSV creates a private key set (S1, S2, S3, S4) for a WHMS and computes an amplified identity ADSV = H(IDSV) and ADSV·S1. After that, SV stores the information in its memory. The notations used in the FNKAP are listed in Table 1.

Physician and Patient Registration
This phase is so that each participant has a pair of keys for the secure channel establishment based on the IBC. It is assumed that the physician PHi has a greater power compared to the patient PAi with a gateway node GWi,j and some sensor nodes SNi,j,d. The role of nodes in the hierarchy is pre-allocated before the phase. To allow identity revocation, SV could add a random number ri into ADi, such that each of the amplified identities is derived as ADi = H(IDi||ri). Figure 3 shows the established key after the system initialization phase and the registration phase for the FNKAP. Each node in the tree contains the bindings between the amplified identity and the secret key of the node and the old entities in its hierarchy.

Figure 3.
Hierarchical key setup for the freshness-preserving non-interactive hierarchical key agreement protocol (FNKAP).

Physician Registration
To register, a physician PHi submits his/her identity IDPHi to the u-Health server SV. SV first validates the received identity. If validation is successful, it computes ADPHi = H(IDPHi) and ADPHi·S2. After that, SV sends { (ADSV·S1, ADPHi·S2, S3, S4) and (ADSV, ADPHi)} to PHi via a secure channel, and PHi keeps the information in private, which is preferably stored in the smartcard of his/her identity card or the smart device.

Patient Registration
Patient registration is required for the subscription to the service from the WHMS, which needs to issue some sensor nodes and a gateway, depending on the physician's prescription for the patient PAi. Let PAi be a patient seeking medical help from PHi. Patient registration is only possible after PAi gets a proper prescription from PHi. To register, PAi submits his/her identity IDPAi, the attending physician's identity PHi, the prescription for the sensor nodes and a smart device to the u-Health server SV. The attending physician's identity could be omitted from PAi's registration if SV could set the relationship between PAi and PHi. SV first validates the received identities. Only if the validation is successful does SV check the prescription and set up some sensor nodes with a smart device. SV needs to issue a smart device if PAi does not have any smart device, which works as the role of a gateway GWi,j. SV computes ADGWi,j = H(IDGWi,j), ADGWi,j·S3, ADSNi,j,d = H (IDSNi,j,d) and

Non-Interactive Key Agreement and Secure Communication
The purpose of this phase is to establish a secure channel by setting up a fresh session key between the sensor node SNi,j,d of the patient PAi and the physician PHi in the WHMS. To establish a secure channel by using a fresh session key SNi,j,d, PHi conducts the following tasks: Step 1. SNi,j,d with its private key set (ADSV·S1, ADPHi·S2, ADGWi,j·S3, ADSNi,j,d·S4)  The above scenario assumed that the PHI of PAi is collected and sent to PHi by SNi,j,d, not by GWi,j. However, if GWi,j could have more powerful functionality, each entity on PAi could have a distinctive role, for which the sensor node only collects the PHI and sends it to the gateway, and the gateway communicates with the EHR after the collection and analysis of the PHI from the sensor nodes. In this scenario, we need to modify the steps of this phase focusing on GWi,j, which is skipped in this paper, due to the similarity with the following scenario.
If PHi needs to return back a report to PAi, PHi could send a secure message by using the similar steps as the communication with SNi,j,d. In this case, PHi needs to communicate with GWi,j on PAi, not via the u-Health server nor the EHR. For the process, PHi and GWi,j conduct the following further tasks: Step 3. PHi with the private key set (ADSV·S1, ADPH i ·S2, S3, S4) chooses a random number r2, computes R2 = r2·ADPH i and a fresh session key SK2 = ê(ADSV·S1, ADSV′)·ê(ADPH i ·S2, The FNKAP could support secure communication between any two entities in the hierarchy tree without requiring any pre-communication by establishing a fresh session key in them. Furthermore, it could provide convenience to the patient, because he/she could know his/her health condition anywhere and anytime by directly communicating with his/her attending physician.

Analysis
This section provides the correctness of the FNKAP and provides the security analysis on it. Furthermore, we provide the functionality and the performance analyses by comparing the FNKAP with the related protocols in [10,16,22].

Correctness
Here, we verify the correctness of the session keys of SK1 and SK1′ and SK2 and SK2′ based on the properties on the bilinear map described in Section 2. First of all, SK1 and SK1′ are consistent as follows:

Security Analysis
Although it is important to provide a formal security proof on any cryptographic protocol, the formal security proof of protocols remains one of the most challenging issues for cryptography research. Until now, a simple, efficient and convincing formal methodology for correctness analysis on security protocols is still an important subject of research and an open problem. Because of these reasons, most protocols have been demonstrated with a simple proof. This section follows the security analysis approaches used in [27]. The security analysis is focused on verifying the overall security requirements for the FNKAP, including passive and active attacks, as follows.

Proposition 1. The FNKAP provides entity anonymity.
Proof: In the FNKAP, the anonymity of the entity is obtained by applying the hash function and is based on the BDH problem. Two phases in the FNKAP, the registration phase and the non-interactive key agreement and secure communication phase, use amplified identities by using the one-way hash function. The u-Health server only gets the real identity of each entity. There is no way for an attacker to know the real identity, even if the attacker could capture the messages {R1, M1, ADSN i,j,d , MAC1} and {R2, M2, ADGW i,j ′, MAC2} during the protocol run of the FNKAP.

Proposition 2. The FNKAP cannot reveal the private key set or the generated session key to outsiders.
Proof: The security of the private key set is based on the combinations of the amplified identities and the secret values. This indicates that an attacker has to know both of them to retrieve the private key set. However, there is no way that the attacker could derive the secret values or the amplified identities from the private key set due to the BDH and the CDH problems. For the concern of revealing the session key SK, the attacker needs to have power to analyze and get necessary information from the intercepted messages {R1, M1, ADSN i,j,d , MAC1} and {R2, M2, ADGWi,j′, MAC2}. However, there is no way that the attacker could know the session key due to the BDH and the CDH problems.

Proposition 3. The FNKAP provides session key freshness and thereby can prevent from the replay attack.
Proof: The random number ri used to establish the session key in the non-interactive key agreement and secure communication phase guarantees the freshness of the session key. There is no way that an attacker could get any information to know the session key due to the BDH problem. Furthermore, the FNKAP is strong against the replay attack due to the session key freshness support with MACi in each message.

Proposition 4. The FNKAP is secure against passive attack.
Proof: We assume that an attacker is successful if the attacker knows any useful information from the intercepted messages. We show that the probability of success for learning them is negligible due to the difficulty of the underlying mathematical problems, the BDH and the CDH problems. Finally, we could say that the FNKAP is secure against passive attack.

Proposition 5.
The FNKAP is secure against active attack.
Proof: We could argue that an attack from an attacker is successful if the attacker finds the session key SKi or knows any of the messages M1 and M2. Therefore, we will show that the probability of the success of finding them is negligible due to the difficulty of the BDH and the CDH problems.
-The acceptance by all entities means that each MACi in the corresponding message is successfully verified. This means that MACi is verified successfully by using the correct session key SKi. If it is the case that entities accept the messages and they continue the session, the probability that the attacker could modify the messages is negligible. Additionally, the only way for the attacker to find the session key or the private key information is to solve the difficulty of the underlying mathematical problems, the BDH and the CDH problems. -Now, we consider the active attacker with the following cases.
(1) There is no way that an attacker could get the private key set related to {S1, S2, S3, S4} due to the difficulty of the BDH and the CDH problems. (2) An attacker cannot masquerade as SNi,j,d nor GWi,j to cheat PHi. This is mainly because the attacker cannot generate valid messages without deriving the correct session key SKi. Furthermore, the attacker could not compute the proper MACi, which is required for the verification of the session for the counter party. (3) An attacker cannot impersonate PHi to cheat SNi,j,d nor GWi,j. Only the legal physician PHi could form the legal messages, which need to be properly matched with the information from the counter party in the protocol run. Even if the attacker could pass the verifications at the protocol steps, the attacker still cannot get any useful information from M1 and M2, due to the difficulty of the underlying mathematical problems, and cannot generate the consequent valid messages.
Finally, we could say that the FNKAP is secure against active attack.

Functionality and Performance Analyses
This sub-section evaluates the functionality and the performance of the FNKAP and provides comparisons with the FNKAP and the related works of Huang et al., in [10], Mtonga in [16] and Lee et al.,in [22], as shown in Tables 2 and 3. We only consider the key agreement from both of Huang et al.'s schemes and Mtonga's scheme, even if they provide some other security functions.
For the functionality analysis, we consider the freshness of the session key, the privacy only focused on the anonymity, the integrity of transmitted data and the network environment of the protocols.   As shown in Table 3, the performance of the key agreement protocol can be approximated in terms of the communicational loads, the space and computation overheads. The number of rounds is considered as a factor for the communicational load. The communication overhead of Huang et al.'s scheme is mentioned as '-', because it does not provide the session key agreement. Except for Huang et al.'s scheme, all of the other three protocols share this property, because they share the basic mathematical operation for the key agreement.
For the space and computation loads, we consider the memory requirements and the number of basic operations, including the hash function, the public-key operation, the scalar multiplication and the pairing operation. The key agreement protocol demands extra space to keep the required keys and additional information to set up a secure channel. The space and computation overheads are related to the size of the private key set. An entity in the hierarchy tree needs to store a key set of {S1, S2, S3, S4} with an amplified identity set {ADSV, ADPH i , ADGW i,j , ADSN i,j,d }. The size of the key set and the amplified identity in Huang et al.'s scheme and Mtonga's scheme do not depend on the size of network entities, but depend on two communication entities. However, the FNKAP and Lee et al.'s protocol depend on the height of the hierarchical tree. The FNKAP requires a little bit more computational overhead than Lee et al.'s, which is for the WHMS, and requires some additional entities for the WSN.

Conclusions
In this paper, we have proposed a secure and freshness-preserving non-interactive hierarchical key agreement protocol (FNKAP) for the WHMS. The FNKAP is based on the bilinear paring, the IBC and the non-interactive key agreement. To propose a communication-efficient protocol, we proposed a permission hierarchical tree for WHMSs with the consideration of the network requirements. In the FNKAP, each entity in the WHMS is only pseudonymously identified, hence protecting the entity from the negative effects of identity theft, such as fraudulent insurance claims by attackers. The FNKAP allows the patient and his/her physician to establish a secure channel via a session key, which only requires one-round communication and does not require any further interactive communications. The analyses have shown that the FNKAP achieves good security properties and functionalities. However, the performance comparison has shown that the FNKAP has a bit more overhead than the other protocols, due to the support of the required features for the WHMS.