Citation
BlueSec

Material Information

Title:
BlueSec a Bluetooth stack extension for secure service access
Creator:
Anand, Sapanpreet
Place of Publication:
[Gainesville, Fla.]
Publisher:
University of Florida
Publication Date:
Language:
English

Subjects

Subjects / Keywords:
Access control systems ( jstor )
Authentication ( jstor )
Communications industries ( jstor )
Communications security ( jstor )
Computer technology ( jstor )
Data encryption ( jstor )
Databases ( jstor )
Human computer interaction ( jstor )
Mobile devices ( jstor )
Vendors ( jstor )
Bluetooth
Bluetooth technology ( lcsh )
Computer and Information Science and Engineering thesis, M.S ( lcsh )
Computer network protocols ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF ( lcsh )
Telecommunication -- Equipment and supplies ( lcsh )
Genre:
government publication (state, provincial, terriorial, dependent) ( marcgt )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Summary:
ABSTRACT: Bluetooth is a low-cost, low-power, short-range radio technology, originally developed as a cable replacement to connect devices such as mobile phone handsets, headsets, portable computers etc. Bluetooth devices operate at 2.4 GHz unlicensed ISM band using a frequency hopping spread sequence (FHSS). It has evolved over time and is on the way to becoming an industry standard for short-range wireless communications. Communication using the Bluetooth protocol stack involves discovering devices that are in the range, establishing connection, performing service discovery and then accessing those services. This thesis concentrates on the security aspect of the Bluetooth communications. Originally Bluetooth was developed just to form ad-hoc personal area networks (PANs) but in due course of time, other usages of Bluetooth have evolved which require secure communication between devices and hence, this aspect cannot be ignored.
Abstract:
Without incorporating security, Bluetooth will be confined only to its initial vision of a cable replacement technology for home users and not fit for more critical scenarios like Bluetooth enabled credit-card machines, ATMs, etc. This thesis aims at extending the Bluetooth stack for facilitating secure Bluetooth communications using mode 2 (service level enforced security) defined by the Generic Access Profile. The Linux-based Bluetooth stack by Axis Communications (OpenBT) is used for development. The BlueSec module is developed as a part of the Bluetooth kernel module, which implements the functionality needed for incorporating security. This generic module is in turn linked to vendor specific functionality which can be specified later by the vendor with the product and used with the Bluetooth stack.
Abstract:
A well-defined interface is provided to the user (developer) of the Bluetooth stack so that bigger applications like Bluetooth Software Suite for Linux can be built and the BlueSec module can be plugged in and used to perform security related tasks.
Thesis:
Thesis (M.S.)--University of Florida, 2002.
Bibliography:
Includes bibliographical references.
System Details:
System requirements: World Wide Web browser and PDF reader.
System Details:
Mode of access: World Wide Web.
General Note:
Title from title page of source document.
General Note:
Document formatted into pages; contains 70 p.
General Note:
Includes vita.
Statement of Responsibility:
by Sapanpreet Anand.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Anand, Sapanpreet. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
12/1/2012
Resource Identifier:
029833564 ( ALEPH )
1105558595 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

BLUESEC – A BLUETOOTH STACK EXTENSION FOR SECURE SERVICE ACCESS By SAPANPREET ANAND A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Sapanpreet Anand

PAGE 3

DEDICATED TO MY PARENTS, SISTER AND DIVJOT.

PAGE 4

ACKNOWLEDGMENTS I take this opportunity to thank my advisor, Dr. Abdelsalam Helal, for his invaluable guidance and support, and also for giving me an opportunity to work on this project. His constant motivation always inspired to work harder and harder. I would also like to thank Dr. Joachim Hammer and Dr. Michael Frank for serving on my committee. I would also like to thank my colleagues Sree Kuchibhotla, Pradeep Padala and Baldeep Anand for their suggestions and help. I am grateful to my parents and my sister for their encouragement and support and Divjot for showing her love and affection and always being there for me. Last but not least, I would like to thank God for always being besides me and helping me overcome every difficulty. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF TABLES............................................................................................................vii LIST OF FIGURES.........................................................................................................viii ABSTRACT.........................................................................................................................x CHAPTER 1 INTRODUCTION...........................................................................................................1 Goal and Motivation.......................................................................................................1 Organization of Thesis....................................................................................................2 2 BACKGROUND.............................................................................................................3 Security Basics................................................................................................................3 Overview of Bluetooth Technology................................................................................6 The Bluetooth Protocol Stack..................................................................................8 Bluetooth Usage.....................................................................................................12 3 THE OPENBT BLUETOOTH PROTOCOL STACK..................................................15 Features.........................................................................................................................15 Stack Architecture.........................................................................................................16 Software Development using OpenBT.........................................................................21 The Bluetooth Driver.............................................................................................21 Developing Applications using OpenBT...............................................................27 Modifying the Bluetooth driver module..........................................................27 Developing user applications...........................................................................28 4 BLUETOOTH SECURITY...........................................................................................30 Current Security in Bluetooth.......................................................................................30 Encryption Keys and Algorithms...........................................................................31 Pairing and Bonding...............................................................................................33 Key Management Procedures................................................................................35 v

PAGE 6

Analysis and Weaknesses.............................................................................................40 Scope of Thesis.............................................................................................................43 5 BLUESEC IMPLEMENTATION.................................................................................45 Architecture...................................................................................................................45 Requirements..........................................................................................................45 Design....................................................................................................................47 Software Implementation in OpenBT...........................................................................50 6 CONCLUSION AND FUTURE WORK......................................................................56 LIST OF REFERENCES...................................................................................................58 BIOGRAPHICAL SKETCH.............................................................................................59 vi

PAGE 7

LIST OF TABLES Table page 3-1 OpenBT ioctls..............................................................................................................25 5-1 Ioctls provided by BlueSec..........................................................................................50 vii

PAGE 8

LIST OF FIGURES Figure page 2-1 Bluetooth in action.........................................................................................................7 2-2 The Bluetooth Protocol Stack .......................................................................................8 2-3 HCI functional entities ................................................................................................10 2-4 L2CAP layer implementation......................................................................................10 2-5 The SDP Protocol........................................................................................................11 2-6 The Bluetooth Profile Structure...................................................................................12 2-7 Discovering a Bluetooth device...................................................................................13 2-8 Performing Service Discovery.....................................................................................13 2-9 Connecting to a Bluetooth service...............................................................................14 3-1 The HCI Layer.............................................................................................................17 3-2 The L2CAP layer.........................................................................................................18 3-3 The SDP Layer............................................................................................................19 3-4 The RFCOMM Subsystem..........................................................................................20 3-5 Source Tree for the OpenBT stack..............................................................................21 3-6 Default TTY Driver Configuration..............................................................................22 3-7 Stacked TTY Driver Configuration.............................................................................23 3-8 Glue Layers for the stack.............................................................................................23 4-1 LMP procedures involved in pairing...........................................................................34 4-2 Dedicated Bonding......................................................................................................34 4-3 General Bonding..........................................................................................................35 viii

PAGE 9

4-4 Generation of Unit Key...............................................................................................36 4-5 Generation of Initialization Key..................................................................................36 4-6 Authentication processes.............................................................................................37 4-7 Link key exchange with the unit key as link key........................................................38 4-8 Link key exchange with combination key as link key.................................................38 4-9 Generation of encryption key......................................................................................39 4-10 Encrypted Communication........................................................................................40 5-1 Bluetooth protocol stack with BlueSec.......................................................................48 5-2 BlueSec Module interaction........................................................................................49 5-3 Device Database entry.................................................................................................53 5-4 Service Database entry................................................................................................54 5-5 Screen Capture of sample user application..................................................................55 ix

PAGE 10

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science BLUESEC – A BLUETOOTH STACK EXTENSION FOR SECURE SERVICE ACCESS By Sapanpreet Anand December 2002 Chair: Dr. Abdelsalam (Sumi) Helal Department: Computer and Information Sciences and Engineering Bluetooth is a low-cost, low-power, short-range radio technology, originally developed as a cable replacement to connect devices such as mobile phone handsets, headsets, portable computers, etc. Bluetooth devices operate at 2.4 GHz unlicensed ISM band using a frequency hopping spread sequence (FHSS). It has evolved over time and is on the way to becoming an industry standard for short-range wireless communications. Communication using the Bluetooth protocol stack involves discovering devices that are in the range, establishing connection, performing service discovery and then accessing those services. This thesis concentrates on the security aspect of the Bluetooth communications. Originally Bluetooth was developed just to form ad-hoc personal area networks (PANs) but in due course of time, other usages of Bluetooth have evolved which require secure communication between devices and hence this aspect cannot be ignored. Without incorporating security, Bluetooth will be confined only to its initial x

PAGE 11

vision of a cable replacement technology for home users and not fit for more critical scenarios like Bluetooth enabled credit-card machines, ATMs, etc. This thesis aims at extending the Bluetooth stack for facilitating secure Bluetooth communications using mode 2 (service level enforced security) defined by the Generic Access Profile. The Linux-based Bluetooth stack by Axis Communications (OpenBT) is used for development. The BlueSec module is developed as a part of the Bluetooth kernel module, which implements the functionality needed for incorporating security. This generic module is in turn linked to vendor specific functionality which can be specified later by the vendor with the product and used with the Bluetooth stack. A well-defined interface is provided to the user (developer) of the Bluetooth stack so that bigger applications like Bluetooth Software Suite for Linux can be built and the BlueSec module can be plugged in and used to perform security related tasks. xi

PAGE 12

CHAPTER 1 INTRODUCTION Bluetooth is a low-cost, low-power, short-range radio technology, originally developed as a cable replacement to connect devices such as mobile phone handsets, headsets, portable computers, etc. Bluetooth devices operate at 2.4 GHz unlicensed ISM band using a frequency hopping spread sequence (FHSS). It has evolved over time and is on the way to becoming an industry standard for short-range wireless communications. Earlier, Bluetooth was just developed as a technology solution to the “get rid of the cables” concept with its usage being limited to home appliances and small personal area networks (PAN). With the passage of time, more critical usages have evolved like Bluetooth enabled credit card machines, ATM machines, etc. Goal and Motivation Since Bluetooth was initially developed to address trivial scenarios like synchronizing data from PDAs, wireless headsets and file transfer from one device to another, there was little need to incorporate strong security in the Bluetooth stack. This would have increased the overhead and moreover the devices are resource constrained so the goal was to involve minimal overhead and accomplish communication between devices without the use of wires. Since the technology was aimed to replace the cables, it had to be at least as efficient as its wired counterpart and also the cost factor had to be taken care of. Therefore, the core specifications released by the Bluetooth SIG (Special Interest Group) incorporated weak security management procedures, which had several vulnerabilities. Without strong security, Bluetooth will only be feasible for applications 1

PAGE 13

2 that do not require secure communications. If it has to really make a revolution in the wireless industry, it has to be extensible to more critical real life application scenarios. Having a world where we have millions of Bluetooth devices interacting with each other would only be possible if everyone has a proper feeling of security. This has been the motivation to delve into the security aspect of Bluetooth and provide a solution that fits nicely into the existing technology. The goal is to provide a solution that can be incorporated into the existing stack architecture and is flexible according to the different security needs of different application scenarios. Organization of Thesis The thesis aims at providing a solution, which facilitates secure Bluetooth communications. Chapter 2 provides an overview of various security concepts and an overview of the Bluetooth technology. Chapter 3 describes the Linux-based Bluetooth stack (OpenBT) by Axis Communications in detail. 1 This protocol stack is used for development purposes. Chapter 4 delves into the implementation of current security in Bluetooth, its limitations and the proposal to overcome some of the limitations. Chapter 5 discusses the implementation of the proposed solution in detail. It describes the proposed architecture in detail, shows how the solution is fitted into the OpenBT Bluetooth Stack and does an analysis of the proposed solution.

PAGE 14

CHAPTER 2 BACKGROUND Before going into Bluetooth Security in detail, we explain some concepts about security in general. This chapter also gives an overview of the Bluetooth technology. Basically, the security of a system is a combination of its ability to support System availability Data Integrity Data Confidentiality A failure of a system to protect any of these characteristics amounts to a security violation or weakness. Some of the terms used in computer and network security are explained as follows. Security Basics Following is a glossary of key terms in security. 2 Access control. Access control is any mechanism by which a system grants or revokes the right to access some data, or perform some action. This mechanism controls what operations the user may or may not make by comparing his identity with an access control database. Access Control systems include File permissions, such as create, read, edit or delete on a file server. Program permissions, such as the right to execute a program on an application server. Data rights, such as the right to retrieve or update information in a database. Authentication. Authentication is to positively verify the identity of a user, device, or other entity in a computer system, often as a prerequisite to allowing access to 3

PAGE 15

4 resources in a system. It may be implemented using Credentials (User ID and Password), Smart Cards, Authentication Server or a Public Key Infrastructure. Authorization. Authorization is a process of determining what type of activities or access is permitted on a network. It is the usually the next step after authentication. Once a user has been authenticated, he may be authorized to have access to a particular service. Availability. System availability is whether a system is available for use by its intended users. It is an integral component of security and it should be assured that information and communications services will be ready for use when expected. Challenge-Response. Challenge-Response is a common authentication technique in which an individual is prompted (the challenge) to provide some private information (the response). Confidentiality. Confidentiality is also an integral component of security. It is whether the data and information stored on the system is protected against unintended or unauthorized access or not. Since the system might be used to manage sensitive information, confidentiality is a measure of the ability of the system to protect its data. Host system. Host System is a computer on the network, which provides services to users or other computers on that network. Integrity. Integrity is whether the data and information stored on a system is reliable and can be trusted. It is the assurance that the information will not be accidentally or maliciously altered or destroyed. It is a measure of the quality of the information stored in a system and is also an integral component of security. Encryption. Encryption is a process of translating a message, called the plaintext, into an encoded message, called the ciphertext. This is usually accomplished using a

PAGE 16

5 cryptographic key and a cryptographic cipher. Encryption can be of two types: symmetric encryption (where a single secret key is used for both encryption and decryption) and asymmetric encryption (where a pair of keys is used – one for encryption and the other for decryption). User authentication. User authentication is the process that verifies a user’s identity to ensure that the person requesting access to a service or network is in fact, that person to whom access is authorized. Security. The security of a system is a combination of its ability to support system availability, data integrity and data confidentiality. A failure to protect any of these characteristics is considered a security weakness or flaw. Security policies. A security policy is a set of objectives, rules of behavior for users and administrators, and requirements for system configuration and management that collectively are designed to ensure security of computer systems. This might include access control rules, usage of access logs, procedures for granting and revoking system access, account termination, host system administration practices, maintaining security related information about services and devices, etc. Security architecture. Security architecture is a detailed description of all aspects of a system that relate to security, along with a set of principles to guide the design. It describes how the system is put together to satisfy the security requirements. Trust. Trust is the ability of one party to rely on the availability of the other party, the integrity of information provided by the other party, or the ability of the other party to protect confidentiality of sensitive information.

PAGE 17

6 Trusted Computing Base (TCB). It is the totality of protection mechanisms within a computer system including hardware, firmware and software – the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or a system. Overview of Bluetooth Technology Many people have envisioned wireless devices effortlessly communicating with one another. In this panacea, devices of all types begin to correspond just by coming within proximity of each other. The Bluetooth wireless technology, although begun as a simple “get rid of the cables” concept, has come to fulfill this vision of many people who feel that the technology will go a long way in realizing these dreams. It is a fast-growing technology with a significant increase in the number of devices shipped every year. Bluetooth enables connectivity to become simple, seamless and intuitive. The Bluetooth system is complex, full-featured and has many components and layers of abstraction. This is necessary for it to be simple, intuitive and transparent to the user. The technology is rapidly finding its way into mobile devices, which are increasing day by day. There are a lot of scenarios in which the technology can find its application. It ranges from handheld devices, PDAs, palmtops, headsets, etc. to Bluetooth enabled credit card machines, ATM machines, printers and LAN access points. Although there are a lot of potential areas of application of Bluetooth, a lot of work being done and products being made are in the beta stage and a lot of testing is to be done. But as time passes, Bluetooth is envisioned to make its way into our lives and make our lives easier and more sophisticated at the same time. The figures below show some scenarios in which Bluetooth technology is in action.

PAGE 18

7 Figure 2-1. Bluetooth in action The Bluetooth technology specifications are defined and promoted by the Bluetooth Special Interest Group (SIG). There are more than 1800 companies in the Bluetooth SIG. The aim of the Bluetooth specification is to sell more of the core promoters’ products. Since Bluetooth is a cable replacement technology, it has to be as

PAGE 19

8 easy and convenient as plugging a cable and at least as reliable as the cable it replaces. It must also be resilient since being a wireless technology; it has to cope with more errors than a wired equivalent. Also, it cannot be more expensive than the cables and since it is designed for mobile devices, it should be able to run on batteries with low power and voltage requirements. So the aim of Bluetooth is to be a technology that is widely available, cost-effective, easy to use and reliable. The Bluetooth Protocol Stack The Bluetooth Specification Protocol Stack is as shown in the figure below. Figure 2-2. The Bluetooth Protocol Stack 3 The various layers of the stack are described below in detail Bluetooth radio. This is the lowest layer in the specification and defines the requirements of the Bluetooth transceiver device operating in the unlicensed 2.4 GHz

PAGE 20

9 ISM frequency band. It defines requirements for frequency bands and channel arrangement, transmitter characteristics, receiver characteristics etc. Baseband. The Baseband layer in Bluetooth is analogous to the physical layer in the OSI Network Architecture. The baseband functionality includes physical link management, error correction, data whitening, hop selection etc. The baseband protocol is designed to function as a link controller which works in tandem with the link manager to carry out routines at link level like connection management, power control, asynchronous and synchronous link management, packet handling, performing paging and inquiry etc. LMP. The LMP (Link Manager Protocol) communicates with other Lilnk Managers and performs tasks like link set-up, authentication, link configuration etc. The protocol works using single-slot packets known as PDU (Protocol Data Units) that are used for communication between the devices. There can be many types of LM PDU in a specific format defined by the specifications in order to provide the above functionalities. HCI. The HCI (Host Controller Interface) basically provides a command interface to the Link Manager and Baseband Controller. It provides access to hardware status and control registers. Using the HCI commands, a Bluetooth host can control a Bluetooth module and its baseband capabilities. It is further divided into three parts – the host, the transport layer and the host controller. It makes the hardware specific functionality transparent to the host. It allows the higher layers to run on a separate host processor and lower layers to be implemented in firmware such as a PCMCIA card. This would also enable the higher layers to be implemented independent of different hardware by different manufacturers. The following figure shows the HCI functional entities.

PAGE 21

10 Figure 2-3. HCI functional entities 3 L2CAP. The L2CAP (Logical Link Control and Adaptation Protocol) sits on the baseband protocol and is in the data link layer. It supports higher-level protocol multiplexing and provides connection-oriented and connectionless service to the higher-level protocols. It is also responsible for segmentation and reassembly. The packet size limit is 64KB. The following figure shows the events and actions performed by an L2CAP layer implementation. Figure 2-4. L2CAP layer implementation 3

PAGE 22

11 RFCOMM. The purpose of the RFCOMM protocol is basically to provide serial port emulation over the L2CAP protocol. It supports up to 60 simultaneous connections between two Bluetooth devices. SDP. The SDP (Service Discovery Protocol) provides functionality for applications to discover the services available from a particular device and also attributes related to those services if any. It uses a request/response model where each transaction consists of one request PDU and one response PDU. Figure 2-5. The SDP Protocol 3 Bluetooth profiles. The Bluetooth are a vertical slicing of the Bluetooth protocol stack. They describe how the implementation of user models are to be accomplished. The user models are basically use-case scenarios of the Bluetooth technology. A profile defines certain options to be mandatory and others to be optional for conformance to that particular profile. Conformance to profiles is necessary to avoid interoperability problems between products from different vendors. The profiles have a hierarchical structure as shown below in the figure.

PAGE 23

12 Figure 2-6. The Bluetooth Profile Structure 3 Bluetooth Usage This section describes the various steps to be performed by two devices to connect, communicate and use services using the Bluetooth technology. Following are the steps involved for communication between device 1 and device 2. Device discovery. This is the first stage where the device finds out what other Bluetooth enabled devices are in the range. This is accomplished by performing an inquiry. Only those devices, which are in the discoverable mode, will be discovered. The discovering device send an enquiry packet with a General Inquiry Access Code (GIAC) and the discoverable device responds to this packet. After that the two devices have to synchronize their frequency hopping pattern. The following figure shows how device discovery is performed between two devices.

PAGE 24

13 FHS A B Inquiry Figure 2-7. Discovering a Bluetooth device Performing service discovery. The next stage is to find out what services are offered by the discovered device. For this, the Service Discovery Protocol (SDP) is used. An L2CAP connection is formed between the two devices to perform the service discovery. After this has been accomplished, the link is shut down and a separate link will be established in future to use the discovered service. The following figure shows how a device performs service discovery. B Disconnect Set up SDP connection A Set up L2CAP connection Set up Baseband Link Figure 2-8. Performing Service Discovery 4

PAGE 25

14 Using the service. This stage is after the service discovery and a separate L2CAP connection is set up and the application can use the service. The application may also configure the link according to its requirements using the Link Manager. The following figure shows how a connection is formed to use a service (in this case a DUN service over RFCOMM). B Set up DUN connection A Set up RFCOMM connection Set up L2CAP connection Figure 2-9. Connecting to a Bluetooth service 4 Hence, we have provided an overview of the Bluetooth technology in general and seen how the technology works and how the technology is used. The next step will be to study the popular linux-based Bluetooth stack OpenBT. The next chapter would give a detailed description of the Bluetooth stack (OpenBT) by Axis Communications Inc, which is used for development purpose.

PAGE 26

CHAPTER 3 THE OPENBT BLUETOOTH PROTOCOL STACK This chapter discusses the OpenBT Bluetooth protocol stack in detail. Sourceforge hosts the OpenBT project and the latest version can be found at http://sourceforge.net/projects/openbt . Bluetooth is an open standard and Linux is open source. This made Linux-based Bluetooth stacks an obvious choice for development. Moreover, commercial products like access points, laptops etc. are being deployed with Linux so it is also gaining market popularity. The OpenBT stack is gaining a lot of popularity and a lot of developers are using this stack. The following section discusses the features of the OpenBT protocol stack. Features Kernel versions. The kernel versions supported by OpenBT are 2.0.x – 2.4.x. It can also be used with uCLinux. The source is available and is up to the developers to port to whatever kernel version they require. Hardware platforms. The hardware platforms supported are X86, ARM, MIPS and PowerPC. If required, it can just be cross-compiled for a non-x86 platform. Bluetooth protocol support. It supports the protocols like Host Controller Interface (HCI), Logical Link Control and Adaptation Protocol (L2CAP), Service Discovery Protocol (SDP), RFCOMM, HCI-UART and HCI-USB. It does not have support for Synchronous Connection Oriented (SCO) connections used for voice. SDP support. OpenBT provides an SDP server daemon to handle SDP requests from remote devices. There is no provision for dynamic registration of services. The OpenBT uses a static XML database for storing services attributes. Also, an application developer has to frame his own SDP request packets according to the standard format defined by the SIG and also parse the resulting responses. API. The OpenBT provides a set of device files that can be used by applications. These are TTYs (terminals) and follow the standard Linux API for TTY drivers. 15

PAGE 27

16 The Bluetooth stack provides a set of blocking ioctl calls that are used to control the stack. License Terms. The OpenBT project is released under the AXIS OpenBT Stack License, which is basically a GPL with some additional freedoms. The advantages of the OpenBT stack are that it is freely available, the full source code is accessible, it can be used on many platforms and can be ported to many kernel versions. However there are also some drawbacks associated with it like the lack of proper documentation, no interface for dynamic SDP registration, lack of SCO support, lack of a central stack manager etc. Stack Architecture This section explains how the various layers in the Bluetooth stack are implemented in the OpenBT project starting from the bottom and going up to the higher layers. Host Controller Interface (HCI). HCI basically provides hardware abstraction by hiding the hardware details of the Bluetooth module from the upper logical layers. Using the HCI commands, a Bluetooth host can control a Bluetooth module and its baseband capabilities. It makes the hardware specific functionality transparent to the host. It allows the higher layers to run on a separate host processor and lower layers to be implemented in firmware. In the OpenBT stack, this layer provides an interface that abstracts Bluetooth hardware, baseband and radio details from the applications. Access to the Bluetooth hardware is obtained by executing HCI commands through ioctls. The HCI layer is itself divided into three modules – the HCI driver, the HCI transport and the host controller. The last one is not implemented in OpenBT. The following figure shows the HCI layer and its modules.

PAGE 28

17 Host Controller HCI Transport HCI Driver Figure 3-1. The HCI Layer 5 The HCI driver is the highest module that interfaces with logical higher layers of Bluetooth stack where Bluetooth commands and events can be invoked to operate on Bluetooth hardware. It communicates with the host controller. The HCI transport module is for the purpose of providing separation between the physical and the logical interface. It abstracts the type of transport of the physical bus driver from the host to the Bluetooth hardware. The host controller provides access and control to various capabilities of Bluetooth vendor-specific hardware. Logical Link Control and Adaptation Protocol (L2CAP). The purpose of the L2CAP layer is basically to provide higher level protocol multiplexing, segmentation and reassembly, data flow control and management and providing connection oriented and connectionless service to upper layers. It basically consists of 4 modules: event handler, segmenter/desegmenter, state handler and action sender. The following figure shows the L2CAP layer with the modules.

PAGE 29

18 Segmenter/ Desegmenter State Handler Action Sender Event Handler Figure 3-2. The L2CAP layer 5 The event handler handles messages from the upper and lower layers. It can receive messages from the response module in SDP layer, the command router, the control flow module in the RFCOMM layer and the HCI driver (for access to hardware). The segmenter/desegmenter basically translates incoming events from other layers’ messages so that the state handler can understand. After receiving messages provided by the event handler, it performs parsing into a format that is understandable to the state handler. The state handler module implements a Deterministic Finite Automata (DFA) to decide the next course of action based on the input and the current state of the automata. The action sender module handles the sending of messages to other layers in the protocol stack. The messages can be to the modules from which the event handler receives the messages. It receives messages from the segmenter/desegmenter. Service Discovery Protocol (SDP). The service discovery protocol is used to discover the available services in a particular device so that the other devices can use them. The OpenBT stack implements the SDP layer by dividing it into 4 modules – the request module, the storage access module, the response module and the XML storage unit. The following figure shows the implementation of the SDP layer and the modules.

PAGE 30

19 XML Storage Unit Request Module Storage Access Module Response Module Figure 3-3. The SDP Layer 5 The function of the request module is to receive service requests and to send them to the storage access module. The applications send service access requests to this module. It also receives messages from the action sender in the L2CAP layer to handle data and voice connections, and the serial port emulation sub-layer to query the SDP database that stores the information and attributes of available services. The storage access module basically acts as a router for requests coming from the request module and going to the XML storage unit. The response module sends the results of the service requests to the other layers. It receives messages from the XML storage unit routed via the storage access module. The XML storage unit acts as the static database for storing definitions, attributes etc. of various services available in a device. It consists of a tokenizer and parser. The data is stored in an XML file and the services can then be queried using attributes from here. Serial Port Layer (SP). The serial port layer is responsible for simulating a serial port connection between two Bluetooth devices using a virtual serial port. This enables applications to use the serial port without any other modification by sending data to the

PAGE 31

20 virtual port. This layer itself consists of 3-layered subsystems – serial port emulation, RFCOMM and service discovery layer. The serial port emulation subsystem provides emulation of a serial port by creating a virtual serial port over the RFCOMM subsystem. It provides an API to applications that require using a serial port in the application layer. RFCOMM. RFCOMM is basically used to provide a transport protocol for serial communication over radio frequency. It also has to provide a transparent data stream and control channel to connected devices wishing to use serial port emulation. The following figure shows the RFCOMM implementation. Control Buffer Command Router and Flow Emulation Status/State Reporter Figure 3-4. The RFCOMM Subsystem 5 The command router and flow control module is to manage the transport and routing of all messages passed through the RFCOMM subsystem. It provides two-way connectivity to the serial port emulation subsystem and the L2CAPs event handler and action sender modules. It also has two-way connectivity with the buffer module and the emulation status/state reporter. The emulation status/state reporter keeps track of the connections based on current states and events. The buffer module provides buffering needs to the RFCOMM subsystem.

PAGE 32

21 Higher Layers – The other higher layers and profiles implemented in OpenBT are the TCS-Binary (Telephony Control Specification), PPP networking and modem emulation. Other profiles can be built on top of the stack module. Software Development using OpenBT The following figure shows the source tree of the OpenBT Bluetooth stack. OpenBT Apps Libs Linux Figure 3-5. Source Tree for the OpenBT stack The actual kernel Bluetooth driver is the bt.o module, which is built in the linux/drivers/char/bluetooth directory of the OpenBT source tree. This loadable module implements a TTY (terminal) driver and an ldisc, the line discipline that affects how the data stream to a terminal is interpreted. The Bluetooth Driver The Bluetooth driver bt.o is loaded into the kernel by the insmod command. It is registered as a char driver with the name bt having major number 124. The line discipline is registered under the name bt_ldisc. The figure 3-6 shows the default TTY driver configuration after loading the bt.o module.

PAGE 33

22 tty_io n_tty n_tty bt bt_ldisc Serial Driver Figure 3-6. Default TTY Driver Configuration Both, the bt and the serial TTY drivers are using N_TTY ldisc as the adapter. In OpenBT, we have the application change the serial driver’s line discipline to be bt_ldisc instead of N_TTY. This is how the Bluetooth driver talks to a Bluetooth card attached by a serial cable. The devices formed are normal TTY terminals. These devices use bt as the driver. So, any data sent to these devices is handled by the Bluetooth line discipline. In this way, bt_ldisc routes all data to and from the serial port through the Bluetooth driver. That is where all the parsing and assembly takes place. The figure 3-7 shows the stacked TTY driver configuration showing the forwarding of all data through the stacked Bluetooth driver.

PAGE 34

23 tty_io n_tty bt Serial Driver bt_ldisc Figure 3-7. Stacked TTY driver configuration The following figure shows the glue layers for the stack. “APPLICATION” (here: ttyBT) bt_receive_top() bt_receive_lower_stack() THE S TACK bt_write_lower_driver() bt_write_top TOP BOTTOM “PHYSICAL DRIVER” (here: serial driver) Figure 3-8. Glue layers for the stack OpenBT creates two types of Bluetooth device files: data device files and control device files. There are 7 data device files namely /dev/ttyBT [0-6] and one control device

PAGE 35

24 file named /dev/ttyBTC. The major number is 124 (being the major number of the Bluetooth driver module bt) and the minor numbers are from 0-7. The data device files are all instances of RFCOMM TTY’s. When they are open and connected, they behave like serial ports. The significance of the minor number is that it is used internally by the driver to index a connection session. Hence there are seven session objects maintained by the driver. Within the driver, each RFCOMM session has a state machine. When the device file is opened, the line number comes from the minor number of the device file. RFCOMM supports multiplexing and can provide multiple sessions simultaneously. When an RFCOMM device file is opened, the process gets exclusive access to it. The other processes can then establish RFCOMM connections, but this is the only one that can transfer data through it. The OpenBT stack does not have a central stack manager entity that can control the running of the stack. Applications can randomly issue ioctl calls and send commands to the stack. The /dev/ttyBTC control device file can be opened by any number of processes at the same time and hence they can issue ioctls to the stack. There are no device files for protocols like SDP, L2CAP etc. and they can be accessed using ioctl calls on any of the devices. The RFCOMM device files are TTY’s, which facilitates setting up line disciplines sitting on top of the RFCOMM layer. The various ioctls provided by the OpenBT stack are described in the table 3-1. The ioctls range from commands to connect, disconnect, perform service discovery, configuring the link, performing inquiries, initializing and shutting down the stack, getting the status of connections, obtaining vendor related information etc. to commands used for implementing security at the link level.

PAGE 36

25 Table 3-1. OpenBT ioctls 6 Name Description BT_SDP_REQUEST Sends an SDP request and blocks (with no timeout) until the response returns. BTCONNECT Requests an SDP or RFCOMM connection with a remote device. Blocks until the connection operation completes or, in the case of RFCOMM, a timeout occurs. BTDISCONNECT Disconnects an existing RFOMM connection. Blocks until the disconnect operation completes or a timeout occurs. BTWAITFORCONNECTION Checks if a connection exists on the specified line and, if not, blocks until one appears on that line. Does not return on stack shutdown. BTWAITNEWCONNECTIONS Blocks until a new connection appears on any line. Does not return on stack shutdown. BTISLOWERCONNECTED Checks if a connection exists on the specified line and returns the result in the out-parameter. BTINITSTACK Initializes the driver. If the driver is already initialized it implicitly performs the equivalent of BTSHUTDOWN first. BTSHUTDOWN Shuts down the driver, disconnecting all active connections and hanging up their associated TTY’s. BTREADREMOTEBDADDR Returns the BD ADDR of the last remote device to establish a link-level connection in the out-parameter. BTISINITIATED Checks if the driver has been initialized yet and returns the Boolean result in the out-parameter. BTHWVENDOR Returns a string describing the name of the hardware, which the stack was compiled to support. Warning: currently this does not limit the size of the string being copied into the users buffer.

PAGE 37

26 Table 3-1. Continued. NAME DESCRIPTION HCIINQUIRY HCILINKKEYREPLY HCILINKKEYNEGATIVEREPLY HCIPINCODEREPLY HCIPINCODENEGATIVEREPLY HCISWITCHROLE HCISETLOCALNAME HCIAUTHENTICATION_REQUESTED HCISETCONNECTION_ENCRYPTION HCIRESET HCICREATE_NEW_UNIT_KEY HCIREADSTOREDLINKKEY HCIWRITESTOREDLINKKEY HCIDELETESTOREDLINKKEY HCIREADSCANENABLE HCIWRITESCANENABLE HCIWRITEPAGESCANACTIVITY HCIWRITECLASSOFDEVICE HCIREAD_AUTHENTICATION_ENABLE HCIWRITE_AUTHENTICATION_ENABLE HCIREAD_ENCRYPTION_MODE HCIWRITE_ENCRYPTION_MODE HCISET_EVENT_FILTER HCIREADLOCALBDADDR HCIENABLEDUT HCISETBAUDRATE HCIWRITEBDADDR HCISENDRAWDATA BTSETMSSWITCH These ioctls all provide access to the HCI Protocol commands. See the HCI chapter of the Bluetooth Core Specification for a description of what these commands are used for. Commands, which do not provide any status information back to the Host usually, return immediately. Commands, which expect a Command Complete event usually, block until either the Host Controller sends this event or a timeout occurs.

PAGE 38

27 Developing Applications using OpenBT This section describes how to develop user-mode as well as kernel-more applications using the OpenBT stack. Modifying the Bluetooth driver module The bluetooth driver module is built in the linux/drivers/char/bluetooth directory in the OpenBT source tree. This directory contains all the source files for the Bluetooth driver, implementing the functionality of the layers in the Bluetooth stack. To add a layer to the Bluetooth stack or to make any other modifications in the stack, the kernel mode application has to reside in this directory. According the changes in the makefile should be made so that the new module is built with the driver and is loaded into the kernel. The header files for the corresponding C source files should go into the linux/include/linux/bluetooth directory in the source tree, which is declared as the default include directory for the driver. The common definitions for the structs, etc. needed by the Bluetooth driver are defined in the file btcommon.h so this should be included wherever needed. The OpenBT stack currently has support for hardware like Digianswer, CSR, Ericsson, Infineon, etc. It also has USB support and it can also be used without any hardware using HCI_EMULATION (which can typically be accomplished by connecting two computers using a null modem cable). So this is a major advantage of the OpenBT stack that it can be used without any hardware by just emulating the HCI hardware control commands. The stack can be extended to increase the functionality it provides. New functionality can be incorporated and ioctls registered to execute that functionality. The ioctls provided by the stack are defined in the btcommon.h source file. The developer can

PAGE 39

28 add his own functionality and register the ioctls so that an application can use that to give commands to the stack. Developing user applications There are some user applications provided in the experimental directory in the source tree. Also, we have a GUI (BluetoothPN) application and an SDP server application provided by OpenBT. To build a new application that can communicate with the stack requires initializing the stack, opening the control device and then communicating via the ioctls provided by the driver module. Following are the steps involved in creating a basic application. Initializing the Bluetooth stack. The Bluetooth driver should use the serial driver to talk to the hardware. For this purpose, we need to hook up the Bluetooth driver on top of the serial driver so that when it sends data, it sends it through the serial driver through the serial port; and when the serial driver receives data from the serial port it pushes it up to the Bluetooth driver. The settings of the serial driver also need to be changed. Preparing the serial driver. This involves opening the serial port and making it a raw TTY. It has to be made raw because otherwise it will try to filter the data stream looking for special characters. The termios struct is used and the attribute values changed according to the requirements. The ioctl commands used are TCGETS and TCSETS. Stacking the drivers. After applying appropriate settings to the serial driver, it can be connected to the Bluetooth driver. This involves switching the serial port’s line discipline to the Bluetooth line discipline. The ioctl command used for this is TIOCSETD. This causes the Bluetooth line discipline’s open () routine to be called, passing in the serial port’s TTY. This gives the Bluetooth stack a handle to the serial TTY driver so it can use it as the lower layer.

PAGE 40

29 Starting communication between the PC and the card. Now since the drivers are stacked, the host can talk to the hardware. For this, the stack has to be initialized first of all, using the BTINITSTACK ioctl. This has to be done after opening the control device /dev/ttyBTC and obtaining a handle to it. In a similar way, the BTSHUTDOWN ioctl is used to shut down the stack. Once the stack is initialized, the application can be made to perform whatever operations we want. For e.g. we can start an SDP session on top of it, or an application might want to create an RFCOMM connection and use the serial port emulation. The BTDISCONNECT ioctl can be used to close a connection. This was a basic description of the OpenBT stack. Being open source, there are many developers working on it trying to make it more robust and complete. Hence, it is used for development purpose in this thesis.

PAGE 41

CHAPTER 4 BLUETOOTH SECURITY Although Bluetooth has been touted as an emerging technology for mobile Commerce applications, its limited security model poses a significant hindrance to its utility in such applications. Current Bluetooth security architecture is sufficient for home networking applications but, certainly not for credit card transactions. Without proper security, Bluetooth would only be limited to its initial vision of a “get rid of cables” technology and would not be able to affect our lives to the extent it is capable to. Cable based communication is inherently secure. However, since anyone could potentially listen to a wireless transmission, security is a key issue for wireless communication systems like Bluetooth. This chapter first discusses the current security in Bluetooth, then analyses its weaknesses and then proposes an extension to the current Bluetooth protocol stack to incorporate security at the service level. Current Security in Bluetooth The Bluetooth specification includes security features at the link-level. Authentication and encryption are supported, which are based on a secret link key that is shared by a pair of devices. Pairing and Bonding procedures are carried out to generate the link keys and perform authentication. The Bluetooth Generic Access Profile (GAP) defines three security modes. Mode 1. The most insecure mode in which the Bluetooth device does not initiate any security procedures and allows other Bluetooth devices to establish connections with it. 30

PAGE 42

31 Mode 2. Service level enforced security (i.e., security is enforced after an L2CAP link is established). It allows enforcement of security policies and fine-grained application layer controls on top of the lower layer protocols. Each service is free to implement its own security procedures. Mode 3. Link level enforced security (i.e., security is enforced before the establishment of the link). This is enforced by the Link Management Protocol (LMP). There are several levels of trust used by Bluetooth devices and services. Devices have the following three levels: Trusted device. One with which a trust establishment has been done and has access to all services. Untrusted device. One that has a restricted access to services. Unknown device. Also an untrusted device. Services also use three modes of trust, which are combinations of authentication and authorization, as follows: Services that require authentication and authorization. Trusted devices have access automatically. Untrusted devices need authorization. Services that require only authentication. No Authorization required. Services accessible by all devices. Neither authentication nor authorization is required. Encryption Keys and Algorithms This section introduces the various keys and the encryption algorithms used in the Bluetooth security mechanisms. The encryption keys can basically be divided into 3 main types – link keys, sub keys and the resulting encryption keys.

PAGE 43

32 Link key. Link keys are used for authentication procedures between Bluetooth devices and for generation of encryption keys. They can be of various types and generated by different algorithms. They can be temporary (used during a current session) or semi-permanent (used for many sessions). Master key. This key is used for communication where one device (master) is controlling several other devices (slaves) and it is a multipoint communication. It may act as the link key for that session. It is generated using the E22 algorithm * . Unit key. This is a semi-permanent key that is generated in every unit mostly at the time of manufacture. It can be changed at any time though it is not changed very often. Combination key. The combination key is dependant on two units. It is unique for every new combination. It is typically created at the end of the pairing process. Initialization key. This is a link key used for a single session and is created at the time of initialization of the unit. This is generated using the E22 algorithm and uses the PIN number of the Bluetooth device. Encryption key. This key is derived from the current link key using the E3 algorithm. It is used when encrypted data communication is required. There are 5 encryption algorithms used in Bluetooth security mechanisms known as the “E” algorithms. With the exception of E0, all are based on the SAFER+ algorithm. They are explained as follows. E0 – Used for cipher stream generation (encryption engine). E1 – Used for authentication. E2 – Used for authentication key generation. It creates the keys to be used by the E1 authentication algorithm. Two modes are used depending on key to be generated. * E-algorithms used for key generation. They are based on the SAFER+ algorithm.

PAGE 44

33 E21 – Uses a 48-bit Bluetooth address to create unit keys and combination keys. E22 – Uses a user supplied PIN to create initialization keys and master key. E3 – Used for generating the encryption key. Pairing and Bonding Security procedures in Bluetooth communication are established by what is known as pairing and bonding. Two devices are said to be bonded if they are sharing a common link key for their communications. The bonding procedure involves creating a link for creating and exchanging a common link key. Pairing is the collective link level procedure of link level authentication and link key generation. Bonding can be either general bonding or dedicated bonding. In dedicated bonding the devices only perform link key generation whereas general bonding would involve the intervention of higher layers to initialize their security parameters. At the user level, Bluetooth bonding is used to collectively refer to pairing and bonding procedures. As shown in figure 4-1, A sends a connection request to B, then they undergo the pairing process, and then this link is teared down after the link key has been exchanged. A and B are then said to be bonded. The figures 4-1, 4-2 and 4-3 show the pairing and bonding procedures for two devices A and B. The messages starting with LMP are the messages used by the Link Manager Protocol (LMP). As can be seen in the figures, the dedicated bonding procedures are only until the link key is generated and pairing is done. The general bonding also involves initialization of security parameters by higher layers for performing their own security proceudures.

PAGE 45

34 Link Key Negotiation A B Authentication Figure 4-1. LMP procedures involved in pairing LMP_detach Pairing LMP_accepted LMP_host_connection_req Paging A B Figure 4-2. Dedicated Bonding

PAGE 46

35 LMP_detach Channel Release Higher Layer Initialization Channel Establishment A B Pairing LMP_accepted LMP_host_connection_req Paging Figure 4-3. General Bonding Key Management Procedures Several keys are used throughout the authentication and encryption process. Key generation and initialization is done as follows. Generation of unit key. This key is normally generated once in the device lifetime when it boots up for the first time. It is generated using the BD_ADDR (a 48-bit unique

PAGE 47

36 device address) and a random number, and is stored in the device permanent memory. The figure 4-4 shows how the unit key is generated. Figure 4-4. Generation of Unit Key 7 Generation of initialization key (used as a temporary link key). This key is generated in both the devices trying to communicate. The generation is done using a random number IN_RAND (which is passed by one device to another in clear), the PIN and the PIN length. Hence it can be represented as K init = E22 (IN_RAND, PIN, PIN LENGTH) where, E22 is the algorithm used for the generation of the initialization key, K init. The figure 4-5 shows how the initialization key is generated. Figure 4-5. Generation of Initialization Key 7 Authentication using initialization key in each device. Suppose device A wants to communicate with device B. The following steps will take place:

PAGE 48

37 A performs an inquiry scan and obtains B’s BD_ADDR. A sends a random number (challenge) to B (AU_RAND). Both A and B compute SRES and SRES’ using the E1 algorithm with BD_ADDR, K init, and AU_RAND as the parameters. B sends SRES’ to A. If SRES = SRES’, then the authentication procedure is successful and the devices can proceed with further communication. Successful Authentication depends on whether the two devices share the same initialization key or not; which in turn depends on whether they share the same PIN or not. The figure 4-6 shows this process of authentication. Figure 4-6.Authentication processes 7 Generation of link key in each device. The link key to be decided upon to be used in future communication by the two devices could be either the Unit Key of either device or a Combination Key that is a function of parameters of both the devices (hence unique for each pair). Link key exchange. If the Link Key has to be a Unit Key then it is sent to the other device by XORing with the initialization key. If the Link Key has to be a Combination

PAGE 49

38 Key, both sides generate random numbers and calculate temporary keys using the E21 algorithm with the random number and BD_ADDR as the parameters. Each device computes the other device’s key and then the combination key is computed by XORing the two keys. Figure 4-7. Link key exchange with the unit key as link key 7 Figure 4-8. Link key exchange with combination key as link key 7 Authentication using link key. This authentication procedure is the same as the initial authentication (that uses initialization key). The only difference is that now the shared link key is used.

PAGE 50

39 Generation of encryption key in each device. If encryption is required, then the encryption key is generated using the E3 algorithm with parameters being the Link Key, a ciphering offset and a random number. The figure 4-9 shows how the encryption key is generated. Figure 4-9. Generation of encryption key 7 Encrypted communication: The encrypted communication is carried out by performing encryption on the data using a cipher key K cipher that is generated using the E0 algorithm with the parameters being the encryption key, BD_ADDR and the clock. This key is then XORed with the data for encryption purposes. After this, the data can be encrypted and the encrypted communication can take place.

PAGE 51

40 Figure 4-10. Encrypted Communication 7 Analysis and Weaknesses This section analyzes the current Bluetooth security and discusses the potential weaknesses in it. First we present some scenarios, which invariably require secure communications. Communications involving credit card transactions such as a person making payments in a shopping mall by using a Bluetooth enabled credit card machine and his PDA or a payment made at the gas station using his PDA and the Bluetooth enabled machine. Since this involves the transfer of the credit card number, verification code, etc., it should be a secure transfer. Communications involving bank account numbers such as using a Bluetooth enabled ATM machine that can be used to transfer money to and from bank accounts. Since this also involves critical data transfers, it has to be inherently secure.

PAGE 52

41 LAN access points providing facility to clients for accessing services on the LAN. Since this involves various users logging on to the Internet, it requires proper authorization and access control to be incorporated. Facilities in a hotel that are Bluetooth enabled, like access to the printers, wending machines, billiards room, spa, etc. Access to these facilities has to be controlled and different people will have different privileges so authorization has to be incorporated. Public facility like a Bluetooth enabled printer in a lab or a Bluetooth enabled fax machine in an office. They can be used by many users having their mobile devices, at different times, so user level security has to be incorporated. Streamlined meetings. There can be business meeting scenarios where a group of users having their Bluetooth enabled mobile devices come into vicinity and have data which has to be shared and also data which does not have to be shared. Some files should be accessible to a member’s own team and not to the other partners. Some files might be inaccessible to everyone. So these kinds of scenarios require appropriate authorization and access control to be incorporated. A person like a system administrator might want to control his network remotely by using his Bluetooth enabled mobile device by using a LAN access point in the vicinity. This requires proper authentication procedure to be existent. These are some scenarios that require proper security to be implemented for them to be realized. Hence it can be seen that if Bluetooth has to make way into our lives and become a wireless technology standard and be a key element in the era of pervasive computing, it has to be secure enough, otherwise it will just be confined to its initial

PAGE 53

42 vision of a “get rid of cables” technology. Now we discuss some weaknesses in the Bluetooth security and also how an intruder can breach it. PIN code attack. Bluetooth security relies heavily on a shared PIN code that is used to generate initialization key and subsequent link keys. This PIN code is usually a 4-digit number and most of the times it is ”. Breaking a 4-digit PIN is not very difficult and since it is the only secret piece of information shared by the two devices, a third party knowing the PIN can break into all the subsequent communication without much difficulty. Man-in-the-middle attack. This attack also known as impersonation can by done by spoofing in the following ways: Spoofing due to non-secret link key. Here is a typical scenario – device A communicates with device B using B’s unit key as the link key. Then device A communicates with device C and gives B’s unit key to C. After this the device C can communicate with B using this key by pretending to be any device that has previously communicated with B using this link key. Spoofing the BD_ADDR. Since the Bluetooth address of a device is easily obtainable by a general inquiry access routine; a device can perform an inquiry scan on another device and spoof its BD_ADDR to establish subsequent communications with other devices. Authentication misrepresented. The Bluetooth security procedure misrepresents authentication as the process of verification that the two parties share the same link key. It does not actually verify the identity of the other device.

PAGE 54

43 No user level security defined. While Bluetooth claims to provide authentication, its authentication does not determine the identity of a subject (person), but only verifies that the nodes on a connection have the same link key that was exchanged in a pairing process. So, only device level authentication is performed, not user level. Shared secret concept. Bluetooth security is based on a shared secret that is distributed to the communicating parties offline. In ad hoc networking scenarios where two devices communicate with into each other for the first time ever, this security mechanism cannot be used. The devices do not have any shared secret. Also, the shared secret solution needs to store a unique secret for each pair of communicating devices. No access control. Access control is largely missing. There is only the crudest access control, dividing the world into trusted and non-trusted devices, and services that do and do not require security This means that virtually any device may communicate with any other device, and send any information it likes. Exhausting the battery. This attack (basically a form of denial of service attack) is possible if a device is overwhelmed with connection requests and is not able to respond to legitimate requests. These are the major weaknesses in the Bluetooth security mechanisms. Now we will propose a solution to address some of the weakness. Scope of Thesis This thesis is an effort to address some of the issues involved in the inherent weakness of Bluetooth security. It aims at extending the Bluetooth stack for facilitating secure Bluetooth communications using mode 2 (service level enforced security) defined by the Generic Access Profile (GAP). The weaknesses tried to overcome are the lack of access control, lack of authorization mechanisms and lack of service level security. The

PAGE 55

44 BlueSec module is developed which is an extension to the Bluetooth stack for facilitating secure service access. The OpenBT Bluetooth stack is used for development and the module is provided as a part of the kernel mode Bluetooth driver. The module has to be flexible so that a vendor can ship his product according to his own requirements regarding security implementation. Also, it should provide a well-defined interface to the application developer so that he can perform security related tasks without having to make modifications to the Bluetooth stack. The detailed architecture of BlueSec and the implementation details will be discussed in the next chapter. The goal is to provide an infrastructure upon which bigger applications can be built and the security aspect taken care of.

PAGE 56

CHAPTER 5 BLUESEC IMPLEMENTATION In the previous chapters we have delved into the Bluetooth technology overview and the review and analysis of Bluetooth security. We also proposed a solution to address some of the weaknesses of security mechanisms in Bluetooth. This chapter discusses the proposed BlueSec module in detail. Architecture Communication between Bluetooth devices involves performing device discovery, service discovery and then using the discovered service(s). Bluetooth currently provides link-level security i.e. at the baseband level before forming an L2CAP connection. We aim to provide service-level security. The assumption is therefore that the device is authenticated before any other operations start. The baseband connection has been formed. Now the device tries to access the services. For this, it has to form a separate L2CAP connection and start an SDP session. There is no need for incorporating security procedures in the Service Discovery Protocol. It is just like switching TV channels to see what channel is screening what programs. Now when we try to access those services (for e.g. we try to view a pay per view channel), then the security procedures like authorization, access control etc. come into play. The Generic Access Profile defines this mode as the security mode 3 or the service-level security. Requirements First of all it is required to have a broker for all access requests to services. Each access request has to pass through the broker and granted access only if it is authorized to 45

PAGE 57

46 do so. The broker has to come into play when an application or higher-level protocol tries to form an L2CAP connection to use a particular service. L2CAP is the layer that provides protocol multiplexing to the higher layers. Applications and profiles such as PPP, OBEX, etc. form an L2CAP connection to transfer data over Bluetooth radio. For performing access control and making decisions regarding access control, we need to store security related information and attributes for both the services and devices. We should also be able to retrieve those attributes when necessary. Different services will have different security requirements since some may be very critical and some less critical. Hence, it is necessary to assign levels to services to distinguish the services requiring secure access from the services that may be meant to be available to everyone trying to get access. An example can be a service in a mall that displays discounts on various items. This may not be security critical. On the other hand, in the same mall, there might be a service that can display the total sales in each section during the day that should only be available to the owners and managers. In the same way, different devices may have different levels of trust. For e.g., a person could trust his friend’s laptop to a higher degree but may not want to trust a new colleague’s recently bought palmtop. Hence, it is necessary to assign trust levels to devices too. Once a device has been authenticated and authorized to use a particular service, a user may want to establish a bond with that device so that it does not have to undergo security procedures every time is wants to connect. For this, provision has to be provided whereby a bond can be created for subsequent access requests by a particular device.

PAGE 58

47 There might be specific policies that would need to be implemented for both devices as well as services. The module should be able to do policy checks before granting access. Hence, we have to provide the implementation of policies by the user. There might be some scenarios in which the user might want to control access according to his discretion. A typical scenario could be a technical visit by a group in which the visitors have their Bluetooth enabled mobile devices. The host might want to give different access privileges to different members. Hence, for accomplishing this, the module must provide functionality for enabling discretionary user control. The module must also provide enabling and disabling of encryption. Design The BlueSec acts as a broker for service access requests so it is placed above the L2CAP layer. It performs access control, authorization checks and policy checks etc. before allowing forming a connection to use the service. To form a connection to the service, we have to know the attributes to do so. For e.g., an application trying to form a PPP connection over RFCOMM has to know the channel number to use. Performing service discovery and sending an attribute search request and subsequently getting an attribute response can get this information. After the SDP session is over, it has to form a separate connection on top of L2CAP (which is after the SDP connection is shut down). If the discretionary user control is turned on then no checks are performed and the decision is left to the user. He is shown the device name and address and then he can decide whether to grant access or not. There might also be a requirement that a higher-level application performs authorization and access control. In that case the module forwards the request to that external entity and waits for the results. The figure 5-1 shows the position of the BlueSec module in the Bluetooth protocol stack.

PAGE 59

48 vCard/vCal WAE Baseband LMP Host Controller I nterface L2CAP Audio RFCOMM PPP IP UDP TCP WAP OBEX AT Commands TCS BIN BlueSec SDP Bluetooth R adio Figure 5-1. Bluetooth protocol stack with BlueSec The module interacts with the databases storing the service and the device security related information. It is also flexible because the vendor might want to have his own functionality to be implemented like the implementation of databases for services and devices. The current implementation uses link lists to store security related information but in the future the vendor may want to provide his own efficient implementation for this. Also, the decision as to how to implement bonding and what trust algorithms is left

PAGE 60

49 to the vendor. The implementation of policies is also done by storing each policy as a link list element. In the future, the vendor may want to provide his own implementation. Hence, the module has provisions for the vendor to provide his own functionality if he doesn’t want the default implementation. There is a template file for each vendor configuration supported. The vendor has to just overwrite that file to plug in his functionality that can work in tandem with the module. The decisions to be made by the vendor are what method to use for implementing bonding, what procedure to follow for trust establishment, how to implement the service and the device databases and what attributes to show to the user. The module is a part of the Bluetooth driver and each of its functionality is executed by sending ioctls to the driver. The figure 5-2 shows the interaction of the module with the other entities. Commands to the Module Service Database Device Database BlueSec Manager Vendor Specific Functionality Figure 5-2. BlueSec Module interaction

PAGE 61

50 So far, the design of BlueSec has been explained. In the next section we will show how it is fit into the Axis OpenBT Bluetooth stack. Software Implementation in OpenBT BlueSec is implemented in the OpenBT stack to work as part of the kernel mode Bluetooth driver. The functionality is incorporated into the SecurityManager.c source file. This functionality can be invoked by issuing ioctls to the stack. The module also interacts with the vendor templates and the service and device databases as shown in the previous figure. The following table shows the list of ioctls provided for performing security operations. Table 5-1. Ioctls provided by BlueSec BTREGISTERSERVICE BTCANCELSERVICE BTADDDEVICE BTREMOVEDEVICE BTGETATTRIBUTES BTCREATEBOND BTCREATETRUST BTIMPLEMENTPOLICY BTTURNONSECURITY BTTURNOFFSECURITY BTTURNONUSERCTRL BTTURNOFFUSERCTRL BTTURNONENCRYPTION BTTURNOFFENCRYPTION The functionality of these ioctls is as follows. BTREGISTERSERVICE. This performs service registration. It takes a service database entry and puts it in the database. It can only be done by the device owner.

PAGE 62

51 BTCANCELSERVICE. This removes the entry from the service database. This can also be done only by the device owner. BTADDDEVICE. This performs device registration. It takes a device database entry and puts it in the database. This can also be done only by the device owner. BTREMOVEDEVICE. This removes the entry from the device database. This can also be done only by the device owner. BTGETATTRIBUTES. This displays the attributes of the service to the user. It depends on the vendor what security critical information has to be shown and to whom. BTIMPLEMENTPOLICY. This implements service policies as well as device polices. Following are the service policies that have been defined: 1) This service can only be used by a particular BD_ADDR. 2) This service cannot be used by a particular BD_ADDR. 3) Devices below a certain trust level cannot use this service. 4) Only devices having trust level above a certain value can use this service. 5) Non-registered devices cannot use this service. 6) Devices authorized to use a particular service are automatically authorized to use this service. 7) This service can only be used between specific times. Following are the device policies that have been defined: 1) This device cannot access a particular service. 2) This device has privileged access for a particular service. 3) This device has guest privileges only. 4) This device has special privileges for a particular time only. BTCREATEBOND. This is basically to create a bond with a device to grant future access without undergoing security procedures every time. The bond can be either for a

PAGE 63

52 particular service or for all services offered by a particular device. We can have different algorithms to implement bonding. This depends on the vendor what scheme he wants to use. BTCREATETRUST. This is used to create a trust relationship with a device. It assigns a trust level to a device, which is later used while making decisions about granting access, authorization etc. It takes into account the class of device, security level of service, authentication/authorization requirements, access privileges etc. It again depends on the vendor what procedure he wants to follow to create trust with a device. BTTURNONSECURITY. This turns on the service level security. If this is turned on, only then will the security related operations would be performed. The device owner can only do it. BTTURNOFFSECURITY. This turns off the security. Once the security is turned off, no access control or authorization checks would be performed. This also has to be done by the device owner. BTTURNONUSERCTRL. This turns on the user control option. Once this is turned on, the security checks are bypassed by the stack and the decision is left to the user whether to grant access or not. BTTURNOFFUSERCTRL. This is used to turn off the user control. If this is turned off, only then would the stack perform the checks. BTTURNONENCRYPTION. This ioctl is used to turn on the encryption feature, so in the future the data will have to be encrypted before transfer. BTTURNOFFENCRYPTION. This is used to turn off the encryption feature. If this is turned off, we need not encrypt the application data before transfer.

PAGE 64

53 Implementation of vendor templates. A template source file is designed for use by the vendor before shipping the product. It requires vendor to give his implementation of service and device databases (though he could use the default one also), decide what attributes to show to the user, what scheme to use for implementing bonding and what procedure to use for assigning trust levels. Implementation of Databases Device database. The following figure shows how a typical entry for a device would be. The database is basically a linked list with the fields of a node shown in the figure. Device name BD_ADDR Trust level Policies Nbonds Next Prev Figure 5-3. Device Database entry Service database. The following figure shows how a typical entry for a service would be. This is also implemented as a linked list with the fields of a node as shown in the figure.

PAGE 65

54 Service name Service ID Security level Policies Next Prev Figure 5-4. Service Database entry The operations provided on the list are Initialize the list. Free the list. Create a node from the parameters. Initialize a node. Get first node. Get next node. Get a node with a particular device/service name. Insert a node. Delete a node. Display the list. Implementation of the interface to the application developer – The working of the Bluetooth stack is transparent to the applications developer. We provide the developer with a set of ioctls as described above. There is an application (handlerapp.c), which has functionality to execute all the ioctls after initializing the Bluetooth stack. The developer just needs to map his commands to these functions and the stack will do the rest. An example GUI is created which is a menu based system to demonstrate how a future application would use the security features provided by the stack. The following figure shows a screen capture of the sample user application.

PAGE 66

55 Figure 5-5. Screen Capture of sample user application

PAGE 67

CHAPTER 6 CONCLUSION AND FUTURE WORK This thesis aims to be a starting step towards Bluetooth security. An effort is made to make the Bluetooth communications more secure so that this technology can find its way into becoming a wireless industry standard. Security has been a major concern in Bluetooth lately since it has found its application in more critical real-life scenarios rather than just being a cable replacement technology. Linux, being open source and also rapidly finding its way into mobile devices was the obvious choice as a development platform. This thesis addresses the security procedures involved in Bluetooth communications after the baseband link is established and provides an infrastructure for implementing user-level security functionality. Since this thesis is just a starting step towards Bluetooth security, it provides a lot scope for further development. Some of the issues that can be considered and enhanced are: The BlueSec module can be plugged in as a part of a big Bluetooth Software Suite for Linux. The windows counterpart already exists and the development of a robust software for Linux using one of the popular Linux-based Bluetooth stacks can be pursued. The data storage can be handled more effectively. Currently, BlueSec uses link-list storage for databases but a more efficient implementation can be done. 56

PAGE 68

57 The ESDP (Extended Service Discovery Profile) can be implemented for the Bluetooth stack, which would enable more attributes for services to be displayed and hence the access requests can provide more specific information and the decision whether to grant access or not can be more robust and effective. This module assumes device authentication and addresses issues like authorization, access control etc. on top of that. An efficient protocol can be designed to have strong device authentication at the baseband level which is currently a security weakness in Bluetooth.

PAGE 69

LIST OF REFERENCES 1. Axis Communications, Axis OpenBT Project, Accessed: October 2001; http://sourceforge.net/projects/openbt . 2. SSi Service Strategies Inc., Glossary of Messaging and Security Terms, Accessed: April 2002, http://www.ssimail.com/Glossary.htm . 3. Palowireless Pty Ltd, Palowireless Bluetooth Resource Center, Bluetooth Tutorial, Accessed: June 2002, http://www.palowireless.com/bluetooth/tutorial . 4. J. Bray and C. Sturman,”Bluetooth: Connect Without Cables,” Prentice Hall Professional Technical Reference, December 2000. 5. R. Bannon, A. Chin, F. Kassam and A. Roszko, “Extraction of Axis OpenBT Bluetooth Software Stack,” Dept. of Electrical and Computer Engineering, Software Engineering Group, University of Waterloo, December 2001. 6. J. Bray, G. McNutt, B. Munday and D. Kammer, “Bluetooth Application Developer’s Guide,” Syngress Publishing Inc, Massachusetts, Accessed: January 2002; http://www.syngress.com/catalog/sg_main.cfm?pid=1600 . 7. G. Lamm, G. Falauto, J. Estrada and J. Gadiyaram, “Bluetooth Wireless Network Security Features,” Proceedings of the 2001 IEEE, New York, June 2001. 8. Bluetooth SIG, Bluetooth v1.1 Core Specification, Accessed: August 2001; http://www.bluetooth.org/docs/Bluetooth_V11_core_22Feb01.pdf . 9. Bluetooth SIG, Bluetooth v1.1 Profiles, Accessed: August 2001; http://www.bluetooth.org/docs/Bluetooth_V11_Profiles_22Feb01.pdf . 10. N. Muller, Bluetooth Demystified, McGraw-Hill, New York, 2000. 11. M. Krasnyansky, Bluez Linux Bluetooth Protocol Stack, Accessed: May 2001; http://bluez.sourceforge.net . 58

PAGE 70

BIOGRAPHICAL SKETCH Sapanpreet Anand received his Bachelor of Engineering degree in electronics and communication engineering from the University of Delhi in the year 2000 and his master’s in computer science from the University of Florida, Gainesville, in 2002. His research interests include mobile and wireless networks and computer and network security. 59