Dominic Spill University College London d.spill@cs.ucl.ac.uk Andrea Bittau University College London a.bittau@cs.ucl.ac.uk BlueSniff: Eve meets Alice and Bluetooth
To provide privacy, Bluetooth supports optional encryption at the link layer. This scheme has been shown to be vulnerable if the attacker is able to eavesdrop the paring procedure, which is necessary before two devices can setup an encrypted link [14]. Thus both encrypted and unencrypted links would be threatened by attackers with eavesdropping capabilities. The attack on Bluetooth's encryption was not implemented in practice due to the lack of mechanism for eavesdropping the protocol. Monitoring a Bluetooth connection is not a trivial task and various aspects of the protocol implicitly add to its security and difficulty of eavesdropping.
There are two main hurdles to overcome when attempting to eavesdrop Bluetooth: frequency hopping and data whitening. Bluetooth sends each packet on a different frequency and hops 1,600 times a second. The hopping sequence is unknown to an attacker therefore making it impossible for him to follow an entire conversation, unless the whole spectrum of 79 channels is being monitored concurrently, which is impractical. The second hurdle is that data is whitened (scrambled) making it impossible for the attacker to inspect the payload, or indeed the Bluetooth headers. We show that it is possible to determine the parameters necessary for calculating the hopping sequence and unwhitening data, thus providing a practical mechanism for eavesdropping Bluetooth. We have not yet implemented channel hopping due to hardware restrictions although we are able to successfully eavesdrop on a single channel. By bridging the gap between the previously theoretical attack on Bluetooth's encryption, the protocol's data should no longer be regarded as having any practical confidentiality properties.
Recently, ``undiscoverable mode'' is being widely used as a form of protection in Bluetooth devices. This mode acts in a similar way to a firewall, causing a device to become stealth without ever making it reveal its MAC address. Hence only trusted devices which have prior knowledge of the MAC address would be able to connect to an undiscoverable device. This form of protection is often used in devices with hardcoded PINs (usually 0000) in order to provide access control. A common example of such devices are headsets which can be turned on in a special manner in order to make them discoverable for the initial paring, and then switched on in their normal state of undiscoverable. This protection often is the only option when the alternative would instead be to integrate a display with a keypad for configuring customizable PIN numbers--which can be larger than the device itself.
We provide a mechanism for determining the MAC address of undiscoverable ``master'' devices, that is, those that initiate the connection. It is no longer the case that undiscoverable mode can be relied upon as a mechanism for access control and secrecy--the MAC address can be obtained. This is a real threat to users which enable undiscoverable mode in order to ``patch'' vulnerabilities in their devices. For example, many mobile phones have vulnerabilities ranging from allowing attackers to download arbitrary files to arbitrarily controlling the device [9,12]. All of these attacks require knowledge of the MAC address so one way to mitigate the problem is to make the device undiscoverable. Unfortunately this is commonly used and encouraged as a technique to avoid unwanted connections [5], but it has been shown that it is still possible to connect to devices in this mode [6] if the MAC address is known.
Our work brings forward two main contributions. First, we show that the Bluetooth packets have no confidentiality properties. Specifically we demonstrate how data can be unwhitened and the hopping sequence calculated. Prior work has shown how the data can be decrypted if necessary [14]. Second, we show that the undiscoverable mode does not provide access control to master devices, nor protects the secrecy of their MAC address. We are able to determine the complete MAC address of these devices. Finally, all our work was done using GNU Radio and we therefore provide the first open-source Bluetooth sniffer, free from any licensing restrictions.
Bluetooth uses frequency hopping over 79 channels in order to minimize
interference and (usually) hops once every 625
s, sending one packet per
channel. The hopping sequence is determined by the MAC address of the master
device and its clock. The master device is the one that initiates the
connection, and the slave being the one connected to.
Data transfer often takes place on alternate hops, leaving the intervening hops
for acknowledgments, as shown in Figure 1. The difficulties in
eavesdropping in the presence of channel hopping are therefore determining the
sequence, and hopping quickly enough.
|
The second hurdle to eavesdropping on data carried in Bluetooth connections is that packets are whitened (scrambled) in order to improve error resilience and security. The whitening is determined by six bits of the master device's clock. Thus, in order to eavesdrop on a Bluetooth connection two pieces of information are needed: the MAC address and clock of the master device. With this information, one can calculate the hopping sequence and tune to the correct radio channel, and then unwhiten the received packets.
Most Bluetooth devices offer a mode called ``undiscoverable'' which prevents a device from advertising its MAC and clock upon receiving an inquiry. This is often used by people for access control as suggested by Bluetooth security advisories [5], so inquiry cannot be relied upon for determining the MAC and clock. The MAC address cannot be easily discovered since Bluetooth packets do not contain the complete address but only the lower three bytes, known as the Lower Address Part (LAP). The clock is not present in standard packets. There is one packet (FHS), used during the connection handshake, that contains all the necessary information (MAC and clock) for listening on a connection. Unfortunately obtaining this packet requires eavesdropping the start of a connection and being tuned on the (unknown) correct frequency, which most likely is not possible in practice. To obtain the clock one can establish a connection to a device, but in order to do that, the MAC address is needed. Thus, much of the difficulty of eavesdropping Bluetooth comes from the secrecy of the MAC address.
There are three problems to eavesdropping Bluetooth in practice. First, standard Bluetooth dongles do not have a concept of ``promiscuous'' mode so we need to make use of special hardware such as software defined radio. Second, we need to unwhiten the data since all Bluetooth data is scrambled (whitened) by default. Third, we need to determine the master's MAC address since this allows us to calculate the hopping pattern.
In order to capture packets, we made use of GNU Radio. We then developed a technique for unwhitening data which does not require knowledge of the clock. The use of this technique will leak some bits of the clock as a side-effect, and these are enough for an attacker to whiten future data in case that an active attack needs to be performed. Finally we developed a mechanism for determining the full MAC address of a device after eavesdropping one packet and transmitting less than 256 packets. Having obtained the MAC address we can connect to the device in order to determine its full clock, giving us all of the information needed to follow its hopping pattern. All of these attacks work on undiscoverable devices. We will now describe them in detail in the sections that follow.
There are two problems to be solved when eavesdropping with the USRP. First, the demodulator parameters need to be set up properly so that Bluetooth data can be recovered on the channel that is being listened on. Second, because a Bluetooth connection frequency hops, the radio must be able to monitor other channels too in order to eavesdrop the entire conversation and not only packets that happen to pass by the single channel on which the USRP happened to be tuned on. There are two approaches to the latter problem. One solution is to eavesdrop all Bluetooth channels in parallel. The other approach is to make the USRP retune in order to follow the hopping sequence. In the following sections we describe how we demodulated Bluetooth using the USRP, how we can monitor multiple channels, and how we plan to implement channel hopping in the future.
Finding a Bluetooth packet for the first time was not a trivial task. The obvious approach would have been to transfer a large file containing a known pattern and then search for the pattern in the output from the demodulator. This basic approach was not possible since the Bluetooth data is whitened by the device and the whitened version is unknown, so we would not know what we were looking for. Thus we were seeking through a sequence of bits, not knowing which bits to look for, and not even knowing if our demodulator setup was correct. When researching the correct demodulator parameters, looking for packet headers turned out to be unreliable since they are very short and incorrect demodulator settings yielded many bits that seemed like a real packet headers but in reality were just noise.
Fortunately we came across a debug mode of Cambridge Silicon Radio (CSR) based Bluetooth dongles that causes packets to be sent repeatedly on a single channel [8]. This allowed us to eliminate variables such as channel hopping, and since the test packets were not whitened, we knew the exact bit sequence we were looking for. After several attempts we were able to demodulate the packet.
Bluetooth data is modulated using a Gaussian Frequency Shift Keying (GFSK) method, which is not strictly supported by the GNU Radio demodulation tools. There is a Gaussian Minimum Shift Keying (GMSK) demodulator, and this was tuned to allow for the demodulation of Bluetooth packets. GMSK is a variant of GFSK in which the frequency shift used to represent data is kept to a minimum. The Bluetooth modulation scheme is within this limit, so GMSK demodulation is a drop in replacement for GFSK in this scenario.
The main parameters for the demodulator are the modulation index and the symbol
rate given in the form of number of samples per symbol. These were found with
the help of the CSR debug packets and our modified version of the GNU Radio
software oscilloscope which allowed the samples per symbol parameters to be
calculated from a received packet. Our modified oscilloscope allowed file input
to be used, which lead to a large sample being cut in size until it left a
sample file containing a single packet. The packet was measured to be
approximately 400s in length, with a reported sampling rate of 4,000,000
samples per second. The packet was known to be 366 bits in length, which gave a
samples per symbol value of four. The modulation index , a measure of the
frequency deviation of the unmodulated signal, was derived from the Bluetooth
specification [1] which allows a range from 0.28 to 0.35, and we found
0.32 to produce good results. Thus, the necessary parameters for demodulating
Bluetooth using GNU Radio's GMSK demodulator are:
: 0.32.
It may be useful to filter the incoming signal to remove noise caused by signals transmitted in adjacent channels or other by other wireless systems operating in the same band. However this is not recommended since all of the signal processing is done in software and it can therefore have a negative impact on the performance of the packet demodulation and parsing processes. The experimentation showed that, for our setup, filters were not needed, although this may not be the case in a less controlled environment, or with a greater distance between the USRP and the transmitting device.
With these parameters, it is possible to eavesdrop Bluetooth on any given channel. We now examine the issue of channel hopping, first by showing how multiple channels can be eavesdropped in parallel, and second how the radio may be retuned in order to follow the hopping sequence.
It is possible for a connection to use a limited number of channels due to regulatory issues. In fact, the Bluetooth Adaptive Frequency Hopping (AFH) parameter can be used to select the available channels, with a minimum of twenty channels. Thus, with a man in the middle attack, it may be possible to reconfigure an existing connection to use only twenty channels and in this case only two USRPs would be necessary to eavesdrop all of the packets involved. We will investigate this further once we implement transmission and move on to active attacks.
To listen to the entire range of the 79 Bluetooth channels, eight USRP devices are needed. All 79 channels need to be filtered, monitored, and then the packets need to be ordered before the data can be read from them. This greatly increases the processing power required, although the captured data can be processed offline or by a cluster of machines. Ordering packets is necessary when using multiple USRPs because data is buffered in a variable way before being delivered and may therefore result in the packets being received out of order from the multiple devices. The processing of these packets is made easier by our technique of deriving the clock signal from each packet, since it acts as a sequence number and therefore allows for some ordering of the packets to take place. More ordering information may be available from data or headers in layers higher up in the protocol stack. It is a future goal for the GNU Radio project to get rid of delays and buffering, so ordering will no longer be a problem once this is accomplished.
s, which is not fast enough to follow a Bluetooth hopping pattern since
each time slot is 600s. Hopping with a tuning delay of 200s would
cause up to one third of each packet to be lost. There are various solutions to
this problem depending on the attacker's needs.
The attacker could choose which 200s of the time slot to miss. For
example, if the start of the packet has no sensitive data, then the attacker
would retune at the end of the time slot in order to catch the tail of the
packet. Otherwise the retune could occur before the end of the time slot in
order to catch the head of the next packet. If the attacker knew that the
eavesdropped packets were short and (say) occupied only half a time slot, the
retune could happen right after the packet ends, and not at the end of the time
slot. This leaves the attacker enough time to retune to the next frequency and
successfully catch the start of the next packet. Examples of short packets that
contain sensitive information are key presses from a Bluetooth keyboard.
It may be the case that only one direction of the connection holds sensitive data. For example, a file download will have incoming data and outgoing acknowledgments. Bluetooth uses an alternating scheme for receiving and transmitting data. Thus, if only one direction needs to be eavesdropped, the attacker has a whole time slot in order to retune and the USRP is fast enough for this. If the whole connection needs to be eavesdropped, two daughterboards are necessary, and they can be installed on a single USRP. In this case, one daughterboard would be listening to the current time slot while the other one would be retuning to the next time slot. These roles would be then switched and alternated between the two boards throughout the entire connection.
The major practical obstacle to any frequency hopping implementation, and the reason why we still have not produced a working prototype that supports hopping, is the buffering and asynchronous nature of the GNU Radio framework. This introduces a delay which is not constant, and is often large enough to allow multiple packets to be received before the buffered data receives any parsing or processing module. The delay means that the software does not have a chance to synchronize with the hopping of the device which is being attacked by adjusting the clock on packet reception in order to compensate for drift. One of the goals for GNU Radio is to allow more direct flows of data processing through the software, removing the delay in processing, meaning that frequency hopping may be possible with future revisions of GNU Radio. This refactoring is a non-trivial change to the GNU Radio software and hence we did not take the route of doing it ourselves in order to enhance our Bluetooth sniffer.
Whitening is performed on every packet regardless of higher level protocol. It involves an XOR of a pseudo-random sequence with the packet data. The sequence is produced using a six bit value derived from the clock as input to a linear feedback shift register (LFSR), shown in Figure 2. This means that there are a total of 64 possible starting values for the LFSR, which is a small enough set to bruteforce.
Our mechanism is to generate all 64 candidate unwhitened packets and then validate which packet is the correct one using other fields in the packet such as the link ID (typically 1) or the CRC calculated over the payload (which we can check). This process will also reveal six bits of the clock, which can be used to removing whitening from future packets, or to add whitening to a packet in the case that an attacker wishes to transmit data. The clock, once discovered, can be kept synchronized by using the CPU cycle counter as a fine-grained time source.
|
We now describe how we generate the 64 candidate packets. Each of the 64 possible input values are used in turn to initiate the whitening LFSR, producing 18 bits of data to be XORed with the packet header. We made the process faster by creating a look up table because the whitening LFSR, shown in Figure 2, uses a seven bit register and, as this function can be called up to 102,400 times per second in one of only 127 possible states, we wanted to make this function as efficient as possible. This algorithm is shown below.
void unwhiten(input, output, clock) {
indices[64] = array of indices
into whitening_data;
whitening[127] = array of outputs
from whitening lfsr;
index = indices[clock];
for(bits in data) {
output = input XOR whitening[index];
index++;
index = index MOD 127;
}
}
For each possible value of the clock, one packet header is produced. We now need to determine which one is the correct candidate. Each header contains connection state, such as the link ID, which is constant throughout the duration of a connection and therefore will be the same in every packet. Over a number of packets these constant values will emerge, allowing us to filter out candates until the correct one is found. Another technique is to look for correlations between packets such as the clock value itself advancing as expected given the packet reception time.
The most practical method for determining the correctly unwhitened packet is checking the payload CRC. With this method, false positive results are extremely unlikely as the CRC is initialized with a byte of zero and the UAP, as is the HEC, so a false positive match would have to match all 16 bits of the CRC initialization (1 in 65,536) and eight of those bits would have to match the HEC initialization. There is one caveat because not all Bluetooth packets carry a payload CRC. However most of the control data sent between devices uses DM1 packet types which do have a CRC, and these packets are very frequent so it is not a problem obtaining such packets in practice.
The MAC address is divided into three parts called the Lower Address Part (LAP), Upper Address Part (UAP) and Non-significant Address Part (NAP). The lengths of these parts are three, one and two bytes respectively, as shown in Figure 3. In the following sections we show how these parts can be recovered by eavesdropping on any single Bluetooth channel.
|
The HEC calculation is based on a linear feedback shift register (LFSR) which is initialized with the UAP of the master device. Each bit of the header is fed into the LFSR in the order it will be transmitted, and the final contents of the register is appended to the end of the header.
This calculation is based on XOR operations and can be run entirely in reverse, as shown below.
UAPtoHEC(header, HEC) {
for(bits in header) {
HEC = HEC_bit_0 XOR HEC_bit_1;
HEC = HEC_bit_0 XOR HEC_bit_2;
HEC = HEC_bit_0 XOR HEC_bit_5;
HEC = HEC_bit_0 XOR HEC_bit_7;
right_shift(HEC);
HEC = HEC_bit_0 XOR header_bit;
}
return HEC;
}
The LFSR is initialized with the HEC, and each bit of the header is processed in reverse. The final state of the register will be the value with which the LFSR was initialized, i.e. the UAP of the master device.
The following is an algorithm and summary for how to determine the UAP and unwhiten data from an eavesdropped packet, this is also shown in Figure 5.
It is however possible to make educated guesses regarding this byte rather than blindly bruteforcing. The top three bytes of the MAC address (NAP + UAP) correspond to the vendor of the device. MAC address ranges are assigned by the IEEE to vendors in order to divide the namespace so that address collisions are avoided. A complete list of the address ranges is available and known as the Organizationally Unique Identifier (OUI) list [10]. The UAP value may be used to filter out possible candidates from the OUI list. More candidates can be ruled out by guessing the type of device being eavesdropped. For example, when eavesdropping mobile phones, MAC addresses belonging to Nokia are more likely to be correct rather than those allocated to Sun Microsystems. Indeed there are relatively few Bluetooth vendors, and in practice a very narrow set of vendors are widespread. Using this technique usually yields less than thirty candidates, which can be bruteforced very quickly. Instead of using the OUI list, a smaller sample set can be generated by using a database of common Bluetooth device MAC address prefixes [18].
|
The following algorithm is a summary of how to determine the MAC address from an eavesdropped packet.
We chose an OBEX [3] file transfer application simply because we can control the payload of the data (file contents) making it easier to check whether we are doing things correctly. The OBEX data transfer protocol is well established and documented. It has been used for IrDA connections and was chosen as a data transfer method for Bluetooth using the built in RFCOMM transport method as described in volume 7 of the Bluetooth specification [1]. RFCOMM is encapsulated in the Logical Link Control and Adaptation Protocol (L2CAP) [1] to send its data. The L2CAP protocol handles the fragmentation of the data to be transferred, and is transmitted as the payload of Bluetooth packets. The details of these protocols are unimportant, except that they allow a file transfer to take place with the file data easily identifiable in the payload of the packet.
Our setup consisted of two Linux boxes, one acting as an OBEX ftp server and one as an OBEX ftp client. A file containing ``101010...'' was transferred from one machine to the other while a third box running our GNU Radio module was intercepting the communication. The alternating ``101010...'' file was used simply because it was easy to find in a large block of output data. We will now explain how we eavesdropped the data, how we determined the MAC address, and how we unwhitened the data and recovered the portion of the file being transmitted.
Firstly the USRP was tuned to a channel that Bluetooth was known to use, in this case 2.421GHz. The choice of frequency is unimportant as Bluetooth attempts to use all channels equally. 2.421GHz was chosen to avoid interference from neighboring 802.11g sources and the CPU clock signal. The software was then able to detect packets being received by the USRP. These were demodulated using the GMSK demodulator from the GNU Radio tools.
The payload format is fairly straight forward for an OBEX transfer, it features the L2CAP header, followed by the RFCOMM header, and finally an OBEX header. Then the data from the file is carried in plain text, the packet ends with a single byte RFCOMM CRC and a two byte packet CRC, as shown in Figure 6. Given this simple packet layout we were able to extract part of the file contents as we eavesdropped packets from the air.
We intend to investigate transmission and active attacks. With transmission we may be able to reset connections by spoofing a disconnect packet, and therefore examine how tolerable Bluetooth is to man in the middle or DoS attacks. We will also assess the security of the layers above the baseband such as L2CAP, RFCOMM and OBEX to see if they present any vulnerabilities now we have enabled the attacker to have full access to the communication medium.
It is now possible to implement some of the attacks [16,11,17,14] that were only theoretical in nature before, and attacks such as interception of calls that make use of a Bluetooth headset become a real threat. Eavesdropping is the basic weapon an attacker needs and we have provided it; at this point the fun research begins.
We also show how the full MAC address of master devices can be obtained, therefore bypassing the access control of such devices operating in undiscoverable mode. We have therefore opened the doors for practical Bluetooth security research by providing the means for eavesdropping, and by showing that the common form of security through obscurity (undiscoverable devices) used in Bluetooth is futile.
