On Vulnerabilities of the Security Association in the IEEE 802.15.6 Standard
Abstract
Wireless Body Area Networks (WBAN) support a variety of realtime health monitoring and consumer electronics applications. The latest international standard for WBAN is the IEEE 802.15.6. The security association in this standard includes four elliptic curvebased key agreement protocols that are used for generating a master key. In this paper, we challenge the security of the IEEE 802.15.6 standard by showing vulnerabilities of those four protocols to several attacks. We perform a security analysis on the protocols, and show that they all have security problems, and are vulnerable to different attacks.
Keywords
Wearable security Cryptographic protocols Authenticated Key Exchange Elliptic curves Attacks1 Introduction
Advances in wireless communication and embedded computing technologies, such as wearable and implantable biosensors, have enabled the design, development, and implementation of Body Area Networks (BAN) [1]. A BAN, also referred to as a Wireless Body Area Network (WBAN) or a Body Sensor Network (BSN), is a wireless network of wearable computing devices. BAN devices may be embedded inside the body (implants), may be mounted on the body (wearable technology), or may be accompanying devices that humans can carry in clothes pockets, by hand or in various bags. WBAN can be used for many applications such as military, ubiquitous health care, sport, and entertainment [1, 2]. WBANs have a huge potential to revolutionize the future of health care monitoring by diagnosing many lifethreatening diseases, and providing realtime patient monitoring [2]. WBANs may interact with the Internet and other existing wireless technologies.
The latest standardization of WBANs is the IEEE 802.15.6 standard [3] which aims to provide an international standard for low power, short range, and extremely reliable wireless communication within the surrounding area of the human body, supporting a vast range of data rates for different applications.
The network topology consists of nodes and hubs. A node is an entity that contains a Medium Access Control (MAC) sublayer and a physical (PHY) layer, and optionally provides security services. A hub is an entity that possesses a node’s functionality, and coordinates the medium access and power management of the nodes. Nodes can be classified into different groups based on their functionality (personal devices, sensors, actuators), implementation (implant nodes, body surface nodes, external nodes) and role (coordinators, end nodes, relays) [2].
Although security is a high priority in most networks, little study has been done in this area for WBANs. As WBANS are resourceconstrained in terms of power, memory, communication rate and computational capability, security solutions proposed for other networks may not be applicable to WBANs. Confidentiality, authentication, integrity, and freshness of data together with availability and secure management are the security requirements in WBAN [2]. A security association is a procedure in the IEEE 802.15.6 standard to identify a node and a hub to each other, to establish a new Master Key (MK) shared between them, or to activate an existing MK preshared between them. The security association in the IEEE 802.15.6 standard is based on four key agreement protocols that are presented in the standard [3].
Authenticated Key Exchange (AKE) and PasswordAuthenticated Key Exchange (PAKE) protocols aim to exchange a cryptographic session key between legitimate entities in an authenticated manner. Several security properties must be satisfied by AKE and PAKE protocols, and they should obviously withstand wellknown attacks. Many protocols have been proposed in the literature, but some of them have been shown to have security problems [4, 5, 6]. It is desirable for AKE protocols to provide knownkey security, forward secrecy, key control, and resilience to wellknown attacks such as KeyCompromise Impersonation (KCI) and its variants, unknown keyshare (UKS), replay, and DenningSacco attacks. PAKE protocols must also be resilient to dictionary attacks [7, 8].
In this paper, we perform a security analysis on four key agreements protocols that are used in the security association process of the IEEE 802.15.6 standard [3]. We challenge the security of the IEEE 802.15.6 standard by showing vulnerabilities of those four protocols to several attacks. Excluding vulnerability of the first protocol to the impersonation attack which has been implied in the standard, no attack or security vulnerability has been reported in the standard or literature. All the protocols are available in the latest version of the IEEE 802.15.6 standard. The rest of this paper is organized as follows. We review the security structure of the IEEE 802.15.6 standard in Sect. 2, these key agreement protocols in Sect. 3, and report their security problems in Sect. 4.
2 Security Structure of the IEEE 802.15.6 Standard

Orphan: The initial state where the node does not have any relationship with the hub for secured communication. The node should activate a preshared MK or share a new MK with the hub. They cannot proceed to the Associated state if they fail to activate/establish a shared MK.

Associated: The node holds a shared MK with the hub for their PTK creation. The node and hub are allowed to exchange PTK frames with each other to confirm the possession of a shared MK, create a PTK and transit to the Secured state. If the MK is invalid/missing during the PTK creation, they will move back to the Orphan state.

Secured: The node holds a PTK with the hub. The node and hub can exchange security disassociation frames, connection assignment secure frames, connection request and control unsecured frames. The node can exchange Connection Request and Connection Assignment frames with the hub to form a connection, and transit to the Connected state.

Connected: The node holds an assigned Connected_NID, a wakeup arrangement, and optionally one or more scheduled and unscheduled allocations with the hub for abbreviated node addressing, desired wakeup, and optionally scheduled and unscheduled access. The node and hub are not allowed to send any unsecured frame to each other, other than unsecured control frames if authentication of control type frames was not selected during the association.
3 Key Agreement Protocols in the IEEE 802.15.6 Standard
Protocols IIV are based on elliptic curve public key cryptography. The domain parameters consist of an elliptic curve with Weierstrass equation of the form \(y^2 = x^3 + ax + b\), defined over the finite field GF(p) where p is a prime number. In order to make the elliptic curve nonsingular, \(a,b \in GF(p)\) should satisfy \(4a^3 + 27b^2 \ne 0\). There are other conditions that should be satisfied in order to avoid known attacks on elliptic curvebased schemes [9]. The base point G in the elliptic curve is of order n, where \(n \times G = O\) in which O denotes the point at infinity. The IEEE 802.15.6 standard suggests using the Curve P256 in FIPS Pub 1863. Values of a, b, p, n and G are public, and given in [3].
The private keys shall be 256bit random integers, chosen independently from the set of integers \(\{1,...,n1\}\). The private key of \(\mathcal {A}\) and \(\mathcal {B}\) is denoted by \(SK_A\) and \(SK_B\), respectively. The corresponding public keys are generated as \(PK_A = ({PK_A}_X , {PK_A}_Y) = SK_A \times G\) and \(PK_B = ({PK_B}_X , {PK_B}_Y) = SK_B \times G\).
The IEEE 802.15.6 standard does not include having a digital certificate for public keys. Public keys are selfgenerated by involved parties, and are not accompanied by digital certificates. It is because nodes are likely to be severely resourceconstrained, and hence cannot store certificates or perform the certificate validation. The process of certificate validation consists of verifying the integrity and authenticity of the certificate by verifying the certificate authority’s signature on the certificate, verifying that the certificate is not expired, and verifying that the certificate is not revoked [9].
The standard specifies that the node and the hub will abort execution of the protocols if the received public key, sent from the other party, is not a valid public key. A received public key \(PK_i = ({PK_i}_X , {PK_i}_Y)\) shall be treated valid only if it is a noninfinity point (i.e. \(PK_i \ne O\)) on the defined elliptic curve, i.e. \({PK_i}_X\) and \({PK_i}_Y\) satisfy the elliptic curve equation given above. This has been explained in protocol descriptions in the IEEE 802.15.6 standard, but they are absent in the corresponding figures of the standard. We do not show such verifications in Figs. 3, 4, 5 and 6 either. It is noteworthy that validation of elliptic curve public keys includes more steps than those mentioned in the standard. In addition to those conditions, one should check that \({PK_i}_X\) and \({PK_i}_Y\) are properly represented elements in GF(p), and that \(n \times PK_i = O\). The last condition is implied by the other three conditions if the cofactor of the elliptic curve \(h = 1\), which is the case for curves over prime finite fields [10].
In protocols IIV, \(\mathcal {B}\) always sends his public key \(PK_B\) in clear. In Protocols I and IV, \(\mathcal {A}\) sends her public key in clear. In Protocols II, \(\mathcal {A}\) does not send her public key, as \(PK_A\) is preshared with \(\mathcal {B}\). However, in protocol III, \(\mathcal {A}\) first sends a masked public key \(PK'_A = PK_A  Q(PW)\) in which PW is a positive integer, converted from the preshared password between \(\mathcal {A}\) and \(\mathcal {B}\). PW is converted according to the IEEE 13632000 standard from the UTE16BE representation, specified in ISO/IEC 10646:2003, by treating the leftmost octet as the octet containing the Most Significant Bits (MSB). The Q(.) function is a mapping which converts the integer PW to the point \(Q(PW)=(Q_X,Q_Y)\) on the elliptic curve in which \(Q_X = 2^{32} PW + M_X\) where \(M_X\) is the smallest nonnegative integer such that \(Q_X\) becomes the Xcoordinate of a point on the elliptic curve. \(Q_Y\) is an even positive integer, and is the Ycoordinate of that point. In protocol III, \(\mathcal {A}\) shall choose a private key \(SK_A\) such that the Xcoordinate of \(PK_A\) is not equal to the Xcoordinate of Q(PW).
CMAC(K, M, L) represents the Lbit output of the Cipherbased Message Authentication Code (CMAC), applied under key K to message M. The standard suggests to use CMAC with the AES forward cipher function as specified in the NIST SP80038B, and to use a 128bit key as specified in FIPS197. \(LMB_L(S)\) and \(RMB_L(S)\) designates the L leftmost and the L rightmost bits of the bit string S, respectively. X(P) denotes the Xcoordinate of point P on the elliptic curve, i.e. \(X(P) = X(P_X, P_Y) = P_X\). The sign  denotes concatenation of bit strings that are converted according to the IEEE 13632000 standard. BS2DI(BS) converts the bit string BS to a positive decimal integer for display. SSS is the Security_Suite_Selector (16 bits), AC is the Association_Control (16 bits), and XX is X0000000000000000. Security_Suite_Selector specifies type of cryptographic algorithms and protocols that will be used during the protocol execution. It consists of the type of security association protocol (3 bits), i.e. binary representation of the protocol type according to our numbering IIV, security level (2 bits), Control Frame Authentication (1 bit), cipher function (4 bits), and 6 bits reserved for future uses. Association_Control consists of Association Sequence Number (4 bits), Association Status (4 bits), and 8 bits reserved for future. SSS is fixed during a protocol execution, but AC will be different for each message. This is because AC includes the Association Sequence Number which is increased by one after each frame is sent during a protocol execution. Excluding IAck frames that are deleted from the protocols, there are four paths between \(\mathcal {A}\) and \(\mathcal {B}\) in all protocols.
4 Security Problems
In this section, we show that protocols IIV are vulnerable to several attacks. All the protocols are vulnerable to the KCI attack, and they do not provide the forward secrecy. Furthermore, protocols I, III and IV are vulnerable to the impersonation attack. Protocol III is also vulnerable to an offline dictionary attack. Excluding vulnerability of protocol I to the impersonation attack which has been implied in the standard, no attack has been reported on the protocols, and they are available in the IEEE 802.15.6 standard.
The impersonation attack is feasible because public keys are selfgenerated by involved parties, and they are not accompanied by digital certificates due to resource constraints in the nodes. Although this is not recommended in the standard, if one can use certified public keys, or we can have a lightweight PKI [11, 14], this can prevent the impersonation attacks. However, all the protocols will still be vulnerable to the KCI attack. The KCI attack is a variant of the impersonation attack, and has been considered in the eCK security model [12] for AKE protocols. Resilience to the KCI attack is an important security attribute for AKE protocols. If the private key of an entity \(\mathcal {A}\) is compromised, an adversary \(\mathcal {M}\) can impersonate \(\mathcal {A}\) in onefactor authentication protocols. However, such compromise should not enable \(\mathcal {M}\) to impersonate other honest entities in communication with \(\mathcal {A}\). For the sake of briefness, we skip description of the KCI attack on protocols I, III and IV, because they are already vulnerable to the impersonation attack which is stronger than the KCI attack.
Forward secrecy is an important security attribute in AKE protocols. If an entity’s private key has been compromised, it should not affect the security of session keys that have been established before the compromise. We have also the notion of Perfect Forward Secrecy (PFS) which is a bit stronger than the forward secrecy. PFS means that the established session keys should remain secure even after compromising the private keys of all the entities that are involved in the protocol. We have the concept of weakPFS which only allows a passive attack after compromise of all involved private keys.
Protocols IIV use elliptic curve cryptography. Then, it is crucial to have the public key validation. Upon receiving an ephemeral or static public key, the recipient entity must validate it. Otherwise, the protocol would be vulnerable to further attacks. In description of protocols IIV in the IEEE 802.15.6 standard, it has been mentioned that public keys should be validated. However, such validations are absent in corresponding figures in the standard. If one implements the protocols according to the standard’s figures, and does not consider public key validations, further security vulnerabilities will arise. There will be extra scenarios for impersonation attacks on the protocols. Furthermore, all the protocols will be vulnerable to an invalidcurve attack [13] whereby an attacker can extract the private key of another entity. We do not consider those extra vulnerabilities, and strongly recommend to validate public keys.
In the rest of this paper, \(\mathcal {E}\) denotes the adversary in a passive attack, and \(\mathcal {M}\) denotes the adversary in an active attack. The order of protocols and attacks does not imply any preference or importance. The numbering is according to the standard, and will be included in the SSS during protocol executions.
4.1 Protocol I
Protocol I is an unauthenticated key exchange protocol. It is trivially vulnerable to an impersonation attack, but we consider it just for completeness of our security analysis. Such vulnerability has been implied in the standard only for this protocol, where the protocol is introduced as a protocol “without the benefit of keeping third parties from launching impersonation attacks” [3]. Protocol I does not provide the forward secrecy.

\(\mathcal {M}\) selects a private key \(SK_M\), and generates the corresponding public key as \(PK_M = ({PK_M}_X , {PK_M}_Y) = SK_M \times G\). \(\mathcal {M}\) selects a 128bit random number \(N_M\), and sends {\(ID_B  ID_A  SSS  AC  N_M  {PK_M}_X  {PK_M}_Y  XX\)} to \(\mathcal {B}\).

\(\mathcal {B}\) selects a 128bit random number \(N_B\), and sends {\(ID_A  ID_B  SSS  AC  N_B  {PK_B}_X  {PK_B}_Y  XX\)} to \(\mathcal {M}\).

\(\mathcal {B}\) computes \(DH_{Key} = X(SK_B \times PK_M)\), \(T'_1 = RMB_{128}(DH_{Key})\), \(T'_2 = CMAC(T'_1, ID_A  ID_B  N_M  N_B  SSS, 64)\), and \(T'_3 = CMAC(T'_1, ID_B  ID_A  N_B  N_M  SSS, 64)\). \(\mathcal {B}\) sends {\(ID_A  ID_B  SSS  AC  N_B  {PK_B}_X  {PK_B}_Y  T'_2\)} to \(\mathcal {M}\).

\(\mathcal {M}\) computes \(DH_{Key} = X(SK_M \times PK_B)\), \(T_1 = RMB_{128}(DH_{Key})\), \(T_2 = CMAC(T_1, ID_A  ID_B  N_M  N_B  SSS, 64)\), and \(T_3 = CMAC(T_1, ID_B  ID_A  N_B  N_M  SSS, 64)\). \(\mathcal {M}\) sends {\(ID_B  ID_A  SSS  AC  N_M  {PK_M}_X  {PK_M}_Y\) \( T_3\)} to \(\mathcal {B}\). \(\mathcal {M}\) computes \(T_4 = LMB_{128}(DH_{Key})\), and generates the master key \(MK = CMAC(T_4, N_M  N_B, 128)\).

\(\mathcal {B}\) verifies that \(T_3 = T'_3\), computes \(T'_4 = LMB_{128}(DH_{Key})\), and generates the master key \(MK = CMAC(T'_4, N_M  N_B, 128)\).

Assume that \(SK_B\) has been compromised. \(\mathcal {E}\), that has eavesdropped and saved all the messages exchanged through previous runs of the protocol, knows \(PK_A\), \(N_A\) and \(N_B\). \(\mathcal {E}\) computes \(DH_{Key} = X(SK_B \times PK_A)\), \(T'_4 = LMB_{128}(DH_{Key})\), and obtains the established key \(MK = CMAC(T'_4, N_A  N_B, 128)\).

If \(SK_A\) has been compromised, \(\mathcal {E}\) computes \(DH_{Key} = X(SK_A \times PK_B)\), \(T_4 = LMB_{128}(DH_{Key})\), and obtains \(MK = CMAC(T_4, N_A  N_B, 128)\).
4.2 Protocol II
Protocol II requires outofbank transfer of a node’s public key to the hub. It is vulnerable to the KCI attack, and lacks the forward secrecy.
Key Compromise Impersonation Attack: Protocol II is vulnerable to the KCI attack. Here is the attack scenario in which \(\mathcal {M}\) has \(SK_A\) and impersonates \(\mathcal {B}\). As the public key of \(\mathcal {B}\) is sent in clear, we can assume that \(\mathcal {M}\) has obtained \(PK_B\) by eavesdropping a previous protocol run.

\(\mathcal {A}\) selects a 128bit random number \(N_A\), and sends {\(ID_B  ID_A  SSS  AC  N_A  0  0  XX\)} to \(\mathcal {B}\). \(\mathcal {M}\) hijacks the session, and tries to impersonate \(\mathcal {B}\).

\(\mathcal {M}\) selects a 128bit random number \(N_M\), and sends {\(ID_A  ID_B  SSS  AC  N_M  {PK_B}_X  {PK_B}_Y  XX\)} to \(\mathcal {A}\).

\(\mathcal {M}\) has \(SK_A\). \(\mathcal {M}\) computes \(DH_{Key} = X(SK_A \times PK_B)\), \(T'_1 = RMB_{128}(DH_{Key})\), \(T'_2 = CMAC(T'_1, ID_A  ID_B  N_A  N_M  SSS, 64)\), and \(T'_3 = CMAC(T'_1, ID_B ID_AN_MN_ASSS, 64)\). \(\mathcal {M}\) sends {\(ID_A  ID_B  SSS  AC  N_M  {PK_B}_X  {PK_B}_Y  T'_2\)} to \(\mathcal {A}\).

\(\mathcal {A}\) computes \(DH_{Key} = X(SK_A \times PK_B)\), \(T_1 = RMB_{128}(DH_{Key})\), and \(T_2 = CMAC(T_1, ID_A  ID_B  N_A  N_M  SSS, 64)\). \(\mathcal {A}\) verifies that \(T_2 = T'_2\), and computes \(T_3 = CMAC(T_1, ID_B  ID_A  N_M  N_A  SSS, 64)\). \(\mathcal {A}\) sends {\(ID_B  ID_A  SSS  AC  N_A  0  0  T_3\)} to \(\mathcal {M}\).

\(\mathcal {A}\) computes \(T_4 = LMB_{128}(DH_{Key})\), and generates the master key \(MK = CMAC(T_4, N_A  N_M, 128)\).

\(\mathcal {M}\) computes \(T'_4 = LMB_{128}(DH_{Key})\), and generates the master key \(MK = CMAC(T'_4, N_A  N_M, 128)\).
Lack of Forward Secrecy: Protocol II does not provide the forward secrecy. As it is assumed that \(PK_A\) has been securely shared with \(\mathcal {B}\), we just consider the case that \(SK_A\) has been compromised. We show how \(\mathcal {E}\) can extract previously established MK from the eavesdropped messages which proves lack of forward secrecy and PFS: As \(PK_B\), \(N_A\) and \(N_B\) are sent in clear, we can assume that they are eavesdropped and saved by \(\mathcal {E}\). \(\mathcal {E}\) computes \(DH_{Key} = X(SK_A \times PK_B)\), \(T_4 = LMB_{128}(DH_{Key})\), and obtains \(MK = CMAC(T_4, N_A  N_B, 128)\).
4.3 Protocol III
Protocol III is a PAKE protocol. It is vulnerable to impersonation and offline dictionary attacks. It does not provide the forward secrecy.

\(\mathcal {M}\) selects a private key \(SK_M\), and generates the corresponding public key as \(PK_M = ({PK_M}_X , {PK_M}_Y) = SK_M \times G\). \(\mathcal {M}\) computes \(PK'_M = PK_M  Q'\). If \(PK'_M = O\), \(\mathcal {M}\) selects a new private and public key and continues the process until \(PK'_M \ne O\). \(\mathcal {M}\) selects a 128bit random number \(N_M\), and sends {\(ID_B  ID_A  SSS  AC  N_M  {PK'_M}_X  {PK'_M}_Y  XX\)} to \(\mathcal {B}\).

\(\mathcal {B}\) selects a 128bit random number \(N_B\), and sends {\(ID_A  ID_B  SSS  AC  N_B  {PK_B}_X  {PK_B}_Y  XX\)} to \(\mathcal {M}\).

\(\mathcal {B}\) calculates \(PK_M = PK'_M + Q(PW)\), and computes \(DH_{Key} = X(SK_B \times PK_M)\), \(T'_1 = RMB_{128}(DH_{Key})\), \(T'_2 = CMAC(T'_1, ID_A  ID_B  N_M  N_B  SSS, 64)\), and \(T'_3 = CMAC(T'_1, ID_B  ID_A  N_B  N_M  SSS, 64)\). \(\mathcal {B}\) sends {\(ID_A  ID_B  SSS  AC  N_B  {PK_B}_X  {PK_B}_Y  T'_2\)} to \(\mathcal {M}\).

\(\mathcal {M}\) computes \(DH_{Key} = X(SK_M \times PK_B)\), \(T_1 = RMB_{128}(DH_{Key})\), \(T_2 = CMAC(T_1, ID_A  ID_B  N_M  N_B  SSS, 64)\), and \(T_3 = CMAC(T_1, ID_B  ID_A  N_B  N_M  SSS, 64)\). \(\mathcal {M}\) sends {\(ID_B  ID_A  SSS  AC  N_M  {PK_M}_X  {PK_M}_Y  T_3\)} to \(\mathcal {B}\). \(\mathcal {M}\) computes \(T_4 = LMB_{128}(DH_{Key})\), and generates the master key \(MK = CMAC(T_4, N_M  N_B, 128)\).

\(\mathcal {B}\) verifies that \(T_3 = T'_3\), computes \(T'_4 = LMB_{128}(DH_{Key})\), and generates the master key \(MK = CMAC(T'_4, N_M  N_B, 128)\).
Offline Dictionary Attack: Protocol III is a PAKE protocol with twofactor authentication. It requires both public keys and a shared password. For PAKE protocols, it is crucial to provide resilience to offline dictionary attacks. If an adversary could guess a password, he should not be able to verify his guess offline. For performing a dictionary attack on protocol III, it is sufficient that \(\mathcal {E}\) eavesdrops messages between \(\mathcal {A}\) and \(\mathcal {B}\) in a protocol run. \(\mathcal {E}\) then obtains \(PK'_A\) and \(PK_A\) from messages (1) and (4) of the protocol. \(\mathcal {E}\) computes \(PK_A  PK'_A = Q(PW) = (Q_X,Q_Y)\). As \(Q_X = 2^{32} PW + M_X\) and \(Q_X\) is known, this can be used as a verifier. \(\mathcal {E}\) can then try probable passwords from a dictionary of most probable passwords, and check which password PW will map to \(Q_X\). This can be done very fast, and \(\mathcal {E}\) can find the password PW that is shared between \(\mathcal {A}\) and \(\mathcal {B}\).
Lack of Forward Secrecy: Protocol III does not provide the forward secrecy. As \(PK_B\), \(N_A\) and \(N_B\) are sent in clear, we can assume that they are eavesdropped and saved by \(\mathcal {E}\). If \(SK_A\) is compromised, \(\mathcal {E}\) computes \(DH_{Key} = X(SK_A \times PK_B)\), \(T_4 = LMB_{128}(DH_{Key})\), and obtains the master key \(MK = CMAC(T_4, N_A  N_B, 128)\).
4.4 Protocol IV
Protocol IV is vulnerable to an impersonation attack, and lacks the forward secrecy.

\(\mathcal {M}\) selects a private key \(SK_M\), and generates the corresponding public key as \(PK_M = ({PK_M}_X , {PK_M}_Y) = SK_M \times G\). \(\mathcal {M}\) selects a 128bit random number \(N_M\), and computes \(W_M = CMAC(N_M, ID_A  ID_B  {PK_M}_X  {PK_M}_Y, 128)\). \(\mathcal {M}\) sends {\(ID_B  ID_A  SSS  AC  W_M  {PK_M}_X  {PK_M}_Y  XX\)} to \(\mathcal {B}\).

\(\mathcal {B}\) selects a 128bit random number \(N_B\), and sends {\(ID_A  ID_B  SSS  AC  N_B  {PK_B}_X  {PK_B}_Y  XX\)} to \(\mathcal {M}\).

\(\mathcal {B}\) computes \(DH_{Key} = X(SK_B \times PK_M)\), \(T'_1 = RMB_{128}(DH_{Key})\), \(T'_2 = CMAC(T'_1, ID_AID_BW_MN_BSSS, 64)\), and \(T'_3 = CMAC(T'_1, ID_BID_A N_BW_MSSS, 64)\). \(\mathcal {B}\) sends {\(ID_AID_BSSSACN_B{PK_B}_X{PK_B}_YT'_2\)} to \(\mathcal {M}\).

\(\mathcal {M}\) computes \(DH_{Key} = X(SK_M \times PK_B)\), \(T_1 = RMB_{128}(DH_{Key})\), \(T_2 = CMAC(T_1, ID_AID_BW_MN_BSSS, 64)\), and \(T_3 = CMAC(T_1, ID_B  ID_A  N_B  W_M  SSS, 64)\). \(\mathcal {M}\) sends {\(ID_B  ID_A  SSS  AC  N_M  {PK_M}_X  {PK_M}_Y  T_3\)} to \(\mathcal {B}\).

\(Display_M\) will show BS2DI(D) in which \(D = CMAC(N_MN_B, N_BN_MT_1, 16)\).

\(\mathcal {B}\) verifies that \(T_3 = T'_3\), computes \(W'_M = CMAC(N_M, ID_AID_B{PK_M}_X {PK_M}_Y, 128)\), and verifies that \(W_M = W'_M\). \(Display_B\) will show \(BS2DI(D')\) where \(D' = CMAC(N_MN_B, N_BN_MT_1, 16)\).

As \(Display_M = Display_B\), \(\mathcal {B}\) computes \(T'_4 = LMB_{128}(DH_{Key})\) and \(MK = CMAC(T'_4, N_M  N_B, 128)\). \(\mathcal {M}\) computes \(T_4 = LMB_{128}(DH_{Key})\) and \(MK = CMAC(T_4, N_M  N_B, 128)\).
Lack of Forward Secrecy: Protocol IV does not provide the forward secrecy. As \(PK_A\), \(PK_B\), \(N_A\) and \(N_B\) are sent in clear, we can assume that they are eavesdropped and saved by \(\mathcal {E}\).

If \(SK_B\) has been compromised, \(\mathcal {E}\) computes \(DH_{Key} = X(SK_B \times PK_A)\), \(T'_4 = LMB_{128}(DH_{Key})\), and obtains \(MK = CMAC(T'_4, N_A  N_B, 128)\).

If \(SK_A\) has been compromised, \(\mathcal {E}\) computes \(DH_{Key} = X(SK_A \times PK_B)\), \(T_4 = LMB_{128}(DH_{Key})\), and obtains \(MK = CMAC(T_4, N_A  N_B, 128)\).
5 Conclusion
The security of the IEEE 802.15.6 standard for WBAN [3] has been challenged in this paper. We analyzed the security of four key agreement protocols that are used for establishing a master key in the security association process of the standard. We showed that all four protocols have security problems. They are vulnerable to the KCI attack, and lack the forward secrecy. Furthermore, the first, third and fourth protocols are vulnerable to the impersonation attack. The third protocol is also vulnerable to the offline dictionary attack. Further attacks will be feasible if public keys are not validated. The standard aims to provide the confidentiality, authentication, integrity, privacy protection and replay defence. However, our attacks show that the confidentiality and authentication are not achieved by the current security mechanisms in the standard.
Notes
Acknowledgement
The author would like to thank Øyvind Ytrehus and the anonymous reviewers for their comments.
References
 1.Chen, M., Gonzalez, S., Vasilakos, A., Cao, H., Leung, V.C.: Body area networks: a survey. Mob. Netw. Appl. 16(2), 171–193 (2011)CrossRefGoogle Scholar
 2.Movassaghi, S., Abolhasan, M., Lipman, J., Smith, D., Jamalipour, A.: Wireless body area networks: a survey. Commun. Surv. Tutorials, IEEE 16(3), 1658–1686 (2014)CrossRefGoogle Scholar
 3.Association, T.I.S.: IEEE P802.15.62012 Standard for Wireless Body Area Networks (2012). http://standards.ieee.org/findstds/standard/802.15.62012.html
 4.Krawczyk, H.: HMQV: a highperformance secure diffiehellman protocol. In: Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 546–566. Springer, Heidelberg (2005) CrossRefGoogle Scholar
 5.Menezes, A.: Another look at HMQV. Math. Cryptology JMC 1(1), 47–64 (2007)zbMATHMathSciNetGoogle Scholar
 6.Toorani, M.: On continuous afterthefact leakageresilient key exchange. In: Proceedings of the 2nd Workshop on Cryptography and Security in Computing Systems (CS2 2015), ACM (January 2015)Google Scholar
 7.Toorani, M.: Cryptanalysis of a new protocol of wide use for email with perfect forward secrecy. Secur. Commun. Netw. 8(4), 694–701 (2015)CrossRefGoogle Scholar
 8.Bellare, M., Pointcheval, D., Rogaway, P.: Authenticated key exchange secure against dictionary attacks. In: Preneel, B. (ed.) EUROCRYPT 2000. LNCS, vol. 1807, pp. 139–155. Springer, Heidelberg (2000) CrossRefGoogle Scholar
 9.Toorani, M., Beheshti, A.: A directly public verifiable signcryption scheme based on elliptic curves. In: Proceedings of the 14th IEEE Symposium on Computers and Communications (ISCC 2009), pp. 713–716 (2009)Google Scholar
 10.Hankerson, D., Vanstone, S., Menezes, A.J.: Guide to Elliptic Curve Cryptography. Springer, Berlin (2004) zbMATHGoogle Scholar
 11.Misra, S., Goswami, S., Taneja, C., Mukherjee, A.: Design and implementation analysis of a public key infrastructureenabled security framework for ZigBee sensor networks. International Journal of Communication Systems (2014)Google Scholar
 12.LaMacchia, B.A., Lauter, K., Mityagin, A.: Stronger security of authenticated key exchange. In: Susilo, W., Liu, J.K., Mu, Y. (eds.) ProvSec 2007. LNCS, vol. 4784, pp. 1–16. Springer, Heidelberg (2007) CrossRefGoogle Scholar
 13.Toorani, M., Beheshti, A.: Cryptanalysis of an elliptic curvebased signcryption scheme. Int. J. Netw. Secur. 10(1), 51–56 (2010)Google Scholar
 14.Toorani, M., Beheshti, A.: LPKIa lightweight public key Infrastructure for the mobile environments. In: Proceedings of the 11th IEEE International Conference on Communication Systems(ICCS 2008), pp. 162–166, November 2008. doi: 10.1109/ICCS.2008.4737164