Bluetooth ushered in the wireless generation.
Don’t expect to get rid of it anytime soon.
Bluetooth devices have become ubiquitous in the last 20 years. They’re in our offices, our homes, our cars, and even on our persons. It’s a little overwhelming, frankly, but there must be a reason for “Bluetooth fever.” As a technology protocol, Bluetooth is revolutionary, and it will continue to shape our lives for the foreseeable future.
Of Piconets and Scatternets
Bluetooth, above all else, is a protocol specifying how two or more devices can connect to each other.[1] In particular, Bluetooth specifies how devices can communicate within short ranges (up to 100 meters) across the 2.4 GHz radio spectrum,[2] the same one commonly used with Wi-Fi.
The great thing about Bluetooth is that it’s low-cost and low-power. This means that devices like we would expect to see in the Internet of Things—smartphones, wireless headphones, smart refrigerators, and so on—can connect and communicate with each other without expending a lot of time or energy in the process.[3] And, because Bluetooth operates over radio waves, connected devices don’t have to be within direct sight of each other. So, I can use my wireless headphones without constantly pointing my smartphone at them to maintain the connection. That’s a huge boon to user convenience. But what does a network of Bluetooth devices even look like?
Bluetooth networks form wireless personal area networks (WPANs) otherwise known as piconets. These are basically centralized networks consisting of one “master” device and up to seven “slave” devices.[4] In this master-slave relationship, the master device controls and coordinates communication between the slave devices. The slave devices can’t talk to each other directly; they must communicate through the master device. Logically, the master is talking to all the slave devices within the network simultaneously. Technically, the master can only communicate with one slave at a time, but it switches between slaves so quickly that the communication appears simultaneous.
What’s really cool is that we can have a piconet of piconets. We can turn the master of one piconet into the slave of another piconet. In this way, we’re daisy-chaining piconets together to create what’s known as a scatternet. While it’s rare that an actual scatternet would be created, it’s still a neat possibility.
Okay, so we accept that Bluetooth devices can be combined to create piconets and scatternets. But how do these devices communicate to begin with? What’s the process by which the master-slave relationship develops?
When Pairing Leads to Bonding
When I want to connect my wireless headphones to my smartphone, they follow a multistep process:
- Inquiry. Suppose this is the first time I’m using my headphones with my smartphone. The devices know nothing about each other, so they must discover each other. Thus, one device sends an inquiry to the other. The listening device will then respond with its unique network address and perhaps other information like its name.
- Paging. Alright, so my headphones and my smartphone have successfully exchanged their identification. Next, they need to form the actual Bluetooth connection. For this to work, each device needs the other’s network address, which should have been exchanged in the previous step.
- Connection. I can now use my headphones with my smartphone without fear of making a fool of myself by accidentally blaring my music for the whole world to hear. Once two devices have successfully established a connection, they can enter one of four modes (the master can command a slave to enter these modes):
- Active Mode. This is the regular mode in which data are regularly transmitted. This is the mode I want if I want to listen to my music.
- Sniff Mode. This is a more passive mode in which the device sleeps to save power. It’ll only activate when it detects a transmission during a set time interval.
- Hold Mode. Like Sniff Mode, this mode puts the device to sleep to conserve power. Unlike Sniff Mode, a holding device will awake after the set time interval expires, regardless of whether a transmission was detected.
- Park Mode. This mode is basically deep-sleep hibernation. The device goes to sleep, and it will only reawake when explicitly commanded by the master.
Devices usually don’t connect willy-nilly because that’d be a huge security liability. Instead, two connecting devices follow a one-time pairing process that leads to bonding. Once two devices are bonded, they don’t need to re-share their information with each other—they can just connect automatically. This works because the devices share a secret link key and some additional identification information with each other. That link key is stored in the devices’ memories and is used to identify each other in the future. Bonding is super convenient for me, because I would hate to need to re-pair my headphones with my smartphone every time I wanted to listen to music.
The pairing process itself is essentially an authentication process. During authentication, the devices exchange encryption information to be used in public-key cryptography. That authentication is used to validate all connections between devices. Why is authentication important?
The simple fact of the matter is that two Bluetooth devices are most vulnerable during the pairing process. Before they pair and bond, two unfamiliar devices must nakedly exchange their identification information across the network. That may not be a big deal for many users, but I highly doubt users would be fine with all their data nakedly traversing the Bluetooth network. In short, we want our Bluetooth devices to be able to communicate securely and with only known devices.
But, more fundamentally, we want to be able to follow a set-it-and-forget-it methodology using the one-time pairing process that we’ve just seen. For example, I want my smartphone to automatically recognize my headphones every time I use them together, but I also want to be assured that my headphones are the actual device recognized. In other words, I don’t want my smartphone to erroneously connect to a malicious Bluetooth-enabled device. The way to solve that problem? Bonding. Once my smartphone and headphones are bonded, they will have shared the secret code (i.e., the link key) that they use to identify each other. Without the link key, my devices would need to perform the pairing process constantly.
Public-key cryptography makes the pairing and bonding processes possible. Luckily for us, pairing and bonding are safe and secure operation nowadays. This wasn’t always the case, however. Indeed, it took some trial, error, and embarrassment for Bluetooth to finally implement security that was up to snuff.
Security Considerations
Like any good technical standard, the Bluetooth Core Specification has evolved over the last 20 years, especially when security has been concerned.[5] Historically, early versions of Bluetooth pairing used a type of block cipher known as SAFER+, but the Bluetooth implementation of that algorithm was broken in 2005. The Bluetooth security process therefore got a massive overhaul beginning with Version 2.1 of the specification.
Since Version 2.1, the Bluetooth protocol has implemented Secure Simple Pairing (SSP). This new, securer process uses NIST-approved elliptic curve cryptography and secure hash algorithms.[6] To make things extra secure, newer versions of Bluetooth include implementations of the AES block cipher in their authentication process. We won’t get into the nitty-gritty of the Bluetooth authentication protocol, but know that all this cryptography is what makes the pairing and bonding process secure. Moreover, that cryptography is what’s used to secure the transmission of data across the Bluetooth network.
What’s the point of SSP? This process is meant to protect users against passive attacks (i.e., eavesdropping) and man-in-the-middle (MITM) attacks. The randomness introduced in public-key key generation makes it difficult for a passive attacker to derive the private key required to establish an illegitimate connection—or decrypt messages, for that matter. SSP can also protect against a proactive MITM attack by forcing users to confirm connections with PIN keys.[7]
That last part is important for users like me. I would be very upset, for example, if an attacker hijacked the connection between my wireless headphones and my smartphone. They could interrupt my music streaming, send me different audio, or even steal the audio I was transmitting. Any of these scenarios would be awful, but I can rest easy knowing that the connection is safe once my headphones and smartphone are paired and bonded. All that said, attacks against Bluetooth aren’t unheard of.
There are several recorded attacks against Bluetooth devices. Perhaps the most nefarious is BlueBug, which allows an attacker to gain unauthorized access to a Bluetooth-enabled phone, including the ability to intercept calls. Admittedly, the heyday of these kinds of attacks was in the early-to-mid-2000s, and they were only effective because the technology was young and poorly implemented. Since that time, these attacks have become less effective and less frequent. That said, the solution to the problem is easy: Simply make your device non-discoverable. Better yet, disable Bluetooth on your device altogether. If an attacker can’t discover your device—or if your device isn’t Bluetooth-enabled—then there will be fewer attack vectors.
Despite its rocky years in the early 2000s, Bluetooth technology has revolutionized how we build and use networks. It would have been unheard of 30 years ago for me to use wireless headphones to listen to music—never mind my phone having the ability to stream music. Nowadays, people can’t seem to get enough of the wireless trend. Despite any underlying technical flaws, Bluetooth is a rapidly developing technology that will only become more useful in the future.
[1] Bored or have a long weekend coming up? Version 5.0 of the Bluetooth Core Specification is just 2,822 pages long. Trust me, it’s a brisk read.
[2] If you’re curious, Bluetooth divides the 2.4 GHz band into channels called “hops.” When two devices communicate, they follow a known algorithm to hop frequencies—that is, switch channels—to ensure messages are sent with low probability of interference or collision with other communications. This all happens usually upwards of 1,600 hops per second.
[3] There’s an important qualification here: Devices can only connect with each other if they support the same Bluetooth profile. Essentially, a profile specifies what services a device can perform. There are tons of profiles, so we won’t be getting into the details here.
[4] The terminology is unfortunate, but that’s the jargon chosen by the Bluetooth Special Interest Group. It’d be neat if this were connected to the Hegelian Master-Slave Dialectic, but alas, it isn’t.
[5] If you’re curious, there’s also the IEEE 802.15.1 Standard from 2005.
[6] Specifically, Bluetooth now uses Elliptic Curve Diffie-Hellman (ECDH) and the SHA-256 hash function. ECDH was chosen over normal Diffie-Hellman Key Exchange because the former is computationally less complex, which is great for many devices that implement Bluetooth.
[7] Like many numeric passkeys, the Bluetooth PIN key is typically a six-digit numeric value. This means there are 106 = 1,000,000 possibilities, meaning an attacker has a 0.0001% chance of guessing the right code. In the milliseconds it takes to authenticate a legitimate connection, even a clever attacker would likely fail to guess the correct PIN.
