Lightweighted and energy-aware MIKEY-Ticket for e-health applications in the context of internet of things

: To secure e-health communications, key management protocols play a vital role in the security process. Nevertheless, current e-health systems are unable to run existing standardised key managementprotocolsduetotheirlimitedenergypowerandcomputationalcapabilities.Inthispaper, weintroducetwosolutionstotailorMIKEY-Ticketprotocoltoasuchconstrainedenvironment. Firstly,weproposeanewheadercompressionschemetoreducethesizeofMIKEY’sheaderfrom 12Bytesto3Bytesinthebestcompressioncase.Secondly,wepresentanewexchangemodeto reducethenumberofexchangedmessagesfrom6to4.Weuseaformalvalidationtooltoevaluate andvalidatethesecuritypropertiesofourtailoredMIKEY-Ticketprotocol.Inaddition,weevaluate bothcommunicationandcomputationalcoststodemonstratetheenergygain.Theresultsshow adecreaseinMIKEY-Ticketoverheadandaconsiderableenergygainwithoutcompromisingits securityproperties.


Introduction
Internet of things (IoT) is one of the main communication development in the last decade.According to Atzori et al. (2010), the basic concept behind the IoT is the pervasive presence of various wireless technologies such as radiofrequency identification (RFID) tags, sensors, actuators or mobile phones in which computing and communication systems are seamlessly embedded.Through unique addressing schemes, these objects interact with each other and cooperate to achieve common tasks.
Technology advances along with increasing demand will foster a widespread deployment of IoT's services, which would radically transform our corporations, communities and personal spheres.From the perspective of a private user, IoT's introduction will play a leading role in several services.E-health is seen as one of the most interesting applications as it will provide medical monitoring to millions of elderly and disabled patients while preserving their autonomy and comfort.By using body sensors, physiological data is gathered and transmitted to qualified medical staff that can intervene in the case of emergency.Nevertheless, e-health applications are unlikely to fulfil a widespread deployment until they provide strong security foundations.Securing communications in e-health applications necessarily passes through key management protocols that distribute security credentials between involved entities.However, the lack of energy power and computational capabilities in such kind of environment hinder the deployment of classic developed security solutions.
MIKEY-Ticket (Mattsson and Tian, 2011) is a key management protocol characterised by its simplicity and adaptation to centralised architectures.In fact, these architectures are interesting to be considered for resource constrained environments, as there is no need to predistribute credentials.By using these kinds of architectures, users can request security credentials only when required.Centralised solutions also scale well when the number of users grows.Additionally, MIKEY-Ticket specifies different message exchanges that can be transported over UDP and integrated within several security protocols (e.g., IPSEC, DTLS, HIP).
MIKEY-Ticket needs to be tailored for constrained environments in order to adapt to resources constraints of such environments.To this end, we introduce two solutions to tailor MIKEY-Ticket to e-health environments without weakening its security properties.In the first solution, we propose a new 6LoWPAN (IPv6 over low-power wireless personal area networks) header compression scheme for MIKEY-Ticket.Our scheme is intended to save energy and avoid 6LoWPAN fragmentation that may occur when a datagram size exceeds the link layer (maximum transmission unit (MTU) of the IEEE 802.15.4 protocol).Indeed, fragmentation is undesirable, as 6LoWPAN is vulnerable to fragmentation attacks (Hummen et al., 2013b).In the second solution, we propose a new exchange mode to reduce the number of exchanged messages from 6 to 4. The main concern being to reduce the involvement of the constrained nodes in the exchange process.
To assess our proposed adjusted MIKEY-Ticket protocol with respect to its security properties and energy savings, we have proceeded with a theoretical analysis that we have further formally validated through an implementation in Avispa tool (http://www.avispa-project.org).In addition, based on energy models that consider both communication and computational costs, we have estimated the energy savings at the constrained nodes side.Our results show a progressive gain of energy cost according to the compression rate level while preserving the MIKEY-Ticket security properties.
The rest of this paper is organised as follows.In Section 2, e-health applications in the context of IoT are briefly introduced along with the main security threats that might limit their deployment.Thereafter, we provide in Section 3 an overview of the state-of-the-art of the proposed security approaches.In Section 4, we introduce the motivations behind our choice of MIKEY-Ticket over other existing protocols.Furthermore, for a proper understanding of our contribution, we also present the different technologies used.We outline our network scenario in Section 5.In Section 6, we describe in detail how we have adjusted MIKEY-Ticket.Both security and quantitative analysis of our contribution are provided in Section 7. Finally, Section 8 concludes the paper and gives future directions.

E-health applications in the context of internet of things
Internet of things deployment will open doors to a huge number of applications that would deeply improve our daily life.E-health applications are one of the typical applications that are gaining more and more attention (Atzori et al., 2010).An e-health system is defined as a radio-frequency-based wireless networking technology that provides ubiquitous networking functionalities.It is based on the interconnection of tiny nodes enhanced with sensing and/or actuating capabilities planted, or placed around the human body.
E-health applications are context-aware, personal, dynamic and anticipative by nature.As IoT is designed to meet these key characteristics, it provides a natural and suitable environment for their efficient deployment.In fact, an extensive research study on using IoT paradigm in e-health has recently been reported (Istepanian et al., 2010).Population ageing and the increase of survival chances from disabling accidents and illnesses will lead to an increased demand from today's population that requires a continuous healthcare and monitoring (Dohr et al., 2010).E-health applications could spare a patient from being admitted in hospitals for a long period of time.Reducing the number of nights that a patient may spend in a hospital and the associated risks that may result is a key area of focus for the medical community.Additionally, a continuous monitoring capability, if available, can anticipate the need for an emergency intervention.Moreover, early stage diagnostics could also be achieved remotely (Patel and Wang, 2010).In brief, e-health applications in the context of IoT constitute a cost-effective and unobtrusive solution that is of the best interest of today's patients.Nevertheless, e-health applications are seriously challenged by many security threats that limit their large scale deployment.
Studies in Li and Lou (2010), Javadi and Razzaque (2013), Lim et al. (2010) and Ng et al. (2006) have underlined that e-health applications might be more vulnerable to attacks compared to other IoT applications as the generated data is highly sensitive and private.The health-related records are always private in nature, and any security breach in the confidentiality of such data would seriously repulse patients from adopting e-health solutions.For instance, many people would not like their personal health information, such as early stage of pregnancy or details of certain medical conditions, be divulged to third parties (Ameen et al., 2012).In fact, the eavesdropped communications could be used for several illegal purposes.Moreover, any eventual modification of health-related captured data could lead to disastrous consequences as it could engender wrong medical prescription or delay an emergency intervention.
Classical countermeasures are not suitable to the constrained environment of IoT due to several factors such as power and computation limitations, the weak reliability of wireless links and the scalability issue.Thus, a considerable effort has been made by the research community to provide viable solutions to secure IoT applications.The next section provides an in-depth overview of the state-of-the-art of the proposed security approaches and explains the motivations behind our contribution.

Related work
The research community attempted to propose security protocols that take into consideration the constrained resources of IoT.In this context, we distinguish two distinct research directions: • specific solutions for e-health applications • the tailoring of standard security protocols for the IP-based IoT.
Several specific solutions for e-health applications have been proposed in the literature.For instance, hardware solutions are proposed to deal with the scarcity of resources (Healy et al., 2008;Meingast et al., 2006).However, these approaches still present some drawbacks as they do not offer advanced encryption standard (AES) decryption (only base stations can decrypt the transmitted data).In addition, they are highly platform-dependant and not all the nodes are equipped with hardware encryption capabilities.Besides, TinySec is part of the official TinyOS release that aims to achieve linklayer encryption and authentication of data in biomedical sensors (Karlof et al., 2004).This protocol is based on a single key shared among nodes which constitutes its main weakness as node capture would give access to the entire network.A different approach based on biometric techniques is therefore proposed (Cherukuri et al., 2003;Poon et al., 2006).These techniques use the human body to manage the key establishment process based on physiological values (e.g., electrocardiogram).
A different but complementary research direction has seen several interesting approaches that aim to tailor security protocols for the IP-based IoT.The main focus of these works is to make standard based security protocols suitable for constrained IoT environments.In particular, several compression schemes for the IP-based IoT have been proposed.The compression of IPv6 headers, extension headers along with user datagram protocol (UDP) headers has been standardised through the 6LoWPAN adaptation layer in Montenegro et al. (2007) and Hui and Thubert (2011).Moreover, authors in Granjal et al. (2010) and Raza et al. (2011) have presented 6LoWPAN based compression techniques for IPsec payload headers: authentication header (AH) and encapsulating security payload (ESP), that have been later standardised in Raza et al. (2013a).Besides, an internet key exchange (IKE) compression scheme has been also proposed in order to provide a lightweight automatic way to establish security associations for IPsec (Raza et al., 2012b).Likewise, header compression layers for datagram transport layer security (DTLS) and host identity protocol diet Exchange (HIP DEX) were respectively introduced in Raza et al. (2012a) and Hummen et al. (2013a).
Apart from packet compression schemes, several delegation procedures of protocol's primitives have been proposed to offload the computational load to third entities.Saied and Olivereau (2012a), Saied and Olivreau (2012) and Saied and Olivereau (2012b) have introduced collaboration for HIP (Host Identity Protocol).The idea is to take advantage of more powerful nodes in the neighbourhood of a constrained node to carry heavy computations in a distributed way.Likewise, IKE session establishment delegation to the gateway have been proposed in Bonetto et al. (2012).Furthermore, authors in Freeman et al. (2007) have introduced a delegation procedure that enables a client to delegate the certificate validation process to a third party.While delegation approaches reduce the computational load at the constrained node, they introduce the use of a trusted third party.As a result, the end to end property is no longer ensured with respect to protocols, which initially were designed to ensure it.Further design improvement approaches have been introduced to tailor end-to-end security protocols to IoT.For example, authors in Hummen et al. (2013c) have proposed complementary lightweight extensions to HIP DEX that could be generalised to DTLS and IKE.Following the same way, Hummen et al. (2013d) have introduced design ideas to reduce the overhead of the DTLS handshake where their primary goal was to make the use of certificates for authentication purposes viable in IoT contexts.Besides, Boudguiga et al. (2013) have proposed an approach to mitigate the DoS attack in MIKEY-Ticket.
We do believe that securing IoT applications will be achieved through tailoring current security protocols to IoT environments rather than developing new specific solutions.To the best of our knowledge, no prior solutions have been proposed to tailor the MIKEY-Ticket protocol to the constrained IoT environment.

MIKEY-Ticket choice
In this subsection, we focus on the motivations that are behind our choice of MIKEY-Ticket over other existing protocols, particularly IKE.This latter is a key exchange protocol that aims to perform mutual authentication and to provide security associations (SAs) to be used as input for IPsec.Indeed, securing IoT communications at the IP level is likely to be achieved through the use of IPsec (Keoh et al., 2014).In this way, MIKEY-Ticket aims to achieve the same goal.In our study, we have focused on MIKEY-Ticket instead of the widely adopted IKE.The reasons behind this choice are the following.
• The proposed e-health constrained scenario involves the use of tiny nodes that are highly limited by their computational capabilities.In fact, during its first request/response exchange process (i.e., IKE_SA_INIT), IKE involves the two parties in a Diffie-Hellman instantiation phase, which requires an important energy consumption due to exponential operations.Indeed, Public key operations are not suitable for highly constrained environments.Besides, the Pre-Shared mode of MIKEY-Ticket only involves symmetric operations, which are much more energy saving compared to asymmetric approaches (Wander et al., 2005).Furthermore, Mikey-Ticket is designed to involve a central trusted entity which makes it more suitable to our network scenario compared to IKE.The trusted entity has a double role to play.Firstly, it acts as a gateway (i.e., 6LoWPAN Border Router) through which 6loWPAN headers are compressed and decompressed.Secondly, it spares the constrained node from using public key cryptography by generating and distributing the required security credentials.
• MIKEY-Ticket is a product of the IETF such as IKE (Kaufman et al., 2010), DTLS(E.Rescorla, 2011) and other standard based protocols.In fact, our approach to address data confidentiality in IoT's applications aims to propose new extensions to standardised protocols in order to adapt them to the IoT context.Following this approach, MIKEY-Ticket sounds to be the adequate protocol that can be extended to ensure secure communications in IoT.
• A lot of efforts have been carried out by the research community to optimise the IKE protocol.As IoT is only in its first stages of deployment, the protocol suite that should be implemented to secure IoT-based applications is not clear yet.Our research effort attempts, therefore, to bring a contribution in this process of adapting and selecting existing protocols for IoT environments.

MIKEY-Ticket overview
MIKEY-Ticket (Mattsson and Tian, 2011) is a key distribution protocol designed to enhance the multimedia internet keying protocol (MIKEY) (Arkko et al., 2004).It defines new modes of key distribution which are well adapted to centralised based scenarios where a third trusted entity is available.MIKEY-Ticket considers two entities that aim to establish a shared secret.One of the two entities assumes the initiator role whereas the second one assumes the responder role.
The key establishment relies on a key management server to generate and deliver the needed credentials.Such design spares the peers from a pre-distribution phase that would require credentials storing.Instead, peers can request such credentials only when required.In this work, we only consider the pre-shared key mode (PSK) of MIKEY-Ticket as the public key (PK) mode and the Diffie-Hellman key exchange mode are ruled out due to their inadequacy with IoT constrained environments.We provide a brief description of MIKEY-Ticket message exchanges and the general MIKEY header (HDR) format.Table 1 summarises the used notations.

Message exchanges
MIKEY-Ticket uses six messages to establish a new key between the initiator I and the responder R (see Figure 1).The protocol relies on the key management server (KMS) which delivers the generated key.The Initiator and the Responder do not share any credentials.Instead, they share a secret master key with the KMS.This key is used to derive an authentication key and an encryption key.The generated keys are used to secure the communication between I and R whereas KMS provides data authenticity, data integrity and confidentiality.
We briefly describe the content of each exchanged message of the full three round-trip MIKEY-Ticket mode: REQUEST_INIT : Through this message, node I expresses its willingness to establish a shared key with node R. The message contains information about the responder's identity.To ensure authenticity, a message authentication code (MAC), which is computed with aK I,KMS , is included.
REQUEST_RESP: After successful verification, the request is authorised and the KMS generates the requested key K and encodes it in a ticket.The message is sent to I.
TRANSFER_INIT : Upon reception of REQUEST_RESP message, node I derives an authentication key aK and an encryption key eK to secure data transmission between I and R.Then, node I transfers the ticket to R through TRANSFER_INIT message.Also, a MAC is computed using aK and included in the message.
RESOLVE_INIT : through this message, node R asks the KMS to return the key K encoded in the ticket.The message is protected by a MAC based on aK KM S,R .
RESOLVE_RESP: if node R is authorised to receive the generated key encoded in the ticket, the KMS sends RESOLVE_RESP message that includes the generated key K.The message is protected through encryption and a MAC message based on aK KM S,R .
TRANSFER_RESP: R is in possession of the generated key K. TRANSFER_INIT's MAC can thus be checked.The exchange is concluded through TRANSFER_RESP message to prove the correct reception and derivation of the generated session key.
It is worth noticing that the different messages contain a nonce for protection against replay attacks.
Figure 1 depicts the signalling for the full three roundtrip MIKEY-Ticket mode.Nevertheless, RFC 6043 (Mattsson and Tian, 2011) introduces four different modes according to the specificities of both the Initiator and the Responder.Mode 1 represents actually the full three round-trip mode where only the KMS is in charge of generating, deriving and distributing the keying materials.Both I and R have to request/resolve messages with the KMS.In mode 2, the exchanges between the KMS and R are omitted (i.e., RESOLVE_INIT and RESOLVE_RESP ).However, R has to be able to resolve the ticket without assistance from the KMS.In mode 3, the ticket request exchange (i.e., REQUEST_INIT and REQUEST_RESP) can be omitted if I is able to create the keying materials without an assistance from KMS. Mode 4 only contains a ticket transfer exchange (i.e., TRANSFER_INIT ).However, it requires from I and R to share security credentials prior to the start of the protocol session.

Common header format (HDR)
The common header payload (see Figure 2) contains information about the different exchanged messages.It is always present as the first payload in each message.In the following, we present a succinct description of each field contained in the Mikey_Ticket header.We refer to RFC3038 (Arkko et al., 2004) and RFC6043 (Mattsson and Tian, 2011) for a more detailed description: • Version (8 bits): Version of Mikey.
• Data type (8 bits): Type of the exchanged message.
• Next Payload (8 bits): Identifies the payload added after the current payload.
• V (1 bit): Flag to indicate the use of a verification message.
• CSB ID (32 bits): Crypto session bundle (CSB) is a collection of one or more crypto sessions (CS).CSB ID field identifies the CSB.
• ♯ CS (8 bits): A crypto session refers to a data steam protected by a single instance of a security protocol.♯ CS field indicates the number of crypto sessions within the CBS.
• CS ID map type (8 bits): Specifies the method of uniquely mapping crypto sessions to the security protocol sessions.
• CS ID map info (variable length): Identifies and maps crypto sessions to the security protocol sessions.

6LoWPAN adaptation layer
The 6LoWPAN standard defined in Hui and Thubert (2011)  IPHC encoding describes how an IPv6 header is compressed.As depicted in Figure 3, 13 bits of the 2 bytes long IPHC are used for compression.The IPv6 header fields that are not compressed are placed immediately after IPHC.Moreover, NH field in IPHC indicates whether the following header is encoded using NHC.If so, NHC encoding follows immediately the compressed IPv6 header.Compression formats for different next headers are identified by a variable ID bits plus the specific header compression encoding bits.The NHC to encode IPv6 extension headers and UDP header are already defined.For more details on 6LoWPAN, we refer the reader to RFC 6282 (Hui and Thubert, 2011).We consider a scenario of an e-health application where smart objects (contextual sensors), gateways and remote entities are used (see Figure 4).IP-enabled smart objects are in charge of sensing health-related data (e.g., blood pressure, blood glucose level, temperature level, etc.).They are planted in the human body.Gateways connect these objects to a backend infrastructure such as the internet.It is worth mentioning that user's smartphones could be used as gateways.Remote entities are in charge of processing and analysing the received data.
Smart objects have limited computational power, memory and energy resources, whereas gateways are much less resource constrained and are comparable to standard routers.Remote entities can take the form of a server hardware or being distributed in a Cloud infrastructure with dynamic resources.
The mapping with MIKEY-Ticket concepts is defined as follows: • Initiator: Smart object (e.g., IP-enabled tiny sensor).
Securing e-health applications relies on efficient key management schemes that ensure reliable key distribution.We do believe that the best approach to tackle security challenges in the evolving IoT is to focus our efforts on standard based protocols.We have chosen MIKEY-Ticket for its simplicity and its adaptation to centralised scenarios which suits well our e-health application.However, current key management protocols such as MIKEY-Ticket were designed to be used in an unconstrained environment which does not take into consideration resources limitation.In the next section, we present in detail our contribution to make MIKEY-Ticket more lightweight while preserving its security properties.To reduce the communication overhead of MIKEY-Ticket protocol when implemented on constrained entities, we have adopted two complementary approaches.Firstly, we have reduced the size of the exchanged messages by proposing a new header compression scheme.Secondly, we have minimised the number of exchanged control messages by proposing a new exchange mode.

New header compression scheme
In this section, we describe our proposed 6LoWPAN header compression scheme for MIKEY-Ticket.Our compression is based on the fact that the fields which are implicitly known to all entities in the network or those that can be deduced from the MAC layer can be removed.As explained in Section 4.2, the NHC is used to encode the IPv6 extension headers and UDP header.Nevertheless, despite 6LoWPAN has defined header compression for UDP, no NHC compression is defined in the case where headers contained in UDP payloads are compressed.In fact, MIKEY-Ticket common header is contained in the UDP payload.Therefore, we propose to use the 6LoWPAN extension proposed in Raza et al. (2012a) to extend 6LoWPAN header compression mechanisms.These extensions indicate that the headers of protocols that are part of the UDP payload are compressed with 6LoWPAN-NHC.The MIKEY-Ticket common header is 12 bytes long.It is appended to each packet through the different exchanged messages.We propose a 6LoWPAN-NHC to compress MIKEY-Ticket header called 6LoWPAN-NHC-HDR.The proposed approach allows reducing the header length from 12 bytes to 3 bytes (2 bytes for our 6LoWPAN-NHC-HDR plus 1 byte for the Next Payload field that is always carried inline) in the best compression case.In fact, only 13 bits are required to encode the different fields.Nevertheless, in order to remain standard compliant (i.e., the size of NHC encodings is multiple of bytes), our 6LoWPAN-NHC-HDR is 2 bytes long.6LoWPAN-NHC encoding schemes do not limit the length or the value of the NHC-ID.However, the NHC-ID must be unique in order to distinguish the various existing compressed 6LoWPAN headers (e.g., IPv6, UDP, IPsec, DTLS, IKE).Thus, the first four bits implement the ID field to uniquely identify our NHC encoding.We set the ID bits to 1100.To the best of our knowledge, the 1100 bits are currently unused as NHC identifiers.In the following, we present in detail the encoding approach for each field (see Table 2 and Figure 5).• Verification V (VF): the VF field encoding is similar to the non-compressed header.If it is set to 0, no verification message is used.When it is set to 1, a verification message is required.
• PRF func (PRF): if 0, the default PRF function defined in Arkko et al. ( 2004) is used.If set to 1, the PRF function value is carried inline.
• CSB ID (CSB): the CSB ID is chosen by the initiator and needs to be unique between each initiator-responder pair.Instead of carrying its 32 bits size inline, we propose to derivate the CSB ID from the concatenation of lower layer addresses.To guarantee uniqueness, we require the use of unique identifiers such as 6LoWPAN addresses, or physical addresses.One bit is sufficient for the encoding.If set to 0, the CSB ID is derived instead of being carried inline.If set to 1, the 32 bits CSB ID are carried after the 6LoWPAN-NHC-HDR header.
• ♯ CS: if we assume in our constrained scenario that there is only one CS in each CSB, there is no need therefore for keeping 8 bits to indicate the number of crypto sessions.We are then able to encode the ♯ CS with 1 bit.If this bit is set to 0, only one CS is considered.In addition, to make our compression flexible, if the bit is set to 1, the number of CS is carried inline.
• CS ID map type(MT): if 0, the default GENERIC-ID map type defined in Mattsson and Tian (2011) is used.
If set to 1, the CS ID map type is carried inline.
• CS ID map info (MI): the CS ID map info size is kept variable in Mattsson and Tian (2011).If we assume that there is only one CS in each CSB, we could use 1 bit for the encoding.If 0, the unique CS is identified with its corresponding mapping to the security protocol for which security associations are created.If set to 1, the map info field is carried inline.
The next payload field is always carried inline as it is impossible to predict or deduce the next payload content.In addition, the three last bits are used as padding bits to remain standard compliant with RFC6282 (Hui and Thubert, 2011) (NHC size is defined as 2 bytes long).Variable length 1

New MIKEY-Ticket exchange mode
Our new communication exchange mode for MIKEY-Ticket is designed to minimise the involvement of constrained nodes.We consider the constrained node as the Initiator of the protocol and the remote entity as the Responder.The constrained node is in charge of requesting the establishment of a session key with the remote entity and periodically sending updates.We assume that I and R are sharing security credentials with the KMS that is in charge of generating, deriving and delivering the required keying materials.Besides, AES-CTR (AES in Counter Mode) algorithm, which is specified as mandatory-to-implement in RFC 3830 (Arkko et al., 2004) is used for encryption.Also, AES-CBC (AES in Cipher Block Chaining mode) is used for MAC computation.
Our communication exchange mode is depicted in Figure 6 and Table 1 summarises the different notations used.It is worth mentioning here that although mode 2, mode 3 and mode 4 (see Section 4.2.1)introduced in RFC 6043 (Mattsson and Tian, 2011) reduce the number of exchanged messages compared to the full three round-trip mode, they introduce strong assumptions on the ability of both I and R to either handle the generation and distribution of security credentials or to share credentials prior to the start of the session.For these reasons, our proposed exchange mode can be considered as an extension of the proposed exchange modes defined in RFC 6043 (Mattsson and Tian, 2011).In fact, our new exchange mode does not assume any capabilities regarding neither I nor R as it is intended to be adaptable to constrained e-health scenarios.
REQUEST_INIT : The Initiator starts the exchange process by sending a REQUEST_INIT message to KMS.This message contains the identities of I (I ID ), KMS (KM S ID ), and R (R ID ).In addition, it contains a nonce N I generated by I, which will be used as a session identifier.Our new communication exchange mode reduces therefore the number of exchanged messages from 6 to 4 messages compared to the basic MIKEY-Ticket defined in RFC 6043 (Mattsson and Tian, 2011) regardless of the ability of I and R to generate, derive or distribute security credentials.As a result, the constrained node processes and exchanges fewer messages.7 Analysis In this section, we provide a detailed analysis of our proposed tailoring for MIKEY-Ticket both in terms of security analysis and energy consumption.Firstly, we conduct a theoretical security analysis of our new exchange mode.In addition, we analyse our protocol's behaviour against the well-known attacks that could hinder the establishment of a secure channel in an e-health environment.Our analysis is then validated using an automated validation tool called Avispa (http://www.avispa-project.org)which is based on formal models.After validating the security properties, we focus on the energy gain of our approach.Different energy models are used to estimate the total energy cost composed of both computational and communication costs.The results are compared with the basic version of MIKEY-Ticket.

Key exchange properties
The security features of our new MIKEY-Ticket exchange mode have been assessed based on the properties presented in Roman et al. (2011).We have added extra analysis concerning integrity and confidentiality as we consider them critical for e-health applications.Hereafter, our communication channel is split into two parts or segments: Seg1) from the Initiator to the KMS and Seg2) from the KMS to the responder.
• Confidentiality: The exchanged data between the different entities involved in our protocol are kept confidential.According to Arkko et al. (2004), AES-CTR is the default and mandatory-to-implement encryption algorithm.Nowadays, more and more tiny sensors include AES hardware coprocessors which help to decrease the overhead.For Seg1, encryption is based on the encryption key eK I,KM S shared between the Initiator (constrained node) and the KMS, whereas in Seg2, encryption is ensured by the use of the encryption key eK KM S,R shared between the KMS and the Responder (remote server).In addition, periodical updates of the established keys are required in order to strengthen the confidentiality and prevent long term attacks.
• Authentication and integrity: By using MAC messages either in Seg1 or in Seg2 communication parts, our new exchange mode ensures that the exchanged data is genuine.In particular, it ensures that data has not been altered and has been sent from legitimate nodes.MAC messages are computed and appended to the exchanged messages based on AES-CBC mode using aK I,KM S in Seg1 and aK R,KM S in Seg2.Furthermore, nonces (e.g., time-stamps or random values) are included in the exchanged messages to avoid replay attacks.
• Distribution: The distribution of security credentials in both communication segments is performed by an offline dealer during the initialisation phase.This constitutes one of the major drawbacks of key distribution schemes based on a pre-shared context.In return, these schemes simplify the cryptographic operations (i.e., Symmetric) at the nodes side which is highly desirable in constrained environments.Besides, upon the establishment of a shared context, our new exchange mode can be run in an online manner, which allows autonomous update processing.
• Overhead: The computation overhead is particularly low.Our compression scheme allows a considerable improvement in energy consumption as the size of the exchanged messages is reduced.Moreover, the constrained nodes are involved in fewer messages compared to the full three round-trip MIKEY-Ticket mode (see Figures 1 and 6).Constrained nodes are thus less solicited as they take advantage of the shared pre-established context with the KMS.A more detailed analysis regarding energy consumption is provided in Section 7.2.
• Resilience: The resilience of our scheme is high.In fact, the loss of a node and thus its key affects only the corresponding sensor as each sensor only stores its shared key with the KMS (i.e., K R,KM S ) and eventually an established key with I (i.e., K I,R ).The KMS maintains a different key with each constrained node either for the pre-shared context or for the generated shared key.
• Extensibility and scalability: Our network model allows new sensors as well as new remote entities to be added (e.g., we can imagine a physician prescribing the implantation of a new sensor for medical reasons).An offline dealer will have to establish a shared context between the new entities and the KMS.No extra operation is required from existing constrained nodes or remote entities when new nodes join them.As a result, high scalability is ensured which is particularly required for constrained environments.
• Storage: Smart objects now provide considerable amounts of storage space due to recent advances in flash memory technology (Tsiftes and Dunkels, 2011).Moreover, our new exchange mode does not add further credentials to be stored in the constrained nodes.The amount of data to be stored is limited, as only two keys (i.e., K R,KM S and K I,R ) have to be stored.Storage space will therefore not limit the deployment of our scheme.

Protocol behaviour against e-health well-known attacks
E-health applications are subject to several attacks that threaten the establishment of secure channels (Li and Lou, 2010;Javadi and Razzaque, 2013;Lim et al., 2010).In this section, we analyse the behaviour of our protocol against these attacks.We focus on the attacks that occur in the network and transport layers of the open system interconnection (OSI) model.
Ensuring key freshness is an important concern with regards to our new MIKEY-Ticket exchange mode.Indeed, to provide the perfect forward secrecy property, the involved entities have to be able to detect replayed messages.In particular, e-health applications might be more vulnerable compared to other types of applications as an outdated information could lead to inadequate and serious medical consequences.To overcome this issue, we have introduced the use of nonces in the different exchanged messages.In fact, these nonces are implemented using one of the following strategies according to the network segment, and to the constrained node capabilities: Random numbers might constitute a solution in our e-health scenario.The constrained node (i.e., the Initiator) maintains a list of the previous received random values in its internal memory.Upon receiving a new message, the initiator checks if the nonce has already been received.As a result, replayed messages are detected.This solution brings a drawback; the constrained node has to maintain a list of the received nonces in its internal memory.This issue can be attenuated by the storage capacity of newly developed nodes (Tsiftes and Dunkels, 2011).The second solution is based on sequence numbers, which does not require any data storage.Sequence numbers provide a sequential counter in the exchanged messages.In the case where a message is replayed, its counter will be smaller or equal to the current one.Thus, the message will be dropped.However, if the KMS goes down (e.g., reboot, hardware failure, etc.), this protection is no longer effective.In fact, the KMS will lose track of the current counter value.Besides, to ensure message freshness, timestamps could also be used.This solution is not suitable for constrained devices as it consumes a lot of energy.In fact, synchronised clocks have to be maintained between the KMS, the remote server, and the constrained nodes.
Taking into account our network specifications, we discuss the feasibility of the precedent solutions.It is obvious that maintaining clock synchronisation between KMS and the constrained nodes is not feasible.However, this solution is adopted to protect the unconstrained part of the network model, namely the channel linking the KMS with the remote server (Seg2).In fact, the Responder and the KMS are not able to challenge each other and they are considered as non-constrained entities that are able to maintain clock synchronisation between them.Hence, the nonces are implemented as timestamps.By doing so, the KMS and the remote server will easily prevent replay attacks.
Regarding Seg1 communication part, our proposed exchange mode allows the Initiator to challenge the KMS about the nonce.In addition, the constrained node is not able to maintain clock synchronisation with the KMS.Consequently, the solution based on random numbers (or sequence numbers) is adopted.If the storage capacity of smart objects is very limited, the solution based on sequence numbers is preferred at the expense of ensuring highly reliable entities with small probabilities of failure.If storage capacity is not a concern, the solution based on random numbers can be adopted.In brief, protecting our new exchange mode against replayed messages is achieved through the combination of the above discussed strategies according to the network model specificities.
Denial of service (DoS) attacks could seriously threaten the availability of our e-health application.In fact, the gathered health-related data should always be available even if the system is under a DoS attack.Like the basic version of MIKEY-Ticket, our new exchange mode is protected against DoS attacks by using the same techniques.In particular, the KMS does not establish any internal state before authenticating both the remote server and the constrained nodes.The different parties share a long-term key with the KMS.Each exchanged message is authenticated before being processed.Besides, classical countermeasures such as rate-limiting and access control list (ACL) could also be implemented.Any malicious message would lead to an abortion of the protocol execution.Node redundancy could be another option.Whenever an entity is made unavailable due to a DoS attack, the protocol execution carries on with the redundant backup node.We refer to Arkko et al. (2004) and Mattsson and Tian (2011) for a more detailed analysis of MIKEY-Ticket behaviour regarding DoS attacks.
Sybil attacks (Douceur, 2002;Javadi and Razzaque, 2013) where a node claims multiple fake identities could lead to harmful consequences in the context of e-health applications.Using these attacks, an intruder could use feigned identities to send false information.As a result, either genuine emergency situations are skipped, or ceaseless false emergency situations are thrown.Our protocol is protected against Sybil attacks.There is no way for a malicious node to perform a Sybil attack unless the KMS (assumed to be a trusted entity) is corrupted.In fact, long-term keys are shared between the KMS, the Initiator (i.e., sensor) and the Responder (i.e., remote server).Any exchanged message with the KMS contains the identity of the sender, and is authenticated using the pre-shared longterm keys.In addition, before any further processing, the KMS checks its access control policy regarding the sender.
Another point of interest regarding the threat model in e-health applications is the attacks that aim to drain the energy power of sensors, and therefore make them unavailable or force them to enter a sleep mode.For instance, the de-synchronisation attack targets the sequence number of the exchanged messages.Actually, this will lead to infinite retransmissions which waste both energy and bandwidth resources.Providing message integrity is the main security concern that hinders this type of attacks.In fact, MAC messages are computed and checked for each exchanged message ensuring that the included data has not been altered.
E-health applications are subject to several routing attacks.Our key management protocol is not involved in securing the routing process, instead, it aims to establish a secure channel upon which the gathered data can be securely transmitted.
In fact, we rely on other mechanisms regarding this aspect.Countermeasures usually involve the introduction of intrusion detection systems (IDS) (Raza et al., 2013b;Le et al., 2012).

Formal validation
Several techniques have been introduced to model and formally validate a security protocol regarding its properties.Model checking (Clarke et al., 1999) is one of the formal methods used to validate finite-state-concurrent systems such as communication protocols.It usually involves verification tools to exhaustively search all possible execution sequences for desired properties in a protocol specification.Many security protocols have been validated through model checking (Tobarra et al., 2009;Hanna et al., 2008), and several validation tools are based on model checking (http://www.avispa-project.org,http://www.prismmodelchecker.org,http://www.cs.utah.edu).We highlight some advantages of model checking compared to classical approaches, which are developed around simulation, testing, and deductions: • Gives the possibility to the users to check every single step of the execution process, allowing them to detect any malfunction in a highly accurate way.However, using simulation or testing, only a broad overview of the protocol behaviour is provided.In addition, some flaws might remain unfound until the protocol's production stage is initiated.
• Allows prompt and automated verifications through different tools that implement model checking.In fact, by adopting model checking, users can avoid prototyping their protocols.
Automated validation of internet security protocol and applications (AVISPA) is a state-of-the-art verification tool for security protocols that includes a set of model checkers with a common front end.The tool follows the Dolev-Yao intruder model (Dolev and Yao, 1981) to intercept messages or to insert modified data.It performs analytical rules to state whether the protocol is safe or not.In the case of unsafety, the tool provides a trace highlighting the steps that led to the attack.In fact, Avispa is considered as an effective tool for the analysis of different internet security protocols and applications.In the literature, several security protocols have been validated through Avispa (Chun et al., 2011;Marino and Caterina, 2011;Charu and Mathieu, 2009;Ruiz-Martínez et al., 2006).Moreover, the security protocols standardised by the IETF have been analysed by the AVISPA community (e.g., IKE, TLS, AAA), and some of the protocols have been found to be flawed (Moedersheim and Drielsma, 2003; http://www.avispa-project.org).
The formal validation of our protocol was carried out using the same Avispa tool to prove that our new exchange mode does not violate the required security properties, in particular, confidentiality, authentication, delivery proof and replay protection.Protocol models in Avispa are written in a role-based language called high-level protocol specification language, or HLPSL (Chevalier et al., 2004).The actions of the different entities are specified in a module called basic role, while their interactions are defined by composing multiple basic roles together into a composed role.In addition, the security goals of the analysed protocol are specified in the goal section before launching the analysis.Besides, Avispa uses four different automatic protocol analysis techniques to validate the analysed protocol against the specified security goals: on-the-fly model-checker (OFMC), constraintlogic based attack searcher (CL-AtSe), SAT-based model checker (SATMC), and tree automata based on automatic approximations for the analysis of security protocols (TA4SP).
In our modelling, we have first specified a basic role to describe the actions of the different entities involved.Then, we have specified how the participants interact with each other in a composed role.The security goals against which the protocol execution will be assessed have been specified in the goal section.Particularly, we modelled the confidentiality property of the generated K I,R , in addition to the authentication property between the involved entities (i.e., I, KM S, and R).
For clarity reasons, we present our modelling using Alice-Bob (A − B) notation, where: The rest of the notations used are the same as those presented in Table 1.Upon completing modelling our exchange mode, we have checked its correctness using a protocol animation tool called SPAN (Glouche and Genet, 2006) that has been introduced to help protocol developers in writing AVISPA specifications.The security goals were subsequently evaluated by executing the four Avispa's backends (i.e., OFMC, CL − AtSe, SATMC and TA4SP).Besides, we have used the default Dolev-Yao intruder model which allows simulating an intruder that has full control over the network.All messages sent and received by the different entities might be intercepted, analysed, modified (as far as the keys are known), or sent to other entities.The results of the simulation were indicated in reports for each backend model produced by Avispa tool.Our new exchange mode is 'SAFE' against OFMC (Figure 7), CL − AtSe (Figure 8) and SATMC (Figure 9).However, against TA4SP database, the result was 'INCONCLUSIVE'.According to Avispa user manual (http://www.avispa-project.org),an inconclusive result does not imply that an attack has been detected (Figure 10).Consequently, based on the obtained results, we can affirm that our protocol is safe regarding the specified security goals.It is impossible for an attacker to violate any of the specified security properties and disrupt the functioning of the protocol.Following our formal validation, we focus, in the next section, on the energy cost savings achieved through our new exchange mode and our header compression scheme.The results are compared with the performances of the basic version of MIKEY-Ticket.

Performance analysis
As explained above, our contribution focuses on tailoring MIKEY-Ticket to the constrained environment of e-health applications.To this end, we propose a new header compression scheme along with a new exchange mode to reduce both the size of the exchanged messages and their number.In this subsection, we provide a performance analysis of our enhancements and compare energy consumption with the basic MIKEY-Ticket.First, we describe the energy model upon which our estimations are based.Then, we evaluate the communication and computational costs regarding both versions of MIKEY-Ticket (i.e., basic version and tailored version).The analysis is concluded with a discussion of the total energy cost highlighting the obtained energy savings.Meulenaer et al. (2008) have presented an energy evaluation of wireless sensor nodes (WSN) regarding the communication cost.This latter is composed of the costs of transmission, reception and listening.Besides, the energy consumption of AES encryption algorithm and SHA-1 hash algorithm on WSN nodes have been also assessed in Kaps and Sunar (2006).Both implementations were processed on tiny nodes with few MHz of computational power, several kilobytes of RAM and several tens of kilobytes of ROM.

Energy model and assumptions
In our evaluation, we consider the total energy cost as the sum of the communication cost and the computational cost.This latter is composed of encryption primitives based on AES and authentication primitives based on SHA-1 as specified in RFC 3830 (Saied and Olivreau, 2012).Based on the energy measurements presented in Meulenaer et al. (2008) and Kaps and Sunar (2006), we estimate the energy consumption of tiny nodes regarding both communication and computational aspects.The deduced values, summarised in Table 3, are used as an energy model of the different operations on constrained nodes.Transmission, reception, listening and cryptographic operations costs are considered for the evaluation of the total energy cost.
A set of assumptions is defined before diving into the details of our evaluation: • Our evaluation only covers energy consumption of the constrained nodes as remote entities are not affected by resources scarcity.Hence, the efforts of reducing energy consumption are focused on the constrained part of the network model.
• In the estimation of message sizes, we only take into consideration the header part on which our compression scheme is applied.The other parts of the exchanged messages are constant regarding the two versions of MIKEY-Ticket.
• MIKEY specification has left the CS ID map info variable in length.In order to carry out our evaluation, we assume a 2 bytes long field.
• In order to evaluate the gains in energy savings of our compression scheme, we propose several levels of compression rates.These rates simulate different applications, each one defines a subset of fields to be compressed using our proposed 6LoWPAN-NHC-HDR.Table 4 presents the different compression rates along with the corresponding compressed fields.

Communication cost
• Sending cost: The sending cost is estimated by computing the overall size of the messages sent from the constrained node for both MIKEY-Ticket's versions.The cost is then computed for different levels of compression rate using the proposed energy model.Table 5 summarises the results.• Receiving cost: The receiving cost is estimated by computing the overall size of the messages sent to the constrained node for both MIKEY-Ticket's versions.The cost is then computed for different levels of compression rate using the proposed energy model.Table 6 summarises the results.
• Listening cost: We consider the constrained node listening for a period of time equal to the sum of packets propagation delay (∆), packets computation time (Comp), transmission latency (T ) and reception latency (R).We assume the KMS being at one hop from the constrained node and 150 ms propagation delay needed for routing packets from the KMS to the remote entity.Moreover, we assume both KMS and R being 100 times more powerful than the tiny node I for the estimation of computational time.Furthermore, we consider, for the estimation of communication latency, an effective data rate of 75 kbps for a tiny node (e.g., TelosB) (Meulenaer et al., 2008).As an example, in the basic MIKEY-Ticket exchange mode, between the sending of REQUEST_INIT message and the reception of REQUEST_RESP message, the constrained node (CN) remains in the listening mode during the following period of time: The cost is computed for different levels of compression rate, Table 7 summarises the results.We notice a slight difference between the energy consumption of the two versions of MIKEY-Ticket.This is due to the fact that the listening time at the constrained node (i.e., I) is based on the time spent by the unconstrained nodes (i.e., KMS and R) to compute and communicate MIKEY-Ticket messages.In fact, their unconstrained resources make our tailoring's impact less visible.

Computational cost
• Encryption cost: The encryption cost is estimated by computing the overall size of the encrypted messages exchanged with the constrained node for both MIKEY-Ticket's versions.The cost is then computed for different levels of compression rate using the proposed energy model.Table 8 summarises the results.
• Authentication cost: The authentication cost is estimated by computing the overall size of the messages exchanged with the constrained node on which a MAC is appended.The estimation is done regarding both MIKEY-Ticket's versions.The cost is then computed for different levels of compression rate using the proposed energy model.Table 9 summarises the results.

Discussion
Upon energy cost evaluation regarding both communication and computational aspects, we have estimated the overall energy cost considering both versions of MIKEY-Ticket.The results are synthesised in Table 10.As shown in Figure 11, we have already noticed a marked decrease in the first compression rate (i.e., 16,4%) due to the introduction of both new exchange mode and compression scheme which reduces the size and the number of the exchanged messages.Energy consumption keeps decreasing with the augmentation of compression rate.In fact, nearly 74% less energy is required to perform a full key exchange in the best case of our compression scheme.The obtained results were expected as the reduction of both size and number of messages leads to a decrease in the energy spent either in the processing or in the communication of data.Nevertheless, an additional processing overhead is expected due to the compression/decompression operations of 6LoWPAN packets.As we consider the KMS being unconstrained, we can safely assume that the generated overhead will be supported by the KMS acting as a 6LoWPAN border router (6BR).Additionally, we have compared the energy cost of several rekeying operations regarding different compression rates (see Figure 12).Frequent updates are likely to be performed in order to avoid long term attacks.The results show a considerable gain in the energy consumption that increases with the increase of rekeying operations.It is worth noticing that the gain is more important with the increase of rekeying operations which is critical for tiny nodes with highly constrained resources (e.g., increasing battery lifetime).
The analysis study allowed us to validate our proposition from two perspectives.First of all, we have provided a theoretical analysis regarding the different security properties required in our network scenario.The properties analysis has been validated using Avispa tool.Furthermore, we have proceeded with a quantitative analysis to highlight energy savings resulting from our tailoring of MIKEY-Ticket.The simulation showed the viability of the proposed solutions on e-health environments that are based on highly constrained sensor nodes.In a nutshell, our proposed solutions make MIKEY-Ticket more lightweight while its security properties are preserved.

Conclusion and future work
In this paper, we have introduced a tailoring mechanism for Mickey-Ticket to adapt it to low-power and constrained environment of e-health devices and applications.To this end, we have proposed a new header compression scheme to reduce the size of messages from 12 Bytes to 3 Bytes in the best compression case.In addition, we have introduced a new exchange communication mode to reduce the number of exchanged messages from 6 to 4. We have evaluated our new solutions with respect to security and energy saving aspects.The results demonstrate that our approach keeps MIKEY-Ticket safe while a considerable amount of energy is saved at the constrained node side.Hence, we can claim that our adjustments of MIKEY-Ticket protocol are well-adapted to IoT constrained environments such as e-health applications.In the future, we are going to investigate the applicability of our tailored MIKEY-Ticket for group communication scenarios, and the eventual impact of mobility on the architectural entities.

Figure 1
Figure 1 MIKEY-Ticket full three round-trip mode exchange (RFC 6043)

Figure 2
Figure 2 MIKEY common header format (RFC 3830) aims to transfer IPv6 packets to IEEE 802.15.4 based networks.6LoWPAN uses IPV6 header compression mechanisms of IPv6 datagrams.Compression mechanisms are motivated by the limited space available in 802.15.4 frames to encapsulate IPv6 packets.In fact, the size of the 802.15.4 frame payload (102 bytes) leaves limited space for an IPv6 packet as 48 bytes are required only for its header.6LoWPAN defines encoding formats for compression based on shared state within contexts.In other words, it takes advantage of the fields that are implicitly known to all nodes in the network or can be deduced from the MAC layer.The compression scheme consists of IP header compression (IPHC) and next header compression (NHC).

Figure 4
Figure 4 Network scenario

•
Version (V): If 0, the version is the default and latest MIKEY-Ticket version defined inArkko et al. (2004) and the field is skipped.If future versions are defined, the bit is set to 1 and the version number is carried inline after the 6LoWPAN-NHC-HDR header.Our compression is thus kept dynamic and flexible.•Data type (DT): the data type field describes the type of the exchanged messages.Based on our new exchange mode (See Section 4.1), we only consider three types of messages (i.e., REQUEST_INIT, REQUEST_RESPONSE, TRANSFER_END) plus the ERROR type.In addition, only the pre-shared key (PSK) mode is considered.The other modes are ruled out due to their inadequacy with our constrained network scenario.Doing so, we are then able to use just 2 bits encoding for the data type field instead of 8 bits in the original version:

Figure 5
Figure 5 Our 6LoWPAN-NHC-HDR encoding compared to the basic MIKEY's header Furthermore, node I computes a MAC using aK I,KM S to ensure message authenticity.The message is then sent to KMS.REQUEST_INIT has the following structure: {[I ID , R ID , KM S ID , N I ] eKI,KMS , MAC}.REQUEST_RESPONSE: when KMS receives the REQUEST_INIT message, it validates the MAC using aK I,KM S .Upon successful verifications, KMS decrypts the message using eK I,KM S and retrieves the different identities and the nonce N I .If the request is authorised, KMS generates the requested key K I,R and uses the key derivation function defined in RFC3830 (Arkko et al., 2004) to derive both aK I,R and eK I,R .Then, KMS constructs two versions of REQUEST_RESPONSE message.The first message is intended to I. It is encrypted with eK I,KM S and contains a MAC computed using aK I,KM S .In addition, the message contains the nonce N I .The second message is intended to R. It contains a MAC computed using aK KM S,R and is encrypted using eK KM S,R .In addition, KMS generates a nonce N KM S and includes it in the message along with N I .The REQUEST_RESPONSE is intended to node I, and has the following structure: {[I ID , R ID , KM S ID , aK I,R , eK I,R , N I ] eKKMS,I , MAC}.The REQUEST_RESPONSE intended to R has the following structure: {[I ID , R ID , KM S ID , aK I,R , eK I,R , N I , N KM S ] eKKMS,R , MAC}.The two versions are then sent to I and R. TRANSFER_END: upon receiving a REQUEST_RESPONSE message, R checks the freshness of N KM S and validates the MAC using aK KM S,R .Upon successful verification, R decrypts the message and retrieves both aK I,R and eK I,R .Node I proceeds similarly and retrieves aK I,R and eK I,R upon receiving REQUEST_RESPONSE message.R constructs TRANSFER_END as a verification message.It includes the nonce N I and computes a MAC using aK I,R .The message is then sent to I.This message has the following structure: {[I ID , R ID , N I ] eKI,R , MAC}.Upon receiving TRANSFER_END message, node I checks the freshness of N I to avoid any replay attack and validates the MAC.A successful verification is considered as a proof of R's knowledge of both aK I,R and eK I,R .

Figure 6
Figure 6 New MIKEY-Ticket exchange mode (see online version for colours)

•
A → S : {I ID , R ID , KM S ID , N I } eKI,KMS , M AC • S → A : {I ID , R ID , KM S ID , aK I,R , eK I,R , N I } eKKMS,A , M AC • S → B : {I ID , R ID , KM S ID , aK I,R , eK I,R , N I , N KM S _eK KM S,B , M AC • B → A : {I ID , R ID , N I } eKI,R , M AC.

Figure 11 Figure 12
Figure 11 Total energy consumption on a constrained node for basic and tailored MIKEY-Ticket regarding different compression rates

Table 1
Terminology table

Table 2
MIKEY-Ticket common header compression

Table 3
Estimated energy costs on constrained nodes

Table 4
Different compression rates

Table 5
Sending cost

Table 6
Receiving cost

Table 8
Encryption cost

Table 9
Authentication cost

Table 10
Total energy cost