Efficient and Secure Pairing Protocol for Devices with Unbalanced Computational Capabilities

Abstract

Wearable devices that collect data about human beings are widely used in healthcare applications. Once collected, the health data will be securely transmitted to smartphones in most scenarios. Authenticated Key Exchange (AKE) can protect wireless communications between wearables and smartphones, and a typical solution is the Bluetooth Secure Simple Pairing (SSP) protocol with numeric comparison. However, this protocol requires equivalent computation on both devices, even though their computational capabilities are significantly different. This paper proposes a lightweight numeric comparison protocol for communications in which two parties have unbalanced computational capabilities, e.g., a wearable sensor and a smartphone, named UnBalanced secure Pairing using numeric comparison (UB-Pairing for short). The security of UB-Pairing is analyzed using the modified Bellare–Rogaway model (mBR). The analysis results show that UB-Pairing achieves the security goals. We also carry out a number of experiments to evaluate the performance of UB-Pairing. The results show that UB-Pairing is friendly to wearable devices, and more efficient than standard protocols when the computation capabilities of the two communication parties are highly unbalanced.

1. Introduction

Obtaining valuable information through big data analysis has become an important trend [1]. In particular, under the influence of Coronavirus Disease 2019 (COVID-19), much related data need to be collected, processed, and analyzed, such as datasets of nucleic acid test results, chest X-rays, and computed tomography scans [2,3]. Big data will be collected and processed in distributed or centralized servers through various terminal devices [4]. More broadly, in the field of healthcare, with the growing demand for health monitoring and vital sign tracking, the market for wearable devices has tripled in the last few years [5].

Nevertheless, the transmission of these data usually requires security mechanisms to prevent leakage [6]. Authenticated Key Exchange (AKE) negotiates shared secrets over insecure channels to protect the wireless communications [7]. In the abovementioned device-pairing scenarios, Bluetooth is a widely adopted technology [8,9,10], using three Secure Simple Pairing (SSP) protocols as its AKE solutions [11]. One of them is the numeric comparison protocol, which combines the human–computer interaction Out-Of-Band (OOB) channel and Elliptic Curve Cryptography (ECC) to assist authentication between two pairing devices. This method has been proven to be secure and easy to use [12].

However, the numeric comparison protocol assumes that the capabilities of the two communicating parties are “computationally balanced”. This is often not the case in Internet of Things (IoT) applications [13,14]. For example, a paired link is established between a wearable device equipped with a body temperature sensor and a hospital server.

Thus, this paper proposes a lightweight pairing protocol, named the UnBalanced secure Pairing (UB-Pairing for short) protocol, for devices with different computational capabilities. UB-Pairing is based on the OOB channels and specifically designed for unbalanced computational requirements. It can outperform the OOB-based protocols in terms of computational costs and has a much more comprehensive range of applications in IoT systems. The main contributions are summarized as follows.

• The UB-Pairing protocol is proposed and designed: it allows the powerful device to undertake a portion of the computing tasks on behalf of the wearable device and enables mutual authentication for devices with the help of OOB channels.
• The security of UB-Pairing is analyzed using the modified Bellare–Rogaway (mBR) model [15] via the computational No Reveal-mBR (cNR-mBR) game [16]. Analysis results show that UB-Pairing achieves the security goals of an AKE protocol. Moreover, we also identify some security vulnerabilities in parallel lightweight protocols.
• We demonstrate the advantages of UB-Pairing through experimental results and use cases in COVID-19 scenarios. Results demonstrate that UB-Pairing is friendly to wearable devices, and the overall performance of UB-Pairing is better than that of benchmark protocols.

The rest of this paper is organized as follows. In Section 2, related work is reviewed and discussed. In Section 3, preliminaries are introduced. In Section 4, the design of the UB-Pairing protocol is explained. In Section 5, security analysis is presented. In Section 6, a number of experiments are conducted and the performance of the UB-Pairing protocol is studied. In Section 7, a use case and corresponding application are simulated. Finally, in Section 8, the paper is concluded.

2. Related Work

Secure Simple Pairing (SSP) protocols can establish secure communications between devices. Depending on the input and output capabilities of the device, a series of MANual Authentication (MANA) protocols have been designed by Gehrmann, Mitchell, and Nyberg [17]. Vaudenay designed a protocol that requires only one message on the OOB channel and pointed out the efficiency problems of MANA protocols that require two OOB channel messages [18]. In [19], the protocol in [18] was improved by reducing one message sent over the wireless channel. In the same year, Laur and Nyberg proposed the three-round protocols MANA IV and MA-DH with a formal security analysis [20]. Later, a series of SSP protocols were proposed using a theory called hash commitment before knowledge [21,22,23,24], which forms the basis of our security analysis. In 2015, Nguyen and Leneutre [25] proposed a lightweight scheme for device pairing with only four messages. However, a brute-force attack was found by Khalfaoui et al. [26]. Later, in 2017, Taparia, Panigrahy, and Jena [27] proposed AKE based on a commitment scheme and authentication strings to withstand MITM (man-in-the-middle) attacks. Unfortunately, we found that their protocol had a design flaw leading to an MITM attack, which will be explained in the security discussion section. In recent years, Hou, Zhang, and Man tried to resist side-channel attacks in SSP protocols [28]; Groza et al. [29] used accelerometer data to establish OOB channels.

IEEE 802.15.6 employs the SSP protocols to establish initial trust in wearable applications [30]. In terms of security, Huang, Liu, and Zhang [31] identified that impersonation and MITM attacks were found against password-authenticated association protocol IEEE 802.15.6. Later, an improved protocol was proposed to solve the security defects [32], including off-line attacks and the lack of forward secrecy. In terms of light weight, Zhang, Xue, and Huang [33] proposed a lightweight version of the display association protocol in IEEE 802.15.6 for pervasive social networks.

Bluetooth also uses SSP as the authentication protocol in wearable applications [11]. Recently, researchers have carried out intensive research on the security of numeric comparison protocols [28,34,35] as well as the Passkey Entry protocols [36] in the Bluetooth standard. However, the requirement of being lightweight for these protocols has not been adequately studied. The proposed protocol aims to address this requirement. To evaluate the performance, we chose the numeric comparison protocol (named Pairing-Bluetooth) in the Bluetooth standard [11], the display-authenticated association protocol (named Pairing-IEEE 802.15.6) in IEEE 802.15.6 [30], and Zhang, Xue, and Huang’s protocol (named ZXH) [33] as the benchmark protocols. Pairing-Bluetooth and Pairing-IEEE 802.15.6 are two standard protocols that have been widely used in many applications; ZXH is a lightweight solution for IEEE 802.15.6.

3. Preliminaries

This section introduces the system model, security goals, security models, and relevant security mechanisms.

Table 1. Notations and corresponding descriptions.

Notations	Description
$EC$	Elliptic curve group
G	A generator point of $EC$
q	The order of G
${\mathbb{Z}}_q^{*}$	Prime finite field
k	Security parameter
($S{K}_i,P{K}_i$)	Private and public key pair of device i
$I{D}_i$	Identity string of device i
$N_i,r_i$	Random number of device i
$K_i$	Shared secret of device i
$L{K}_i$	Session key (link key) of device i
MAC$(·)$	Message authentication code function
MAC${}_{16}(·)$	16-bit short digest function
×	Elliptic curve point scalar multiplication
$U_i$	Sum of temporary secret and long-term private key of device i
$T_i$	Sum of temporary secret and long-term public keys of device i
$f_1(·)$	Function that generates 128-bit commitment (used in Pairing-Bluetooth)
$f_2(·)$	Function that generates link key (used in Pairing-Bluetooth)
$f_3(·)$	Function that generates check values (used in Pairing-Bluetooth)
$g_1(·)$	Function that generates numeric check values (used in Pairing-Bluetooth)
$DHKey$	Diffie-Hellman key
$D_i$	Confirmation value on device i
$C_i$	Commitment value of device i
$ma{c}_i$	Check value from device i
$M_i$	The ith message exchanged in protocol
⊕	Bitwise XOR operation
‖	Concatenation operation
$\stackrel{m}{\to }$	Message m is sent via wireless channel
$\stackrel{m}{⟹}$	Message m is sent via the OOB channel

summarizes the notations used in this paper.

3.1. System Model and Security Goals

Figure 1 shows the system model. UB-Pairing can be applied to scenarios where two parties with unbalanced computational capabilities intend to generate a shared link key through Bluetooth connections. Without loss of generality, we assume that a wearable device (A) intends to establish a common secret key with a relatively computationally powerful smartphone (B) via UB-pairing. Then, using the shared link key, the health data can be securely collected and transmitted to the smartphone according to the Bluetooth protocol stack [11].

A and B can both display a 6-digit number and allow the users to enter confirmation signals (yes or no). If “yes” is entered on both devices, the pairing is successful. An attacker cannot alter, insert, delay, or delete the 6-digit numbers and confirmation signals.

UB-Pairing has two security goals:

• To be secure under passive eavesdropping—the adversary cannot infer any useful information from eavesdropping;
• To be secure against MITM attacks (active eavesdropping)—it prevents a third party from establishing independent contacts with both communication parties without being detected.

3.2. Security Model

Kudla and Paterson in [16] proposed modular security proofs and the mBR model. We use their cNR-mBR game to prove the security of UB-Pairing based on the mBR model.

3.2.1. cNR-mBR Game

A cNR-mBR game is a simulation of a protocol being attacked by an adversary. Kudla and Paterson mainly followed the spirit of the BR model [15,37] to construct the security game and removed the $Reveal$-query of the mBR model.

Formally, a protocol is denoted by $\mathsf{\Pi }$, the security of which is modelled by a cNR-mBR game between an adversary $\mathcal{A}$ and a challenger $\mathcal{C}$. k is the security parameter; P is the set of participants; oracle ${\mathsf{\Pi }}_U^i$ is a session of U with session number i; $S{K}_U$ is the private key of U, and $P{K}_U$ is the public key. The adversary $\mathcal{A}$ is given all $\left\{P{K}_U\right\}$ and has access to any ${\mathsf{\Pi }}_U^i$ together with random oracles, which are set by $\mathcal{C}$ to simulate the attack of $\mathcal{A}$ using inquiries and responses:

• $Send({\mathsf{\Pi }}_U^i,M):$$\mathcal{A}$ sends an arbitrary message M to the oracle ${\mathsf{\Pi }}_U^i$, and ${\mathsf{\Pi }}_U^i$ responds according to $\mathsf{\Pi }$. If $M=\lambda$, the oracle ${\mathsf{\Pi }}_U^i$ initiates a protocol run with its partner $U^{\prime }$ and $\{rol{e}_U=initiator,rol{e}_{U^{\prime }}=responder\}$.
• $Corrupt\left(U\right)$: $\mathcal{A}$ obtains the private key $S{K}_U$ of U.
• $Test\left({\mathsf{\Pi }}_U^i\right)$: ${\mathsf{\Pi }}_U^i$ must be accepted, and its partner must not be queried by the $Corrupt$-oracle. Then, a random element in the key space of the protocol is returned to $\mathcal{A}$.

3.2.2. cNR-mBR-Secure Protocol

For any adversary $\mathcal{A}$, let $Advantag{e}^E\left(k\right)$ be the probability that the session key $sk$ guessed by $\mathcal{A}$ is equal to $s{k}_{P{i}_U^i}$, where $P{i}_U^i$ is the oracle responding to the $Test$ query.

Definition 1.

Π is a cNR-mBR-secure protocol if:

• Two oracles running the protocol both accept holding the identical session key and session ID, and the session key is distributed uniformly on ${\{0,1\}}^k$ for a benign adversary;
• $Advantag{e}^E\left(k\right)$ is negligible for any adversary $\mathcal{A}$ in the cNR-mBR game.

3.2.3. Partnership

The partnership between two participants is defined as follows.

Definition 2.

Suppose that ${\mathsf{\Pi }}_U^i$ holds $(sk,sid,pid)$, ${\mathsf{\Pi }}_{U^{\prime }}^j$ holds $(s{k}^{\prime },si{d}^{\prime },pi{d}^{\prime })$, and both oracles have accepted. Two oracles ${\mathsf{\Pi }}_U^i$ and ${\mathsf{\Pi }}_{U^{\prime }}^j$ are partners when the following three conditions are satisfied:

• $pid=U^{\prime },sk=s{k}^{\prime },sid=si{d}^{\prime }$, and $pi{d}^{\prime }=U$, and
• $rol{e}_{U^{\prime }}=initiator$ and $rol{e}_U=responder$ or vice versa, and
• no oracle accepts on the same session ID such that $si{d}^{″}=sid$ besides ${\mathsf{\Pi }}_U^i$ or ${\mathsf{\Pi }}_{U^{\prime }}^j$.

The mBR model [16] requires that $\mathsf{\Pi }$ has a strong partnering property.

Definition 3.

Assume that adversary $\mathcal{A}$ has a non-negligible advantage over protocol Π in the cNR-mBR game. Π has weak partnering if $\mathcal{A}$ could cause any two oracles to accept holding the same session key when they are not partners. Otherwise, Π has strong partnering.

3.3. Hardness Assumptions

Suppose that $EC$ is an elliptic curve, G is its generator in the order of q, and $a,b,c\in {\mathbb{Z}}_q^{*}$.

• Computational Diffie–Hellman (CDH) assumption: given $a\times G,b\times G$, the advantage of computing $ab\times G$ in probability polynomial time is negligible.
• Decisional Diffie–Hellman (DDH) assumption: given $a\times G,b\times G,c\times G$, the advantage of determining whether $c\times G=ab\times G$ in probability polynomial time is negligible.
• Gap Diffie–Hellman (GDH) assumption: given $a\times G,b\times G$ and an oracle that solves the DDH problem, the advantage of computing $ab\times G$ in probability polynomial time is negligible.

3.4. Security Mechanisms

Several security mechanisms are worth mentioning here.

3.4.1. Commitment Scheme

A commitment scheme is defined as follows.

Definition 4.

The following two algorithms constitute a commitment scheme:

• The probabilistic algorithm Commit$(pub,x)\to (c,t)$, where x is the n-bit private value to be committed, c is the commitment value, t is the corresponding opening value, and $pub$ is some public value.
• The deterministic algorithm Open$(pub,c^{\prime },t^{\prime })\to x^{\prime }\in {\{1,0\}}^n\cup \{\perp \}$. This algorithm returns the n-bit private value $x^{\prime }$ if the commitment $c^{\prime }$ is valid, or ⊥ otherwise.

The commitment scheme shall satisfy the following two properties:

• (${ϵ}_h,{\tau }_h$)-Hiding property, where ${ϵ}_h$ is the upper bounded probability of the case where, given $(c,pub)$, an adversary correctly guesses the private value x without t, and ${\tau }_h$ is the corresponding running time of the adversary.
• (${ϵ}_b,{\tau }_b$)-Binding property, where ${ϵ}_b$ is the upper bounded probability of the case where an adversary correctly opens a commitment c of x to a different private value $x^{\prime }$, and ${\tau }_b$ is the corresponding running time of the adversary.

3.4.2. MAC${}_{16}(·)$ Function

The MAC${}_{16}(·)$ function is defined as follows.

Definition 5.

${MAC}_{16}(k,m)\to d$, where k is the l-bit key, m is the n-bit message, and d is the 16-bit output. It satisfies two properties:

• ${ϵ}_u$-(key-based uniformity) property: given $(m,d)$, Pr${}_{k{\in }_R{\{0,1\}}^n}[{MAC}_{16}(k,m)=y]={ϵ}_u.$ (${ϵ}_u$-key-based uniformity) for any fixed m and y, Pr${}_{k{\in }_R{\{0,1\}}^n}[{MAC}_{16}(k,m)=y]={ϵ}_u.$
• ${ϵ}_r$-(no uniform compensation) property: given $(\theta ,m\ne m^{\prime })$, Pr${}_{k{\in }_R{\{0,1\}}^n}[{MAC}_{16}(k,m)={MAC}_{16}(k\oplus \theta ,m^{\prime })]={ϵ}_r.$

4. The Proposed Protocol

In this section, we first provide a brief review on the Pairing-Bluetooth in [11]; then, the UB-Pairing protocol design is explained in detail and its advantages are described afterwards.

4.1. Review of Pairing-Bluetooth

The Pairing-Bluetooth protocol is composed of four phases. Figure 2 shows the integrated process of Pairing-Bluetooth.

4.2. UB-Pairing

UB-Pairing transfers one scalar multiplication from the wearable device A to the more powerful smartphone B. First, both A and B compute their private–public key pairs; then, they start the two authentication stages and, finally, the Link Key Calculation. The process is demonstrated in Figure 3. After these, A and B will share a fresh and secure session key (or link key [11]) $L{K}_A=L{K}_B.$

4.2.1. Initiation

Both A and B share the public parameters of elliptic curve $EC$, generator G, prime finite field ${\mathbb{Z}}_q^{*}$, and security parameter k. Then, A generates its private and public key pair $S{K}_A$ and $P{K}_A=S{K}_A\times G$; B generates its private and public key pair $S{K}_B$ and $P{K}_B=S{K}_B\times G$.

4.2.2. Authentication Stage 1

• A sends the message $M_1$ to B as (1):

  $$\begin{array}{c}\hfill A\to B:M_1=P{K}_A.\end{array}$$

  (1)
• Upon receiving $M_1$, B generates a random value $R_B\in {\mathbb{Z}}_q^{*}$ and computes $U_B$, $T_B$, and a commitment $C_B$ as (2)–(4):

  $$\begin{array}{cc}\hfill U_B& =R_B+S{K}_B,\hfill \end{array}$$

  (2)

  $$\begin{array}{cc}\hfill T_B& =\underline{U_B\times G},\hfill \end{array}$$

  (3)

  $$\begin{array}{cc}\hfill C_B& =\mathrm{MAC}(T_B,P{K}_A\parallel P{K}_B).\hfill \end{array}$$

  (4)
  Then, B sends the message $M_2$ to A as (5):

  $$\begin{array}{c}\hfill B\to A:M_2=\{C_B,P{K}_B\}.\end{array}$$

  (5)
• Upon receiving $M_2$, A generates a random value $R_A\in {\mathbb{Z}}_q^{*}$ and computes $U_A$ as (6):

  $$\begin{array}{c}\hfill U_A=R_A+S{K}_A.\end{array}$$

  (6)
  A sends the message $M_3$ to B as (7).

  $$\begin{array}{c}\hfill A\to B:M_3=U_A.\end{array}$$

  (7)
• Upon receiving $M_3$, B computes digest $D_B$ as (8):

  $$\begin{array}{c}\hfill D_B={\mathrm{MAC}}_{16}(U_A,T_B\parallel P{K}_A\parallel P{K}_B).\end{array}$$

  (8)
  B then displays the six-digit decimal number converted from $D_B$. Meanwhile, B sends the message $M_4$ to A as (9):

  $$\begin{array}{c}\hfill B\to A:M_4=T_B.\end{array}$$

  (9)
• Upon receiving $M_4$, A verifies $C_B$ as (10):

  $$\begin{array}{c}\hfill \mathrm{MAC}(T_B,P{K}_A\parallel P{K}_B)=C_B.\end{array}$$

  (10)
  If the verification succeeds, A computes a digest $D_A$ as (11):

  $$\begin{array}{c}\hfill D_A={\mathrm{MAC}}_{16}(U_A,T_B\parallel P{K}_A\parallel P{K}_B).\end{array}$$

  (11)
  A then displays the six-digit decimal number converted from $D_A$.
• The human user checks if $D_A=D_B$. If the digests are equal, the user confirms on each device. The two devices compute the shared key as (12) and (13):

  -

  A computes

  $$\begin{array}{cc}\hfill K_A& =\underline{R_A\times (T_B-P{K}_B)}\hfill \\ \hfill & =R_A\times R_B\times G.\hfill \end{array}$$

  (12)

  -

  B computes

  $$\begin{array}{cc}\hfill K_B& =\underline{R_B\times (\underline{U_A\times G}-P{K}_A)}\hfill \\ \hfill & =R_A\times R_B\times G\hfill \\ \hfill & =K_A.\hfill \end{array}$$

  (13)

4.2.3. Authentication Stage 2

• A firstly computes $ma{c}_A$ as (14):

  $$\begin{array}{c}\hfill ma{c}_A=\mathrm{MAC}(K_A,U_A\parallel T_B\parallel A\parallel B).\end{array}$$

  (14)
  Then, A sends the message $M_5$ to B as (15):

  $$\begin{array}{c}\hfill A\to B:M_5=ma{c}_A.\end{array}$$

  (15)
• B firstly checks the following Equation (16):

  $$\begin{array}{c}\hfill \mathrm{MAC}(K_B,U_A\parallel T_B\parallel A\parallel B)=ma{c}_A.\end{array}$$

  (16)
  When the verification succeeds, B computes $ma{c}_B$ as (17):

  $$\begin{array}{c}\hfill ma{c}_B=\mathrm{MAC}(K_B,T_B\parallel U_A\parallel B\parallel A).\end{array}$$

  (17)
  Then, B sends the message $M_6$ to A as (18):

  $$\begin{array}{c}\hfill B\to A:M_6=ma{c}_B.\end{array}$$

  (18)
• A checks the following Equation (19):

  $$\begin{array}{c}\hfill \mathrm{MAC}(K_A,T_B\parallel U_A\parallel B\parallel A)=ma{c}_B.\end{array}$$

  (19)

4.2.4. Link Key Calculation

If the verification of $ma{c}_B$ and $ma{c}_A$ succeeds, A and B derive the link key $LK$ from the shared key as (20):

$$\begin{array}{cc}\hfill L{K}_A& =\mathrm{MAC}(K_A,A\parallel B\parallel P{K}_A\parallel P{K}_B)\hfill \\ \hfill & =\mathrm{MAC}(K_B,A\parallel B\parallel P{K}_A\parallel P{K}_B)\hfill \\ \hfill & =L{K}_B.\hfill \end{array}$$

(20)

4.3. Advantages

The Bluetooth Core Specification [11] stipulates that the device should replace the public–private key pair in each round for protecting the device’s private key. This leads to recalculating a new public–private key pair every time. However, UB-Pairing can generate fresh shared secrets while using the long-term public key. Since UB-Pairing shifts the computational load (one scalar multiplication) from the wearable device to the smartphone, it significantly reduces the computational requirements of the wearable device.

The computational complexity required for UB-Pairing and related protocols is shown in

Table 2. Number of cryptography operations required on the two parties in UB-Pairing and related protocols.

Protocol	${\mathit{S}}_{\mathit{A}}$	${\mathit{S}}_{\mathit{B}}$
Pairing-Bluetooth [11]	$2T_m+3T_h+T_a$	$2T_m+3T_h+T_a$
DPE [36]	$2T_m+6T_h$	$2T_m+6T_h$
SPEKE [29]	$2l{T}_{mod}+l{T}_h$	$2l{T}_{mod}+l{T}_h$
HDK [28]	$2T_m+5T_h+T_a$	$2T_m+5T_h+T_a$
Pairing-IEEE 802.15.6 [30]	$2T_m+5T_h$	$2T_m+5T_h$
ZXH [33]	$T_m+3T_h+T_a$	$3T_m+3T_h+T_a$
UB-Pairing	$T_m+5T_h+T_a$	$3T_m+5T_h+T_a$

Note: T_h: HMAC operation; T_a: elliptic curve point addition; T_m: elliptic curve point scalar multiplication; T_x: xor operation; T_mod: Modulo exponentiation; l: is typically larger than 56.

, where $S_A$ and $S_B$ represent the computational complexity on A and B, respectively. In Pairing-Bluetooth and Pairing-IEEE 802.15.6, the time complexity of A and B is the same, and both A and B undertake two scalar multiplications; meanwhile, in the ZXH and UB-Pairing protocols, the time complexity difference between A and B is mainly in scalar multiplication, where A undertakes one scalar multiplication, and B undertakes three scalar multiplications.

The ZXH protocol is based on IEEE 802.15.6 (which is not widely used as Bluetooth) and lacks explicit key confirmation. In addition, an inattentive user may confirm two unequal values, but ZXH is unable to detect this kind of human error (will be explained in the next section).

Note: Pairing-Bluetooth, Pairing-IEEE 802.15.6, and ZXH are selected as benchmark protocols in the experiments. The reason is that these three protocols are more efficient than other protocols, as shown in Table 2.

5. Security Analysis

We analyze the security of UB-Pairing in this section.

5.1. Formal Security Proof

To start, we first define a similar protocol, UB-Pairing${}^{\prime }$, from UB-Pairing. UB-Pairing${}^{\prime }$ is identical to UB-Pairing except for the session key: UB-Pairing${}^{\prime }$ uses the string $\{K,A\Vert B\Vert P{K}_A\Vert P{K}_B\}$, while UB-Pairing uses MAC $(K,A\Vert B\Vert P{K}_A\Vert P{K}_B)$.

Theorem 1.

Suppose that there is an adversary $\mathcal{A}$ to protocol UB-Pairing${}^{\prime }$ that can win the cNR-mBR game with non-negligible probability $\eta \left(k\right)$ in polynomial time $\tau \left(k\right)$, where k is the security parameter of UB-Pairing${}^{\prime }$. The number of participants is $n_P$ and the number of sessions that each participant may be involved in is $n_S$, where $n_P$ and $n_S$ are both polynomial functions of k. Then, the CDH problem can be solved with non-negligible probability $\eta \left(k\right)\frac{1}{n_P^2·n_S}$ within time $\tau \left(k\right)$.

The proof of Theorem 1 is given in Appendix A.

Based on Definition 4 (commitment scheme) and Definition 5 (MAC${}_{16}(·)$), we redefine them here:

Definition 6.

Commit$(·)$ algorithm modelled by $MA{C}_{Cmt}$-oracle is a $MA{C}_{Cmt}$-query, where the input value is composed of the public keys and private data, and the output of $MA{C}_{Cmt}$-oracle is the commitment value c. Then, the Open$(·)$ algorithm in Definition 4 is a $MA{C}_{Cmt}$-query, too, where the output value is compared with the commitment value c held by the query executor. If the output value equals c, c is a valid commitment; otherwise, c is an invalid commitment.

The commitment scheme has the following two properties:

• Suppose that there is a record $\{T_J,P{K}_I,P{K}_J,C_J\}$ in $MA{C}_{Cmt}$-list. $\mathcal{A}$ queries $C_J$ to $Guess$-oracle and obtains a $T_J^{\prime }$. The probability of $T_J^{\prime }=T_J$ is upper-bounded by ${ϵ}_h$ in time ${\tau }_h$.
• Suppose that there is a record $\{T_J,P{K}_I,P{K}_J,C_J\}$ in $MA{C}_{Cmt}$-list. $\mathcal{A}$ queries $\{{T_J}^{\prime },{P{K}_I}^{\prime },{P{K}_J}^{\prime }\}$ to $MA{C}_{Cmt}$-oracle and receives a $C_J^{\prime }$, where $\{{T_J}^{\prime },{P{K}_I}^{\prime },{P{K}_J}^{\prime }\}\ne \{T_J,P{K}_I,P{K}_J\}$. The probability of $C_J^{\prime }=C_J$ is upper-bounded by ${ϵ}_b$ in time ${\tau }_b$.

Definition 7.

MAC${}_{16}(·)$ modeled by $MA{C}_{16}$-oracle in the cNR-mBR model has the following properties:

• Suppose that there is a record $\{U_I,T_J,P{K}_I,P{K}_J,D_{IJ}\}$ in $MA{C}_{16}$-list. $\mathcal{A}$ generates a number $U_I^{\prime }$ and queries $\{U_I^{\prime },T_J,P{K}_I,P{K}_J\}$ to $MA{C}_{16}$-oracle to obtain a digest $D_{IJ}^{\prime }$. The probability of $D_{IJ}^{\prime }=D_{IJ}$ is ${ϵ}_u$.
• Suppose that there is a record $\{U_I,T_J,P{K}_I,P{K}_J,D_{IJ}\}$ in $MA{C}_{16}$-list. $\mathcal{A}$ queries $\{U_I^{\prime },T_J^{\prime },$$P{K}_I^{\prime },P{K}_J^{\prime }\}$ to $MA{C}_{16}$-oracle to obtain $D_{IJ}^{\prime }$ where $\{U_I,T_J,P{K}_I,P{K}_J\}\ne \{U_I^{\prime },T_J^{\prime },P{K}_I^{\prime },P{K}_J^{\prime }\}$. The probability of $D_{IJ}^{\prime }=D_{IJ}$ is ${ϵ}_r$.

Theorem 2.

Assume that MAC$(·)$ and MAC${}_{16}(·)$ are modelled by $MA{C}_{Cmt}$-oracle and $MA{C}_{16}$-oracle, respectively, and protocol UB-Pairing has strong partnering in the cNR-mBR model.

The proof of Theorem 2 is given in Appendix B.

Here, we draw Theorem 3 from [16]:

Theorem 3.

Suppose that MAC$(·)$ is a random oracle $MA{C}_{LinkKey}$. If UB-Pairing uses a session key via the MAC$(·)$ function and has strong partnering, and UB-Pairing${}^{\prime }$ is probabilistic polynomial time reducible to the hardness of the CDH problem, and the session string decisional problem for UB-Pairing is polynomial time reducible to the DDH problem, then the mBR security of UB-Pairing is probabilistic polynomial time reducible to the hardness of the GDH problem of f.

According to Theorems 1–3, UB-Pairing is secure in the mBR model if the CDH, DDH, and GDH assumptions hold.

5.2. Security Discussion

We discuss the security of UB-Pairing and other protocols [11,25,27,28,30,33] with regard to several security threats involving human users [38]. The results are summarized in

Table 3. Security and functionality comparison of UB-Paring and benchmark protocols.

Protocol	F1	F2	F3	F4	F5	F6	F7	F8	F9
Pairing-IEEE 802.15.6 [30]	√	√	√	×	√	√	√	×	√
Pairing-Bluetooth [11]	√	√	√	√	√	√	√	×	√
Nguyen and Leneutre [25]	√	√	×	×	√	√	√	×	×
ZXH [33]	√	√	√	×	√	√	√	√	×
Taparia, Panigrahy, and Jena [27]	×	√	√	×	√	√	√	×	×
Hou, Zhang, and Man [28]	√	√	√	√	√	√	√	×	×
UB-Pairing	√	√	√	√	√	√	√	√	√

Note: F1: resistance to MITM attacks; F2: resistance to relay attacks; F3: resistance to brute-force attacks; F4: inattentive or dishonest user; F5: rushing behavior; F6: user observation; F7: honest-but-curious party; F8: unbalanced computation; F9: formal security analysis; √: the protocol preserves the feature; ×: the protocol does not preserve the feature.

.

5.2.1. Man-in-the-Middle Attack

The attacker can modify the messages transmitted on the wireless channel. For example, to obtain the session key $LK$, the attacker can replace the values of $U_A,T_B,P{K}_A$, and $P{K}_B$. Nevertheless, with the commitment scheme and OOB checking, the attacker must commit an unknown value, and pass the verification of honest party A or the confirmation of the user who compares the two short numbers. In such cases, the attacker’s advantage is negligible. Therefore, UB-Pairing can resist MITM attacks.

However, in Taparia, Panigraphy, and Jena’s protocol [27], as shown in Figure 4 (where $D_a=m_a$ w.l.o.g.), an MITM attacker could replace $g^{X_b}$ with its own generated $g^c$ in message $m_b$. Since A accepts $m_b$ without authentication, and furthermore, $S_a$ and $S_b$ exclude $g^{X_b}$, A will then generate the shared secret key $K_a={\left(g^c\right)}^{X_a}=g^{c{X}_a}modp$. Therefore, the attacker could calculate the key $K_c={\left(g^{X_a}\right)}^c=g^{c{X}_a}=K_{a}modp$. Hence, Taparia, Panigraphy, and Jena’s protocol [27] could not resist MITM attacks.

5.2.2. Replay Attack

The attacker may replay the messages transmitted in the previous sessions. In UB-Pairing, both A and B generate a fresh nonce or a random number and DHKey in every session. Moreover, the attacker cannot reserve the secure hash function to obtain the random value. Thus, the attacker can only replay the commitment, while the human user’s confirmation can prevent the session from proceeding to the next step. Therefore, UB-Pairing can resist replay attacks.

5.2.3. Brute-Force Attack

The attacker may use brute force to extract the values of nonce or random numbers from the hashes. In UB-Pairing, $R_A$ and $R_B$ are used as ephemeral secrets, the length of which is the same as the private keys (e.g., 160 bits). Therefore, the advantage of an attacker using brute force is negligible. Meanwhile, in Nguyen and Leneutre’s protocol [25], their exchanged commitment contained a short nonce used for subsequent OOB checking, but they ignored the ability of an attacker that could extract the nonce by brute-force search. If the nonce is revealed, the attacker could obtain the value used for OOB checking in advance, rendering the protocol insecure. Therefore, their protocol cannot resist the brute-force attack [26].

5.2.4. Inattentive or Dishonest User

The human user may be careless when confirming two different values. UB-Pairing needs key confirmation with the MAC exchanging after the careless user confirms, which is not given in ZXH [33] and Pairing-IEEE 802.15.6 [30]. In UB-Pairing, if any MAC verification ($ma{c}_A$ or $ma{c}_B$) fails, the honest party will abort. Therefore, UB-Pairing can tolerate an inattentive or dishonest user.

5.2.5. Rushing Behavior

The human user may forget the confirmation step. UB-Pairing cannot proceed without receiving the confirmation signals from the two negotiating parties, as the session key cannot be generated. Hence, the attacker cannot utilize the rushing behavior of human users to crack UB-Pairing.

5.2.6. User Observation

The attacker may learn the six-digit number through a hidden camera. $D_A$ and $D_B$ are computed from the messages transmitted on the wireless channel, on which the attacker may eavesdrop. Therefore, the attacker could compute the value of $D_A$ or $D_B$. However, the attacker cannot obtain $D_B$ or $D_A$ in advance; hence, observing the six-digit number does not pose a threat to the security of UB-Pairing.

5.2.7. Honest-but-Curious Party

The negotiating parties may be interested in obtaining some additional information from each other. In UB-Pairing, the additional information may be the long-term private keys. If B wants to derive A’s private key $S{K}_A$ through $U_A$, it is no different from obtaining a random number. Moreover, $T_B$ gives no advantage to A to derive the private key $S{K}_B$. Therefore, honest-but-curious parties cannot obtain additional information in UB-Pairing.

6. Performance Analysis

The performance of UB-Pairing is studied via a series of experiments. Details are elaborated below.

6.1. Setup

The experimental setup is shown in

Table 4. Experimental setup.

	Device	CPU	Programming Language
Expt. I	Raspberry Pi	1.2 GHz ARM	Python
	Virtual Machine	i7-6700HQ 2.6 GHz	Python
Expt. II	Virtual Machine	i7-6700HQ 2.6 GHz	Python
	Virtual Machine	i7-6700HQ 2.6 GHz	Python
Expt. III	Raspberry Pi	1.2 GHz ARM	Python
	Virtual Machine	i7-6700HQ 2.6 GHz	Python

Note: The operating systems of virtual machines are Ubuntu 16.04 32-bit; “Expt.” means “Experiment”.

. Experiment I and III used a Raspberry Pi and a virtual machine, and Experiment II used two identical virtual machines. The CPU of the Raspberry Pi was 1.2 GHz ARM, and the CPU of the virtual machine was i7-6700HQ 2.6 GHz, and the programming language was Python. The Raspberry Pi was used as the wearable device A, with the virtual machine in a laptop as the powerful device B. The elliptic curves were P-192, P-224, P-256, P-384, and P-521, which are recommended by Federal Information Processing Standards (FIPS). The HMAC based on SHA-256 was used as the default MAC algorithm. The MAC${}_{16}$ algorithm in experiments II, III, and IV was implemented based on the MAC algorithm. The output of MAC${}_{16}$ was the first 16 bits of the MAC output. In the rest of the section, we use $T_y^x$ to represent the time of running y on device x. For all experiments, we repeated them 10 times and used the average value as the final result.

The scope of the experiment and expected results are described below.

• Experiment I tested the computing time required for major cryptographic operations. The expected result: the computation time of scalar multiplication is much longer than that of other operations.
• Experiment II tested the computing time of UB-Pairing on two virtual machines. The expected result: UB-Pairing reduces the communication loads of one party.
• Experimental III tested the running time of UB-Pairing on devices with unbalanced computation capabilities. The expected result: the protocol running time of UB-Pairing is shorter than that of other protocols.

6.2. Experiment I

In experiment I, we evaluated the computing time of HMAC, CMAC, point addition, and scalar multiplication on a Raspberry Pi and a virtual machine. The elliptic curve used was P-192. The average computing time is shown in

Table 5. Average computing time on Raspberry Pi and virtual machine in experiment I.

Operation	Raspberry Pi	Virtual Machine
HMAC	0.0011805 s	0.000263 s
CMAC	0.0009493 s	0.0002671 s
Point addition	0.0000263 s	0.0000039 s
Scalar multiplication	0.0410498 s	0.0185570 s

.

• On both devices, $T_{\mathrm{scalar}\mathrm{multiplication}}\gg T_{\mathrm{HMAC}}\approx T_{\mathrm{CMAC}}$. This result verified that the computation time of scalar multiplication is much longer than the MAC computation time.
• On both devices, $T_{\mathrm{scalar}\mathrm{multiplication}}\gg T_{\mathrm{point}\mathrm{addition}}$. This result verified that the computation time of scalar multiplication is much longer than that of point addition.
• $T_{\mathrm{scalar}\mathrm{multiplication}}^A\gg T_{\mathrm{scalar}\mathrm{multiplication}}^B$. This result verified that computing a scalar multiplication on Raspberry Pi is much more time-consuming than that on the laptop.

Thus, we should try to reduce the time of scalar multiplication on the wearable devices.

6.3. Experiment II

In experiment II, we evaluated the computing time of UB-Pairing on two communication parties, $B1$ and $B2$, which were two virtual machines. The average computing time is shown in Figure 5. We can see that $T_{\mathrm{UB}\text{-}\mathrm{Pairing}}^{B1}\ll T_{\mathrm{UB}\text{-}\mathrm{Pairing}}^{B2}$. This result verified that

• UB-Pairing transferred one scalar multiplication from $B1$ to $B2$;
• The UB-Paring protocol can reduce the computational loads on one communication party, and it is more friendly to wearable devices.

Thus, we can conclude that UB-Paring can reduce the computational loads on one communication party. It is more friendly to wearable devices.

6.4. Experiment III

In this experiment, we implemented and evaluated the running and computing time of UB-Pairing on two communication parties: Raspberry Pi A and a virtual machine B in the laptop. Paring-Bluetooth, Pairing-IEEE 802.15.6, and ZXH were used as the benchmarks. Results are shown in Figure 6. Moreover, the communication overhead is shown in

Table 6. Communication costs under curve P-192.

Protocol	Wireless Messages (bits)	OOB Messages (bits)
Pairing-IEEE 802.15.6 [30]	2624	16
Pairing-Bluetooth [11]	1408	16
ZXH [33]	2176	16
UB-Pairing	$\mathbf{1728}$	$\mathbf{16}$

Note: Under curve P-192, the communication payloads of an identity, elliptic curve point, random number, MAC, and MAC₁₆ are 160, 384, 192, 128, and 16 bits, respectively.

.

• On Raspberry Pi, from the perspective of the running time or computing time, $T_{\mathrm{UB}\text{-}\mathrm{Pairing}}^A\approx T_{\mathrm{ZXH}}^A\ll T_{\mathrm{Paring}\text{-}\mathrm{Bluetooth}}^A\approx T_{\mathrm{Paring}\text{-}\mathrm{IEEE}802.15.6}^A$.
• From the perspective of the total running time or computing time, $T_{\mathrm{UB}\text{-}\mathrm{Pairing}}\approx T_{\mathrm{ZXH}}^A\ll T_{\mathrm{Paring}\text{-}\mathrm{Bluetooth}}\approx T_{\mathrm{Paring}\text{-}\mathrm{IEEE}802.15.6}$.
• When the elliptic curve parameter changed from P-192 to P-521, $T_{\mathrm{Paring}\text{-}\mathrm{Bluetooth}}-T_{\mathrm{UB}\text{-}\mathrm{Pairing}}$ and $T_{\mathrm{Paring}\text{-}\mathrm{IEEE}802.15.6}-T_{\mathrm{UB}\text{-}\mathrm{Pairing}}$ became larger.
• The differences between running time and computing time are small. In other words, the dominant factor that influences the protocol performance is the time of computing scalar multiplications.

In summary, the results verified that UB-Pairing performs better than Pairing-Bluetooth and Pairing-IEEE 802.15.6 when the computational capabilities of the two devices are unbalanced, and UB-Pairing is more friendly to wearable devices. The performance of UB-Pairing and ZXH is almost the same; however, UB-Pairing is more secure (see Table 3), and has more application scenarios since Bluetooth has been widely used.

7. Use Case and Advantages

This section illustrates the usages and advantages of UB-Pairing via a use case in emergency scenarios. It verifies whether UB-Pairing is more applicable for emergency scenarios than symmetric-AKE protocols [15] and general asymmetric encryption-based AKE protocols [39].

7.1. Application of UB-Pairing

In temporary mobile cabin hospitals and nucleic acid PCR testing areas (Figure 7), the public key infrastructure is not always available, and information sharing between devices must be carried out in ad hoc ways. The following steps explain how to use UB-Pairing.

Suppose that there are two characters, Alice and Bob, in our scenario. Their devices should support UB-Pairing. In particular, Alice’s device is a computationally limited device, e.g., a mobile phone A, and Bob’s is a powerful device, e.g., a server B. Moreover, both A and B should support encryption/decryption algorithms such as AES and MAC algorithms such as HMAC.

Suppose that there are N devices in emergency scenarios.

• N1 represents the number of devices in N that have master keys (mk) with each other. When devices A and B have mk with each other, the symmetry-AKE protocol in [15] will be run. The probability that the symmetric-AKE protocol is successfully executed is $P1=\left(\frac{\left|N1\right|}{\left|N\right|}\right)$${}^2$.
• N2 represents the number of devices in N that have public keys pk (and no mk) with each other. When devices A and B have public keys with each other, the TLS-AKE protocol in [39] will be run. The probability of the TLS-AKE protocol being successfully executed is $P2=\left(\frac{\left|N2\right|}{\left|N\right|}\right)$${}^2$.
• N3 (N4, N5, or N6) represent the number of devices that have neither mk nor pk. In the situation wherein devices have neither master key nor public key, we will run UB-Pairing (N3), ZXH (N4), Pairing-Bluetooth (N5), or Pairing-IEEE 802.15.6 (N6). The probability of the protocol being successfully executed is $P3=P4=P5=P6=1-P1-P2=1-{\left(\frac{\left|N1\right|}{\left|N\right|}\right)}^2-{\left(\frac{\left|N2\right|}{\left|N\right|}\right)}^2$.

When A and B generate the link key, they can use it to send messages securely.

7.2. Advantages

Here, we analyze the advantages of UB-Pairing. The availability results are shown in Figure 8 and Figure 9. We find that the connection probability of UB-Pairing ($P3$) is roughly the same as that of the ZXH protocol ($P4$), Pairing-Bluetooth ($P5$), and Pairing-IEEE 802.15.6 ($P6$), and better than the case in which devices only have shared mk and pk. In addition, when the proportion of N3 (N4 or N5 or N6) increases, the advantages of UB-Pairing, ZXH, Pairing-Bluetooth, or Pairing-IEEE 802.15.6 are much more obvious.

However, UB-Pairing is much more efficient than Pairing-Bluetooth and Pairing-IEEE 802.15.6. Although the efficiency of UB-Pairing and ZXH is almost the same, the use of Bluetooth is more extensive than that of IEEE 802.15.6, and UB-Pairing is more secure than ZXH (see Table 3).

In the extreme case, when protocols run between devices with unbalanced computational capabilities in experiment III, the accumulated authentication time is as shown in Figure 10. In the case in which the elliptic curve is P-521, P3/P4/P5/P6 = 90%, and N = 100/540/1000, UB-Pairing can save 16 min more than Pairing-Bluetooth and 14 min more than Pairing-IEEE 802.15.6. This is extremely important for emergency medical treatment.

8. Conclusions

Secure Simple Pairing (SSP) protocols are simpler and more elegant than PKI (Public Key Infrastructure)-based solutions; thus, they have become useful in applications in the mobile computing era. Many researchers have proposed SSP protocols in the past few years, and MANA protocols are one of the representative SSP protocols [17,18,19,20]. Bluetooth [11] and IEEE 802.15.6 [30] also use SSP as their authentication protocols, and some improved versions have been proposed [28,32,33,34,35,36]. Currently, the security, performance, and usability of SSP protocols are still the main research questions.

This paper presented the design of the UB-Pairing protocol, which is specifically proposed for improving the protocol performance where the two communicating parties have unbalanced computational capabilities. The security of UB-Pairing was analyzed using the modified Bellare–Rogaway (mBR) model via the computational No Reveal-mBR (cNR-mBR) game. The analysis results showed that UB-Pairing achieves the security goals of an AKE protocol. Experimental results showed that UB-Pairing is more friendly to wearable devices and more efficient than standard protocols [11,30] when the computation capabilities of the two communication parties are highly unbalanced. Moreover, compared with ZXH [33], UB-Pairing is more secure and has more application scenarios since Bluetooth has been widely used. Further comparison regarding the performance and security can be found in Table 2 and Table 3, and experimental results in Section 6.

In the next few years, when healthcare applications based on Blockchain [40] and Metaverse [41] enter the market, more and more Bluetooth devices will be used to generate health data, and UB-Pairing can play an important role in these applications since it performs better than standard protocols in many cases.

UB-Pairing is the authentication procedure of the whole Bluetooth protocol; thus, if the Bluetooth protocol is used for transmitting large files, the performance improvement is not as obvious as transmitting many small files. In the future, we will study more lightweight AKE protocols, as well as lightweight secure transmitting protocols, which can cover more scenarios.