17-11-2012, 06:02 PM
Bluetooth Security & Hacks
Bluetooth Security.pdf (Size: 566.18 KB / Downloads: 39)
Introduction
Historical Overview
Bluetooth is a technology for wireless connections of short range devices.
Originally invented by Ericsson, it has been called after Harald Blatand, a Danish
Viking who lived during the 10th Century and unified Skandinavia.
Bluetooth itself was intented to unify a users devices to her wireless personal
area network (WPAN). A Bluetooth WPAN is called piconet and may consist of
mobile phones, PDAs, printers or personal computers.
In September 1998, the Bluetooth Special Interest Group (SIG) was founded with
the objective of developing the Bluetooth wireless technology, as well as propagating
the Bluetooth brand worldwide. Today, the Bluetooth SIG consists of
more than 8000 members, which vary from music industry to telecommunication
companies.
Bluetooth Basics
Bluetooth operates in the license-free ISM band (Industrial, Scientific and Medical
Band) between 2.4 and 2.48 GHz.
For prevention of interferences with other devices working within ISM, such as
baby phones or microwave ovens, Bluetooth makes use of a technique called frequency
hopping. Therefore, the base band frequency is switched 1600 times per
second to one of 79 frequency steps of 1 MHz band width within the ISM band.
Bluetooth Services
Bluetooth makes use of a protocol stack, which makes it simple to seperate application
logic from physical data connections. In comparison to the ISO/OSI
reference model, the protocol architecture of Bluetooth allows for straightforward
implementation of existing network protocols like HTTP, FTP, etc.
SDP - Service Discovery Protocol
Bluetooth is a technology, which is deployed in a dynamical environment. Devices
may get out of range or even switched off, while new devices might become
activated.
In order to detect services, provided by other devices, a protocol, which detects
services makes sense. In Bluetooth, the Service Discovery Protocol is responsible
for keeping track of services, provided within a device’s operating range.
LMP - Link Managing Protocol
Especially interesting for further consideration is the Link Managing Protocol
(LMP), as one of three possible security modes in Bluetooth is implemented in
this layer.
Every Bluetooth device contains a Link Manager Unit, which keeps track of
connected devices. Those Link Managers communicate via protocol data units
(PDU), defined in LMP. New connections are established, using an inquiry routine
(detecting device address), followed by a page command (call for a device with
known device address), which have to be responded correctly by the opposite
device.
Bluetooth Profiles
In Bluetooth, provided services are composed to a Bluetooth Profile. Bluetooth
devices communicate via the profiles, that act as ”interfaces”.
For example, a Bluetooth-enabled mobile phone might make use of a Bluetooth
headset, which implements the Headset Profile (HSP), which means that SCO
(synchronous connection-oriented)-based audio connections and a subset of AT
commands for accepting an incoming phone call, etc. are supported.
For further consideration, two Bluetooth profiles are especially interesting, concerning
BlueSnarfing and BlueBugging attacks:
OBEX Object Push Profile (OPP)
The Object Push Profile (OPP) provides basic functions for exchange of binary
objects, mainly used for vCards in Bluetooth.
vCard is a file format standard for electronic business cards. Since vCards are not
worth being especially protected, no authorisation procedure is performed before
OPP transactions. Supported OBEX commands are connect, disconnect, put,
get and abort.
Synchronisation Profile (SYNCH)
The Synchronisation Profile (SYNCH) provides functions for exchange of Personal
Information Manager (PIM) data and was adopted from the IrDA infrared
specification.
In Bluetooth, especially private data, like the address book, calendar, etc. is
sent using the SYNCH profile, thus certain security measures have to be setup in
order to make use of SYNCH transactions, namely performing a pairing process
to authenticate the opposite device, based on a link key.
Trusted Devices
The Bluetooth specification defines several possible relations between Bluetooth
devices, mainly based on whether a link key has been established previously (cf.
section 2.9).
A paired device may get explicitely marked as a trusted device, which means that
e.g. no authentication based on the link key is required for that device, in order
to access certain services.
A weak implementation of the trusted devices feature leads to the HeloMoto
vulnerability, which ocurred on some Motorola mobile phones and is described in
section 2.7.