How I Hacked 10 Billion Bluetooth Devices: My Pursuit of Overlooked Technological Challenges

I am thrilled to finally pen down this journey of mine into the world of cryptography and hacking.

Back in 2016, I found myself introducing myself to Prof. Eli Biham, a pioneer in modern cryptography. I had been teaching Differential Cryptanalysis, a technique developed by Biham, to a group of computer science students just a few years prior. This technique revolutionized the way we approach block ciphers and laid the foundation of modern cryptography.

As an overconfident 21-year-old, I boldly walked into Biham's office and declared my intent to become his Masters' student with my research focused on "Breaking Bluetooth". Admittedly, at this point, my knowledge about Bluetooth’s encryption was minimal, and my understanding of its workings, barely above ground.

One may wonder, why did I audaciously believe I could hack Bluetooth, a global communication protocol with over 10 billion devices relying on it?

To understand this, we have to rewind to 2010. Bluetooth 4.0 was launched, introducing Bluetooth Low Energy and essentially splitting Bluetooth into two distinct protocols, Bluetooth BR/EDR and Bluetooth LE (or Bluetooth Smart). In 2013, Mike Ryan, a security researcher, exposed how Bluetooth LE's pairing PIN could be cracked in less than a second using a common laptop and a brute force technique. This raised two important questions - how was Bluetooth 4.0 released with such an obvious security gap, and how did it take three years to discover this flaw in such a widely used protocol?

In December 2014, the Bluetooth Special Interest Group launched Bluetooth 4.2, which included a redesign of the pairing process. They introduced authenticated Elliptic-Curve Diffie-Hellman (ECDH) cryptographic key exchange to address Ryan’s discovery. This cryptosystem was essentially the older Bluetooth BR/EDR with minor tweaks. Considering the blatant initial flaw and the time taken to discover it, I was confident that another vulnerability was waiting to be discovered.

I decided to dive deep into the Bluetooth Core Specification, a convoluted document spanning over 5,000 pages. It soon became clear that this document was not reader-friendly, and it was unlikely that anyone, especially someone with a cryptanalysis background, was examining it thoroughly. This, I believed, explained why it took three years to expose the first vulnerability.

During an intense three-month period, my existence orbited around the colossal Bluetooth Core Specification. This document was packed with convoluted protocols and definitions, ranging from the physical to the application layer. Despite my diligent efforts to consume its contents, every day felt like an uphill struggle. The daunting task often left me feeling desperate; the challenge appeared unviable.

However, as a hands-on individual who thrives on practical problem-solving and real-world applications, this was not my natural habitat. The daily grind of reading, re-reading, and theorizing felt tedious, even draining. So I decided to shift my approach to more hands-on research. 

I feel it's necessary to point out that self-conducted hands-on research into Bluetooth, particularly its link layer protocol, presents a considerable challenge. Despite its widespread use, especially within the Internet of Things (IoT) and mobile devices, Bluetooth's link layer proves exceptionally challenging to manipulate. Its implementation is found in either kernel drivers or, even worse, the firmware of wireless cards. This is a stark contrast to WiFi, which provides a "Monitor Mode" allowing for raw packet manipulations. During this period, Bluetooth offered no such functionality, leaving those without the skill or inclination to write kernel code or delve into firmware hacking with an extremely restrictive command interface. A noteworthy distinction between Bluetooth BR/EDR and Bluetooth LE was the migration of the link layer's implementation from firmware to the kernel. This change was implemented to facilitate the creation of simpler and more cost-effective Bluetooth Systems on a Chip (SoCs).

Returning to the heart of my investigation, I decided to begin by examining my Dell Precision M3800, specifically its Broadcom BCM4360 wireless card. Regrettably, the BCM4360 did not support Bluetooth 4.2, but rather than opting for an equipment upgrade, I chose a more challenging path. I decided to delve into the BCM4360's firmware, the heart of Bluetooth BR/EDR's link layer. I was on a quest for insights into the chip's internal workings. Fortuitously, Broadcom's wireless unit had recently been acquired by Cypress (which subsequently fell under Infineon's ownership), who were notably more forthcoming with their data sheets. Despite the absence of the BCM4360's datasheet, I managed to unearth valuable information from the equivalent document for its close relative, the BCM4339, rebranded as the CYW4339. This document was a goldmine, containing comprehensive pinout information and a detailed block diagram of the System on a Chip (SoC).

Delving into these datasheets, I stumbled upon a section labeled "Vendor-Specific HCI Commands" - a find that immediately piqued my interest. Within this section, I found three commands: "READ_ADDR", "WRITE_ADDR", and "JUMP_ADDR". The potential they offered was significant - using these commands, I realized I could directly interact with and manipulate the SoC's memory, providing me with a far greater degree of control than I had ever imagined.

This newfound ability opened up a world of possibilities. On exploration, I quickly identified several intriguing buffer overflows, signaling security gaps that could be exploited. But it wasn't about identifying these flaws - I also discovered that I could patch the callback table that holds the link layer state machine. This enabled me to not only alter incoming Bluetooth link-layer packets but also write arbitrary packets, essentially granting me an unprecedented level of control over the communications.

Hold on a second! The primary goal here is to break Bluetooth, not merely to tinker with Broadcom SoCs. Returning to the heart of the matter - the Bluetooth pairing protocol - we find a relatively simple concept at its core. The protocol employs Elliptic Curve Diffie-Hellman (ECDH), coupled with a cryptographic hash applied over the ECDH public keys from both devices. From this hash, a six-digit PIN code is derived, acting as the authentication mechanism. The users can then compare these PIN codes or read them from one device and enter them into another, ensuring the public keys remain unaltered and the shared secret is safeguarded.

Digging deeper into Broadcom's implementation of this pairing process, I stumbled upon a peculiar observation. I encountered a surprising function call:

Here, 32 represented the length of the pubkey_buffer, translating into 256 bits number.

However, a moment of realization hit me. The ECDH public keys are comprised of two coordinates - X and Y - each 256 bits long. Why then, does the ‘memcpy' function only consider a buffer of 32 bytes? Surely, this must be an error! But, if it indeed were a bug, it would result in a different PIN code from other devices, inevitably leading to failed pairings and user frustration.

Upon revisiting the core specifications, on page 600, I discovered a surprising detail - the hash function (or 'f4') only takes into account the X coordinate of the ECDH public key, effectively excluding the Y coordinate from the calculation process.

With the surprising revelation that Bluetooth's standard architects chose to exclude the Y coordinate from the validation process, we must explore the potential implications. Put simply, this loophole could be catastrophic for Bluetooth's security. By forcing the Y coordinate to zero, we can generate a public key (X, 0), which is a point on another elliptic curve with an order of two. The impact of this alteration is far-reaching; it means that in a quarter of all instances, both devices will end up computing the shared secret key as the identity element. This statistical anomaly hands a potential attacker a one-in-four chance to accurately guess the secret key, thereby gaining unimpeded access to all Bluetooth traffic. The vulnerability of the entire Bluetooth network, therefore, lies in this seemingly insignificant technical detail.

This simple but potent attack was successful against most Bluetooth implementations including Android, iOS, MacOS, Windows, Linux, Broadcom, Qualcomm, and Intel, suggesting a universal vulnerability in the Bluetooth protocol.

Fortuitously, the introduction of an additional layer of software validation could effectively counter this attack. However, the reality is that a vast majority of Bluetooth devices may remain unpatched due to the update challenges.

It's my hope that by sharing this personal journey, I can inspire others to strategically choose and confront the substantial challenges often hidden in plain sight, unaddressed, and neglected.

These problems often persist for years, not because they're insignificant, but because they are either out of the mainstream focus or present accessibility challenges. Yet, it's these very issues that can have the most profound impact on our world. As aspiring researchers and technologists, it's our responsibility to illuminate these hidden flaws, driving advancements and innovations that form the backbone of our existence.

‍