### Background  
In E2 EA, the communication nodes of the IoT architecture are the gateway node (GWN), representing the healthcare service provider, the physician's monitoring device (Pi), the patient's smart device (SDj), and the nodes (SK) as illustrated in Figure 1. The Sk sensor nodes collect the patient's vital signs and send them as an on-demand report to the SDj; the Sk actuator nodes receive medical orders from the Pi through the SDj to perform a specific action such as turning on the insulin pumps [1; 2; 3; 4; 5; 6]. Communication between the SDj and Sk nodes is accomplished via the WMSN [1; 2; 3; 4; 5; 6; 12]. The SDj supports the registration process with the GWN and connects with a new sensor node. The SDj should be able to save the vital signs collected by specific sensor node, then forward them to the Pi indirectly through GWN or directly during emergencies. Communication between the SDj, GWN, and Pi is conducted over the Internet [1; 12; 13; 14; 15; 16]. The GWN is the core node of the E2 EA scheme because it supports registration with the Pi and SDj. The GWN observes the authentication and key agreement (AKA) execution to coordinate authentication between the Pi and SDj. The Pi can collect vital signs from the SDj and transmit medical orders to the actuator sensors for treatment through the SDj. Figure 1: Healthcare IoT system architecture of E2 EA. In E2 EA, authentication is exercised for every monitoring and treatment event between the GWN, Pi, SDj and Sk through three authentications phases: the long-term authentication phase (LAP), short-term authentication phase (SAP), and WMSN authentication phase (WAP) as shown in Figures 2-4, respectively. As shown in Figure 2, the LAP supports full mutual authentication, i.e., authentication of the Pi by the GWN and authentication of the GWN by the Pi through the exchange of authentication messages M1, M4 and M5. Furthermore, authentication of the GWN by the SDj and authentication of the SDj by the GWN through exchanging the authentication messages M2 and M3. Figure 4: WMSN authentication phase (WAP). Figure 3: Short-term authentication phase (SAP). Figure 2: Long-term authentication phase (LAP). The LAP performs a set of a symmetric cryptographic functions using the authentication keys that were generated during the registration phases of the [PERSON] and [PERSON] with the GWN. Besides, one-way hash functions are used to generate the verification values of the authentication parameters for all authentication messages. This phase also establishes a new subsequent key PSij generated by the GWN to be used when the [PERSON] and [PERSON] execute the SAP to authenticate each other directly. M1 is a request authentication message that the [PERSON] generates to prove itself to the GWN and has the values IDi, CTi0 and Vi0: IDi represents the [PERSON]'s identity; CTi0 is an encrypted value of the [PERSON]'s timestamp and a random number with the identity of the patient; and Vi0 is a hash value used on the GWN side to verify the CTi0 value. M4 is a response message that the GWN generates to prove itself to the Pi and has the values CTi1 and Vi1: CTi1 is an encryption of the concatenation value of the timestamp, random number, and PSij key that are generated by the GWN, and Vi1 is a hash value used on the Pi side to verify the CTi1 value. M5 is a confirmation message the Pi sends to the GWN to complete the mutual authentication. This message includes the hash value (Vx\(i\)), which is used as a confirmation value to the GWN. On the other side, M2 is a request authentication message that the GWN generates to prove itself to the SDj and has the values C0j, CTj0, and Vj0: C0j is an incremental counter of the authentication session; CTj0 is an encrypted value of the timestamp, random number, the PSij key of the GWN's; and Vj0 is a hash value used on the SDj side to verify the CTj0 value.