A Key Management Scheme for Providing Secure Multicasting over Bluetooth Scatternets Subir Biswas, Syed Rehan Afzal, Jong-bin Koh, Mustafa Hasan, Gunhee Lee, and Dong-kyoo Kim Graduate School of Information and Communication, Ajou University, San 5 Wonchun Dong, Yeongtong, Suwon- 443 749, Republic of Korea {subir, rehan, nitefly, hasan, icezzoco, dkkim}@ajou.ac.kr

Abstract— Secure multicasting is one of the major requirements for today’s communication arena. And for any kind of secure communication, a key-distribution scheme is the most sensible part. Being a highly promising, low-cost, and emerging wireless technology, Bluetooth has key distribution supports for secure multicasting over its unit one-hop network, piconet. Bluetooth core specification [1] defines basic security protocols for key generation, encryption, and authentication for intra-piconet security. However, not much attention has been paid so far on securing multicasting over the Bluetooth Scatternet; nevertheless, multicasting is quite a sensible aspect of modern communication arena. Here in this paper, we extend the piconets key distribution scheme to present a new key management scheme for secure multicasting over Bluetooth Scatternets. Our key management scheme is compatible to the current Bluetooth architecture design as we rely on Bluetooth’s existing security algorithms to propose our resolution. Keywords- Bluetooth Piconet, Scatternet, Master node, Master key

I.

INTRODUCTION

Bluetooth has developed an important and significant platform for wireless ad-hoc networks by providing robustness, low power consumption, and low-cost for short range communications. Bluetooth technology is introduced by Bluetooth Special Interest Group (SIG). This technology enables all kind of electronic devices to communicate with each other. The communication range of a device may vary from 10 meters to 100 meters depending on the output power level of a device. A Bluetooth piconet is a single-hop unit network which consists of at most 8 active Bluetooth nodes where there is one ‘master’ node and the rest are ‘slave’ nodes. Two or more piconets may form a larger network called, Scatternet. A connecting common node to adjacent piconets in a Scatternet is called a ‘bridge’ or ‘gateway’. Communication of devices is always performed through the master of the corresponding piconet. Fig. 1 gives an example, where three piconets- P1, P2, and P3 form a simple Scatternet. Nodes M1, M2, M3 are their master nodes and rests are the slaves. D and G are ‘gateway’ nodes. Devices, including master node, share the same channel in a piconet while Bluetooth adopts Frequency Hopping Spread Spectrum (FHSS) mechanism to reduce the interference among other communicating nodes.

Figure 1. An example of Bluetooth Scatternet.

Bluetooth operates on the unlicensed ISM band of 2.4 GHz. This feature gives Bluetooth an enormous independence for thousands of small network applications like video conferencing, multi-party file sharing, remote input devices for computers, many audio-visual applications, interactive games and software distributions. With the passage of time, this range of applications is growing in parallel with the enhancement of computers performance, application versatility, and the development of Bluetooth technology itself. Most of the above mentioned applications require higher degree of secure multicasting. As Bluetooth works on the unlicensed frequency band, it is even more vulnerable to many different security attacks. Though, the latest version of Bluetooth Specifications [1] explicitly defines the basic security issues, yet a number of security challenges are limiting the promise of Bluetooth; secure multicasting over the Scatternet is one of them. In [2] Li et al. presented a link key establishment protocol for unicast communications in Bluetooth Scatternets where they extended the piconets basic key agreement protocol to Scatternets. Their proposed protocol has the same level of security as that of the piconet key establishment procedure. In a different secure multicast framework [3], Mittra et al. defined a secure multicast protocol for general purpose computing, where he introduced the concept of Group Security Controller (GSC) in each multicastsubgroup which can be compared with a master node in a Bluetooth piconet. Here in this paper, we incorporate an effective concept of key management for multicast communications over Bluetooth Scatternets where we combine the ideas of ‘inter-piconet secure

communications in a Scatternet’ and ‘to have the shared secrets between the sender and other master nodes of the Scatternets’. We show that our scheme is decently poised to a trade-off between security level and the Scatternet performance. We organize the remaining of our paper as follows. Section II briefly describes the security outline of Bluetooth as specified in the core specifications [1]. The details of point-tomultipoint security of Bluetooth piconets are narrated in section III. Section IV illustrates our proposed multicast key management scheme over the Bluetooth Scatternet. Different security and performance aspects are discussed in section V. Section VI concludes the paper. II.

BLUETOOTH SECURITY BACKGROUND

Bluetooth core specification [1] describes the link layer security protocols for Bluetooth piconets. The specified security system includes different Key generation and management schemes, Encryption and Authentication of Bluetooth nodes. In this section we briefly describe the leading features of Bluetooth piconet security. A. Key Management During the initialization of a Bluetooth device, the secret keys are generated and they are kept secret in the device. Bluetooth core specification [1] defines the term “Link key” which is a 128-bit random number, works as a permanent or semi-permanent secret key, and shared between two or more devices. This link key is the foundation of all secure data transmission between these devices. There are four distinct types of link keys have been defined for Bluetooth security due to the variety of its applications: •

The initialization key, Kinit is needed when two devices come to communicate with each other for the first time. Each node generates this key by using E22 algorithm and this key is used only for the purpose of exchanging the unit key between two devices. The Initialization key is discarded immediately after the devises perform the Unit key exchange.

•

The unit key, KA is generated by using E21 algorithm during the first time a BT device is switched on. This unit key is used as a link key between the two devices and usually the current application determines which node should provide the unit key as their link key. Once created, the unit key is kept in the node’s volatile memory and hardly changed.

•

The combination key, KAB is generated separately in two devices by the equal participation of two nodes A and B. Each node generates a random number and those numbers are exchanged under the protection of current link key between them. The combination key is a semi-permanent key which replaces the shared current link key immediately after being generated.

•

The temporary key, Kmaster is used in a Bluetooth piconet for secure point-to-multipoint communication services. The master node generates this key which is also known as the master-key. The master node

securely distributes the key among the multicast clients inside the piconet. This key works as a common link key for all connections in a piconet during a multicast or broadcast communication. B. Data Encryption Bluetooth uses a stream cipher based on Linear Feedback Shift Registers (LFSR) to perform data encryption. The sender encrypts the payload field of each packet using the generated key stream. The receiver node decrypts the encrypted payload by generating the key stream and applying exclusive-OR operation on it with the encrypted payload fields. The encryption algorithm E0 [1] runs in both of the communicating devices which uses an encryption key KC, a 48-bit unique Bluetooth address of the master node, the master clock bits, and a random number generated by the master. The encryption key, KC is derived from the E3 algorithm as indicated below: KC = E3 (Shared link-key, 128-bit random number, COF). (1) Depending upon the type of the link key used, the COF value either comes from master’s device address or from an output (ACO) of the authentication process. C. Authentication In Bluetooth, authentication mechanism works based on a challenge-response scheme. The verifier device sends a random number (AU_RAND) to the claimant device as a challenge. Both the verifier and the claimant device calculate a result (SRES) using E1 algorithm [1]. The claimant device then sends it back to the verifier. If the two results are exactly the same, the claimant device is said to be authenticated by the verifier. During the authentication process, both of the devices generate an Authenticated Ciphering Offset (ACO) value. As mentioned in the last paragraph, this ACO is used in generating the encryption key. For mutual authentication, the two devices can switch their roles and the previously authenticated device can send a new AU_RAND to the other device. Fig 2 depicts the complete authentication scheme in Bluetooth.

Figure 2. Device authentication in Bluetooth.

III.

SUMMARY OF PICONETS MULTICAST DATA SECURITY

The master node in a piconet can generate a master key for common use in order to provide multicasting to all of its slaves. Although it’s possible for a master node to send the same data packet to all of it’s multicast clients by using separate encryption keys, it may cause severe bandwidth and capacity loss for the piconet. Again, a slave node is unable to switch between different encryption keys in real time. Thus, the master node computes a new common key (master key) that replaces the common link key of every multicast link. The generation of master key in a master node of a Bluetooth piconet requires two 128-bit random numbers R1 and R2. It then calculates the master key using E22 algorithm [1]. Kmaster = E22 (R1, R2, 16).

(2)

The third input parameter 16 is a fixed value given to indicate the length of the random numbers in bytes. The master key Kmaster is itself a 128-bit random number. Master node then, generates one more random number- R3 and sends it to all of its multicast clients. Both the master and slave nodes now use E22 algorithm which requires the common link key and R3 to produce an overlay value. The master node combines the overlay and Kmaster with an XOR operation and sends the result (C) to the corresponding slaves. When the slave nodes receive the result C, it recalculates the master key Kmaster by an XOR operation of overlay and C. after the key is generated and distributed, the challenge-response authentication process takes place. Fig. 3 illustrates the complete picture of generation and distribution of a master key.

Figure 3. Master key generation and distribution process.

Every individual slave in a piconet that wants multicastservices must be managed this way separately by the master node. The master node then, issues a special command to all of its authenticated slave nodes for replacing their current link key by the master key. Subsequently, the master node produces a new random number EN_RAND and sends to all its authenticated slaves. All participating devices including the master generate a new encryption key, KC utilizing the master key, EN_RAND and a ciphering offset COF that comes from master node’s device address. The following equation summarizes the procedure:

KC = E3 (Kmaster, EN_RAND, COF).

(3)

As all the necessary information have been transferred, the master node now can securely multicast data packets to all its authenticated slaves in the piconet using the newly derived encryption key. All allowed slaves now can listen to the multicast payloads. IV.

PROPOSED KEY MANAGEMENT SCHEME FOR SECURE MULTICASTING OVER THE SCATTERNET

We consider that there is no already existing shared secret (e.g. shared PIN) between the multicast sender and a multicast receiver. That is, initially the sender and receiver nodes don’t know each other. Now, before we describe our new key establishment mechanism for multicasting over Bluetooth Scatternets, we need the following assumptions: •

Bluetooth nodes group into piconets in a procedure as specified in [1, 14] where there is one master and at most seven active slave nodes in each of those.

•

Two or more piconets form a Scatternet, following any one model like [15, 16, 17, 18, 19, 20, 21, and 22].

•

A suitable Scatternet routing protocol like [22, 23, and 24] for Bluetooth is already running throughout the Scatternet.

•

Basic piconet security protocols are all running as different link keys and encryption keys are established between the adjacent nodes in each piconet. The nodes are all authenticated by the master nodes of the corresponding piconets.

•

The proposed multicast key is itself a common link key for the secure multicast group.

A. Detailed Description In the beginning of the multicast key establishment, the source master node will setup a shared secret with each individual master node of other piconets in the existing Scatternet. These shared secrets are established by deploying the Diffie-Hellman key exchange policy [2, 5]. We illustrate the scheme with the example of fig. 4, where the sender node M1 establishes different shared secret with nodes M2 and M3. In order to accomplish this, the two nodes M1 and M2 randomly select their secrets RM1 and RM2 respectively. Each of the nodes then, generates individual key share. Sender node M1 calculates its share, KM1 = α RM1 mod p.

(4)

Concurrently, master node M2 produces its share, KM2 = α RM2 mod p.

(5)

In both cases, α is a primer root of p; α, p values are public to everyone and α, RM1, RM2 < p. Now, both the nodes exchange their key shares KM1 and KM2 in plain text which will keep the overhead low for those two nodes and for other

intermediate BT devices. Once each of the two master nodes M1 and M2 has the key shares KM1 and KM2, both of them can compute the common secret key, KM1M2 = (KM1) RM2 = (KM2) RM1= αRM1RM2 mod p.

(6)

Both the nodes M1 and M2 save the established shared secret key in their volatile memory. This way, the master node M1 establishes shared secrets with all other master nodes in the Scatternet (M3 here in this case).

Where, Kj is the link key between M2 and Nj is a multicast -client in piconet P3. Now, this way, all the multicast clients in the Scatternet are sharing the same key Kmcast with the sender node M1. The next obvious step is to generate the encryption key for encrypting the multicast data packets. We follow the same encryption key generation scheme as mentioned in pointto-multipoint configuration defined in the Bluetooth core specifications. To accomplish this, the source master node M1 would generate a random number EN_RAND and send it to all members of the multicast group in plain text. Then, each device, including the sender node, would compute the encryption key as given in equation 3. The multicast key Kmcast replaces Kmaster in the equation 3 in this case. Authentication at this stage is not required as every single multicast-recipient has already been authenticated by the master node during their joining to the corresponding piconets. The sender master node discards the existing multicast key at the end of the current session and regenerates a new one for the new session following the same procedure. Please note that the sender master node discards the old multicast key, but doesn’t rule out the shared keys with other master nodes in the existing Scatternet so that, it can use those shared secrets again and again.

Figure 4. The sender master node has separate shared secret keys with other master nodes in the Scatternet.

The sender node M1 establishes the different secret key with every master node in the Scatternet. It then, generates two random numbers R1 and R2 to use in the key generation algorithm E22 to produce the multicast key, Kmcast = E22 (R1, R2, 16).

(7)

This Kmcast is the common link key which will be soon shared by all the multicast receiver nodes. In order to deliver this key to the multicast clients, the sender M1 first separately encrypts the multicast key using the different secret keys which have already been established between M1 and other master nodes (M2 and M3 in this case) and then, sends those encrypted payloads to the corresponding master nodes (node M2 and M3). M1 M1

KM1M2 (Kmcast)

M2.

KM1M3 (Kmcast)

M3.

The receiver master nodes (M2 and M3) in each piconet, decrypt the content, re-encrypt it using their individual shared link key with each multicast client in the piconet and then, separately deliver it to the multicast-client slaves. M2

Ki (Kmcast)

Ni.

Where, Ki is the link key between M2 and Ni is a multicastclient in piconet P2. M3

Kj (Kmcast)

Nj.

B. Key Revocation and Re-keying Once a multicast key is somehow out of the current Scatternet, it must be revoked. Otherwise, if an attacker node gets the possession of that key, it can calculate the encryption key from the compromised multicast key and by using that it can illegally access the whole multicast payloads as other parameters like EN_RAND are either sent in plain text or not too difficult to obtain. If a valid client node leaves a multicast group before the end of the session, the key must be revoked. On the other hand, if a new node comes to join the multicast group at the middle of a multicast session, the existing multicast key is not revoked, rather it’ll be provided with the existing multicast key after the new node is authenticated. Again, if there is a malicious multicast recipient node detected by an intrusion detection mechanism like [13], we must revoke the key from the Scatternet to secure the multicast data from being eavesdropped, as it can transfer the information outside the multicast group. While a multicast key is revoked, to keep the communication on going, we must compute another multicast key. For that purpose, the sender master node generates a new pair of random numbers R1, R2 and computes the new multicast key using the E22 algorithm as mentioned in the previous section. Following our original direction, this new key is again distributed to the valid multicast client nodes. The source then generates a new random number EN_RAND, transfers it to all client nodes in plain text and along with other multicast receivers, it computes the new encryption key. C. Discussion Throughout the description, we have been mentioning a multicast source node as a master node. Now, there arises an obvious question, “can’t a slave node be a source of multicast

data?” Of course, it can be. But as a slave node can not directly communicate with another node without communicating through the master and as the required multicast key generation algorithm, authentication process, generation of EN_RAND for the encryption key and some other important functionalities are only available in a master node, we consider that even though, a slave node in a piconet can be a source for the multicast communication, the master node of its piconet will play all the major roles for multicasting purpose. So, in such cases, where a slave node is the source for a multicast session, the slave source makes a request to its master node and then, the master node includes that slave-source node into the multicast group along with other multicast clients. The slave source sends the data packet to its master node using the established multicast key as the link key and the master node takes the rest of the actions to distribute the data among the clients over the Bluetooth Scatternet. Another important consideration is to presume a master node as a trusted entity and thus, it is always free from rekeying operation. This is because, every kind of communication in a piconet is possible only through the master node and a master node is the initiator of any communication in a piconet. It plays the most significant security roles inside a piconet. Bluetooth master nodes have been considered to be trusted in almost all previous researches on Bluetooth security. V.

SECURITY-PERFORMANCE TRADEOFF

In this section, we mainly analyze the important security features and their impact on Scatternets performance based on the proposed scheme and the following discussion. While setting up the initial secret keys between the sender master node and the other piconets’ master nodes, our key establishment scheme uses Diffie-Hellman key exchange scheme, which is one of the most common choices for secret key establishment between two different devices. Note that in our example, the nodes exchange their key shares, KM1 and KM2 in plain text. But, a node intended to compute the shared key KM1M2, would not be able to find the values of RM1 and RM2 as they were never disclosed by those nodes. Thus, no malicious node can compute that shared secret. Again, as the key shares were transferred in the plain text, no separate encryption or decryption was required by the nodes, that means, savings in encryption and computation capacity.

known to the multicast group members and so, the generated encryption key is beyond the scope an unauthorized node. In our scheme, if a new node wants to join the multicast group, it must be authenticated first by the master node of that particular piconet. That is, a node- trusted by the local master node in the corresponding piconet, is also trusted by the multicast source. This may seem to be a threat to the security of multicasting operation. But, if a new node is to be authenticated by a sender master, there is always a possibility that a notorious node may intentionally leave and join a multicast group repeatedly to waste the bandwidth and computation capacity of the Scatternet, leading the whole Scatternet to a severe DoS attack. The established shared secret key between the sender master and another piconets master node is kept in the volatile memories of both the nodes, so that in case of key revocation, the re-keying process can take place quickly, by simply reusing those shared secret keys. VI.

CONCLUSION AND FUTURE DIRECTION

In this paper we proposed a new key management scheme for secure multicasting in Bluetooth Scatternets which extends the existing key distribution technique for Bluetooth piconets. In this scheme, a sender node can securely establish a multicast key among the multicast group members throughout the Bluetooth Scatternet without having any prior shared secret (e.g. shared PIN) between them. Our approach would definitely increase its usability and adds more to the future prospects of Bluetooth. In our true knowledge, ours is the first proposed key management scheme for multicasting over the Bluetooth Scatternet. Our future work includes the formal validation of this approach. We also have plans to work on securing the Bluetooth Scatternet formation protocols. We envision establishing a complete security framework for secure communication in Bluetooth Scatternets. REFERENCES [1] [2] [3]

After the establishment of initial secret keys between the sender master device and other piconets’ master nodes, the multicast key is delivered to the recipients’ master nodes using the encryption with those initial secret keys. There is no decryption and encryption operation involved in intermediate nodes which keeps the computation complexity low for the whole network.

[4]

The master nodes in the recipient piconets deliver the multicast key to all of their multicast-client slaves by using the individual link keys. This provides the equal safety of the multicast key for all multicast-recipient nodes disregarding their distance from the source node. During the encryption key generation process, although the random number EN_RAND is sent to the recipients in plain text, the multicast key is only

[7]

[5]

[6]

[8]

[9]

“The Bluetooth Core Specification, v.2.0”, November 2004. http://www.bluetooth.org/spec/ Huaizhi Li, Mukesh Singhal. “A Key Establishment Protocol for Bluetooth Scatternets.” Proceedings of the 25th IEEE ICDCSW, 2005. Suvo Mittra. “Iolus: A Framework for Scalable Secure Multicasting.” Proceedings of the ACM SIGCOMM ’97, September 1997. Farkas, L. Bakos, B. Spanyi, P. “A practical approach to multicasting in Bluetooth piconets.” Proceedings of IEEE WCNC 2006. Ingemarsson, D. T. Tang, C. K. Wong. “A Conference Key Distribution System.” Proceedings of IEEE Transactions on Information Theory, September 1982. Tzu-Chiang Chiang, Yueh-Min Huang. “Group Keys and the Multicast Security in Ad Hoc Networks.” Proceedings of the 2003 International Conference on Parallel Processing Workshops (ICPPW’03), 2003. T. Kaya, G. Lin, G. Noubir, A. Yilmaz. “Secure Multicast Groups on AD hoc Networks.” Proceedings of the 1st ACM Workshop Security of Ad Hoc and Sensor Networks, 2003. M.S. Bouassida, I. Chrisment, O. Festor: “Efficient Group Key Management Protocol in MANETs using Multipoint Relaying Technique.” Proceedings of ICNICONSMCL, 2006. Anuj Chandha, Younghe Liu, Sajal K. Das. “Group Key Distribution via Local Collaboration in Wireless Sensor Networks.” Proceedings of IEEE SECON, 2005.

[10] Hatem BETTAHAR, Abdelmadjid BOUABDALLAH, Yacine CHALLAL. “AKMP: An Adaptive Key Management Protocol for Secure Multicast.” Proceedings of Computer Communications and Networks, 2002. [11] Creighton T. Hager, Scott F. Midkiff. “Demonstrating Vulnerabilities in Bluetooth Security.” Proceedings of IEEE GLOBECOM, 2003. [12] C.T Hager, Scott F. MidKiff. “An Analysis of Bluetooth Security Vulnerabilities.” Proceedings of IEEE Conference, 2003. [13] Ketan Nadkarni, Amitabh Mishra. “A novel intrusion detection approach for wireless ad hoc networks.” Proceedings of IEEE Wireless Communications and Networking Conference, 2004. [14] TE Jonvik, P Engelstad, D van Tanh. “Ad-Hoc Formation of Bluetooth Piconet and IP Allocation in PAN.” IEEE 5th International Symposium on Wireless Personal, 2002. [15] P McDermott-Wells. “Bluetooth Scatternet models.” IEEE Potentials, Vol.23, No.5, pp.36-39, January 2005. [16] Y Wang, I Stojmenovic, XY Li. “Bluetooth Scatternet Formation for Single-hop Ad Hoc Networks Based on Virtual Positions.” Proceedings of IEEE Computers and Communications, 2004, ISCC 2004. [17] H Sreenivas, H Ali. “An Evolutionary Bluetooth Scatternet Formation Protocol.” Proceedings of the 37th Hawaii International Conference on System Sciences, 2004. [18] C Law, AK Mehta, KY Siu. “A New Bluetooth Scatternet Formation Protocol.” Mobile Networks and Applications, 2003 – Springer series, page 485-498, 2003. [19] C Law, KY Siu. “A Bluetooth Scatternet Formation Algorithm.” Proceedings of IEEE Global Telecommunications Conference, GLOBECOM'01, 2001. [20] M Kazantzidis. “Locally optimal Bluetooth Scatternet formation.” Technical Report # 010033 UCLA Computer Science WAM Lab, 2001. [21] Tommaso Melodia, Francesca Cuomo. “Ad hoc networking with Bluetooth: key metrics and distributed protocols for Scatternet formation.” Article Published in ELSEVIER, 2003. [22] X Zhang, G F Riley. “An On-Demand Bluetooth Scatternet Formation and Routing Protocol for Wireless Sensor Networks.” Proceedings of the sixth International Conference on Software Engineering, Proceedings of Artificial Intelligence, Networking and Parallel/Distributed Computing and First SCIS International Workshop on Self-Assembling Wireless Networks 2005. [23] CY Chang, PK Sahoo, SC Lee. “LARP: A Novel Routing Protocol for the Bluetooth Scatternet.” Proceedings of IEEE WOCN, 2005, Wireless and Optical Communications Networks, 2005. [24] CY Chang, PK Sahoo, SC Lee. “A Location-Aware Routing Protocol for the Bluetooth Scatternet.” Published in Springer series 2006, volume 40, page 117-135, 2006.