[Dataset] toronto/bluetooth (v. 2006-08-29)

top

the initial version

@MISC{toronto-bluetooth-2006-08-29,
  author = {Jing Su and Stefan Saroiu},
  title = {{CRAWDAD} data set toronto/bluetooth (v. 2006-08-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/toronto/bluetooth},
  month = aug,  
  year = 2006
}
					

To investigate whether a large-scale Bluetooth worm outbreak is viable in practice, we conducted controlled experiments and we gathered traces of Bluetooth activity in different urban environments to determine the feasibility of a worm infection.

Even if a worm could exploit a security vulnerability in the Bluetooth
protocol to replicate itself, a large-scale Bluetooth worm outbreak
might never develop. If vulnerable Bluetooth devices are few
and far between, and most inter-device contacts are short, a worm
might never reach many victims. In this case, the threat of a largescale
Bluetooth worm infection is minimal.

To investigate these questions, we examined whether a large-scale Bluetooth 
worm outbreak is viable in practice. For this, we collected traces of Bluetooth 
activity and conducted controlled experiments in a Bluetooth environment.

We used Palm Tungsten T PDAs having 16MB of RAM with PalmOS version 5.0 
to scan for Bluetooth devices. The Bluetooth radios of our PDAs are similar 
to the ones found in most commodity cell-phones: our empirical tests found 
that our PDAs' ranges are about 10 meters in an urban environment 
corresponding to the specifications presented on Palm's website. 

Because a Bluetooth inquiry is a power-intensive procedure, we used 
a total of eight scanners. Each device sends "inquiries" over its 
Bluetooth interface. Our inquiry rate is variable: we increase it 
when no devices are discovered, and we decrease it when others answer 
our probes. We issue inquiries at least once every 10 seconds but 
never more often than once every 3 seconds. This variable rate deals 
with congestion scenarios when several devices answer simultaneously.

We collected three different traces of Bluetooth activity. Two of
our traces are gathered inside Pacific Mall and Eaton Centre, two
malls in Toronto, Canada. We gathered the third trace while riding
the Toronto subway system. These three locations provide a broad
coverage of different density and mobility characteristics one might
find in various urban destinations.

When collecting these traces, we had a behavior compatible to
the environment we were scanning. For example, we were casually
walking in the malls, we stopped briefly by their food courts, and
we stood still while riding the subway. In this way, our data illustrates
a scenario where an attacker behaves inconspicuously while launching 
a Bluetooth worm. We used two devices scanning simultaneously to 
collect the Eaton Centre and the Subway traces. We used only one device 
to collect the Pacific Mall trace.

We have anonymized the MAC addresses of the discovered devices.

[Traceset] toronto/bluetooth/encountering (v. 2006-08-29)

top

the initial version

@MISC{toronto-bluetooth-encountering-2006-08-29,
  author = {Jing Su and Stefan Saroiu},
  title = {{CRAWDAD} trace set toronto/bluetooth/encountering (v. 2006-08-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/toronto/bluetooth/encountering},
  month = aug,  
  year = 2006
}
					

Traceset of Bluetooth activity in three different locations which have 
different density and mobility characteristics one might find in various urban destinations.

We collected three different traces of Bluetooth activity. Two of
our traces are gathered inside Pacific Mall and Eaton Centre, two
malls in Toronto, Canada. We gathered the third trace while riding
the Toronto subway system. These three locations provide a broad
coverage of different density and mobility characteristics one might
find in various urban destinations.

if the same foreign device answers multiple
consecutive Bluetooth inquiries except one, we "patch" the missed Bluetooth
inquiry, pretending the device answered the inquiry. If the foreign device
misses two consecutive Bluetooth inquiries, we do not "patch" the
encounter.

We have anonymized the MAC addresses of the discovered devices. We
preserved the first three octets of the original MAC address, however we
have generated random three octets for the last three octects of the MAC
address. In short:

anonymized_MAC = first_3_octets(orig_MAC) + random_3_octets

[Traceset] toronto/bluetooth/controlled (v. 2006-08-29)

top

the initial version

@MISC{toronto-bluetooth-controlled-2006-08-29,
  author = {Jing Su and Stefan Saroiu},
  title = {{CRAWDAD} trace set toronto/bluetooth/controlled (v. 2006-08-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/toronto/bluetooth/controlled},
  month = aug,  
  year = 2006
}
					

Traceset of controlled experiments for Bluetooth activity

We conducted two controlled experiments as follows:

1. toronto/bluetooth/controlled/xfers

We measured the throughput and the failure rate of transmissions between 
two devices we controlled. We transfered a 256KB file between two devices 
placed apart at different the throughput and the failure rate
of transmissions between two devices we controlled. We transfered
a 256KB file between two devices placed apart at different

2. toronto/bluetooth/controlled/moving

We also conducted the controlled experiments of communicating
over Bluetooth between two devices when only one is moving.

[Trace] toronto/bluetooth/encountering/pacificMall (v. 2006-08-29)

top

the initial version

@MISC{toronto-bluetooth-encountering-pacificMall-2006-08-29,
  author = {Jing Su and Stefan Saroiu},
  title = {{CRAWDAD} trace toronto/bluetooth/encountering/pacificMall (v. 2006-08-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/toronto/bluetooth/encountering/pacificMall},
  month = aug,  
  year = 2006
}
					

Trace of Bluetooth activity in Pacific Mall, a mall in Toronto, Canada

Each line in the file corresponds to one "encountering", where one of 
our scanners encountered a foreign Bluetooth device. One encounter is 
a sequence of several (one or more) consecutive successful Bluetooth 
inquiries. Each encounter has a start time (the time of the first 
Bluetooth inquiry answered by the encountered device) and an end time 
(the time of the last Bluetooth inquiry answered by the encountered device.)

Here's a breakdown of the format, column by column:

1. 32-bit timestamp: the encounter start time.
2. same timestamp as per #1, but in a human readable format
3. 32-bit timestamp: the encounter end time
4. same timestamp as per #3, but in a human readable format
5. location (one of EATON_CENTER, PACIFIC_MALL, or SUBWAY).
6. scanner ID
7. anonymized MAC address of foreign Bluetooth device encountered.
8. type of Bluetooth device
9. manufacturer of Bluetooth device

[Trace] toronto/bluetooth/encountering/eatonCenter (v. 2006-08-29)

top

the initial version

@MISC{toronto-bluetooth-encountering-eatonCenter-2006-08-29,
  author = {Jing Su and Stefan Saroiu},
  title = {{CRAWDAD} trace toronto/bluetooth/encountering/eatonCenter (v. 2006-08-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/toronto/bluetooth/encountering/eatonCenter},
  month = aug,  
  year = 2006
}
					

Trace of Bluetooth activity in Eaton Centre, a mall in Toronto, Canada

Each line in the file corresponds to one "encountering", where one of 
our scanners encountered a foreign Bluetooth device. One encounter is 
a sequence of several (one or more) consecutive successful Bluetooth 
inquiries. Each encounter has a start time (the time of the first 
Bluetooth inquiry answered by the encountered device) and an end time 
(the time of the last Bluetooth inquiry answered by the encountered device.)

Here's a breakdown of the format, column by column:

1. 32-bit timestamp: the encounter start time.
2. same timestamp as per #1, but in a human readable format
3. 32-bit timestamp: the encounter end time
4. same timestamp as per #3, but in a human readable format
5. location (one of EATON_CENTER, PACIFIC_MALL, or SUBWAY).
6. scanner ID
7. anonymized MAC address of foreign Bluetooth device encountered.
8. type of Bluetooth device
9. manufacturer of Bluetooth device

[Trace] toronto/bluetooth/encountering/subway (v. 2006-08-29)

top

the initial version

@MISC{toronto-bluetooth-encountering-subway-2006-08-29,
  author = {Jing Su and Stefan Saroiu},
  title = {{CRAWDAD} trace toronto/bluetooth/encountering/subway (v. 2006-08-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/toronto/bluetooth/encountering/subway},
  month = aug,  
  year = 2006
}
					

Trace of Bluetooth activity gathered while riding the Toronto subway system

Each line in the file corresponds to one "encountering", where one of 
our scanners encountered a foreign Bluetooth device. One encounter is 
a sequence of several (one or more) consecutive successful Bluetooth 
inquiries. Each encounter has a start time (the time of the first 
Bluetooth inquiry answered by the encountered device) and an end time 
(the time of the last Bluetooth inquiry answered by the encountered device.)

Here's a breakdown of the format, column by column:

1. 32-bit timestamp: the encounter start time.
2. same timestamp as per #1, but in a human readable format
3. 32-bit timestamp: the encounter end time
4. same timestamp as per #3, but in a human readable format
5. location (one of EATON_CENTER, PACIFIC_MALL, or SUBWAY).
6. scanner ID
7. anonymized MAC address of foreign Bluetooth device encountered.
8. type of Bluetooth device
9. manufacturer of Bluetooth device

[Trace] toronto/bluetooth/controlled/xfers (v. 2006-08-29)

top

the initial version

@MISC{toronto-bluetooth-controlled-xfers-2006-08-29,
  author = {Jing Su and Stefan Saroiu},
  title = {{CRAWDAD} trace toronto/bluetooth/controlled/xfers (v. 2006-08-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/toronto/bluetooth/controlled/xfers},
  month = aug,  
  year = 2006
}
					

Trace of measurements of Bluetooth transfers performed in different environments

This trace contains the measurements of Bluetooth transfers performed
in different environments. We measured how long it took to transfer 256KB
between two stationary Bluetooth devices while they are K feet apart 
(for K between 0 and 25).

This is a breakdown of the file's format, column by column:

1. inter-device distance in feet
2. data successfully transfered (out of 256032 bytes)
3. duration of transfer (in seconds)

[Trace] toronto/bluetooth/controlled/moving (v. 2006-08-29)

top

the initial version

@MISC{toronto-bluetooth-controlled-moving-2006-08-29,
  author = {Jing Su and Stefan Saroiu},
  title = {{CRAWDAD} trace toronto/bluetooth/controlled/moving (v. 2006-08-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/toronto/bluetooth/controlled/moving},
  month = aug,  
  year = 2006
}
					

Trace of measurements of Bluetooth transfer performed in a controlled environment (our lab)

We conducted controlled experiments to determine whether walking can 
prevent a person's device from becoming infected.  We placed one device 
on a wall at a T-junction hallway, while a person carried another device 
pacing themselves at a constant speed.

The mobile device first issued inquiry requests. Once the stationary
device is discovered, the mobile device transmitted a file. We
performed several experiments. We set the size of the file at 500
bytes and at 25KB. We moved the mobile device at a speed of 1
m/s, corresponding to a typical walking speed, and 2 m/s, to approximate
the relative speed of two people walking in opposite directions. 
Each experiment is repeated five times. 
We chose the T-junction hallway because it combines both line-of-sight 
and obstructed inter-device transmissions.

There are five trials for each setting of moving device's speed and transfer data 
(except when we are transffering 25KB and the device is moving at 2m/s; 
in this case, we only have four successful trials.)

1. moving device's speed (in meters per second)
2. transfer size in KB
3. time elapsed until target is discovered (in seconds)
4. time elapsed until an ACL connection is established
5. time elapsed until an L2CAP socket is setup
6. time elapsed to complete (and ACK) data transmission

[Author] Jing Su

top

[Author] Stefan Saroiu

top

[Paper] su-bluetooth

top

Over the past year, there have been several reports of malicious code 
exploiting vulnerabilities in the Bluetooth protocol. While the research 
community has started to investigate a diverse set of Bluetooth security 
issues, little is known about the feasibility and the propagation dynamics of a 
worm in a Bluetooth environment. This paper is an initial attempt to remedy 
this situation. We start by showing that the Bluetooth protocol design and 
implementation is large and complex. We gather traces and we use controlled 
experiments to investigate whether a large-scale Bluetooth worm outbreak is 
viable today. Our data shows that starting a Bluetooth worm infection is easy, 
once a vulnerability is discovered. Finally, we use trace-drive simulations to 
examine the propagation dynamics of Bluetooth worms. We find that Bluetooth 
worms can infect a large population of vulnerable devices relatively quickly, 
in just a few days.