Bluetooth for Bad Guys

Criminals have been skimming debit and credit card information by tampering with point of sale terminals, PIN pads, gasoline pumps, and ATMs for quite a while now. The first time I heard of Bluetooth being used in such cases was from this SparkFun Electronics news blurb a couple years ago. Malicious hardware installed in a Canada retailer's PIN pad intercepted customer data and transmitted it via Bluetooth to the attacker's device, perhaps a laptop in a nearby parking lot. At the time it seemed like a clever use of the technology by a Canadian ne'er-do-well but probably not the start of a trend. I was wrong.

As Joshua Wright recently pointed out, Visa is informing merchants about similar crimes that took place around the same time in Utah. Skimmers have also been found in Florida and elsewhere. Just this week, customers of Lucky Supermarkets in California found out that a similar attack was the reason their bank accounts were recently drained. This isn't just one clever crook; this is a criminal industry at work.

The technical reasons that Bluetooth is an attractive technology for this application are nicely outlined in Joshua's article, but we wouldn't see so many actual attacks were it not for commercial availability of Bluetooth skimmers sold on the criminal underground. There is an industry producing hardware for crime just as there is an industry producing software for crime.

How can you protect yourself as a customer? The best advice I can think of is to consider the liability of payment methods. There is a reason I like to carry some cash. There is also a reason I strongly prefer to use a credit card over a bank debit card. With a credit card (in the US, at least), the financial institutions and merchants bear most of the burden of liability. As long as I check for unauthorized transactions before paying my bill every month, I don't have much to worry about. Once, many years ago, someone emptied my checking account. I figured out what had happened and managed to convince my bank that the bank's own misguided security practice had allowed it to happen, but guess who bore the burden of a zero balance until that was resolved?

How can you protect yourself if you are a retailer or financial institution? This is a much more difficult problem. For starters, you should read Joshua Wright's article and the Visa bulletin. Josh has some nice things to say about my Project Ubertooth, but he also has some criticisms, mostly pointing out features yet to be developed. The first item on his wish list is frequency hopping, something I am working on now. He also points out the need to improve Bluetooth device fingerprinting, an area of research that has been advanced in recent years primarily by JP Dunning.

When I read about real life attacks on retailers and customers, sometimes I imagine how I could use technology to catch the crooks. Frankly, it would be hard, and it would be especially hard to deploy tools that would allow more investigators to do the same. Bad guys are using Bluetooth (and potentially other wireless technologies). We need Bluetooth tools for the good guys too.

I guess, if there is a lesson to be learned from all this, it is that hardware security matters. If an attacker can get in between a user and a system, the security of the system will fail in almost any case. Advocates of the Bring Your Pwn Device (BYOD) trend might want to pay attention. (That was an honest typo, but I decided to keep it!)

comments on SP 800-121 Rev 1 draft

The following is an email I sent to NIST in response to a request for comments on the draft Guide to Bluetooth Security (NIST Special Publication 800-121 Rev. 1).

Thank you for your efforts to produce and update SP 800-121! Although I have some criticisms, your document is important and unique.

My principal concern about the guide is that the recommended practices are too weak to support the safe use of Bluetooth. Looking at the SP 800-153 draft (Guidelines for Securing Wireless Local Area Networks), I see several recommendations listed in the Executive Summary that would be just as applicable to Bluetooth:

"When planning WLAN security, consider the security not only of the WLAN itself, but also how it may affect the security of other networks."

"Have policies that clearly state which forms of dual connections are permitted or prohibited for WLAN client devices, and enforce these policies through the appropriate security controls."

"Ensure that the organization's WLAN client devices and APs have configurations at all times that are compliant with the organization's WLAN policies."

"Perform both attack monitoring and vulnerability monitoring to support WLAN security."

"Conduct regular periodic technical security assessments for the organization's WLANs."

My second concern is that it is unclear how to implement many of the recommendations. Unfortunately this is more a problem with Bluetooth itself and the available tools than with your document. Along with others in the information security community, I am working to develop Project Ubertooth into a tool that will bridge the gap as much as possible, but more needs to be done.

Third, I have some specific comments and criticisms:

It is incorrect to say that Frequency Hopping Spread Spectrum (FHSS) provides even "a limited level of transmission security." Other features of Bluetooth provide security benefits. FHSS provides interference avoidance.

It is easy to overstate the security benefits of power control. I suggest eliminating discussion of transmit power from the document.

Good job on citing some important work! (Spill/Bittau, Wool/Shaked)

Where you state, "If that device remained discoverable, its location could be tracked by an adversary", it should be corrected to state that discoverability is not required. See Spill/Bittau and this blog post:

http://ossmann.blogspot.com/2011/07/discoverability-is-not-mitigating.html

Table 4-1 is an important contribution that I will recommend to many people.

Section 4.2 "Bluetooth Threats" seems weak. The list of threats is disjointed, inconsistent, and in places dated.

Thank you again for your contribution. I hope you find some of these comments helpful.

Sincerely,

Michael Ossmann
Great Scott Gadgets
mike@ossmann.com
http://greatscottgadgets.com/

Power over Ethernet and the Throwing Star LAN Tap

Since handing out hundreds of Throwing Star LAN Tap printed circuit boards as business cards at DEF CON, I've received a number of interesting questions about the device in my email. A couple people were hoping to use Throwing Stars to monitor connections that use Power over Ethernet (PoE). When I designed the current version of the Throwing Star LAN Tap, I decided to pass all eight conductors through from J1 to J2 (the target ports) even though this necessitated the addition of two filtering capacitors. I did this primarily to support RS-232 monitoring (a feature that I imagine is very rarely used), but I also thought that having eight conductors might be handy for other things such as PoE. It wasn't until recently that I actually verified PoE capability, however.

PoE allows a device to be powered by direct current (DC) running over an Ethernet cable that may also be used for communication. It is popular for VoIP telephones, IP security cameras, wireless access points and other network-connected devices that are commonly deployed at multiple locations within a building. There are several different ways that PoE has been implemented over the years, but most devices these days follow the IEEE 802.3at-2009 standard or its similar predecessor, IEEE 802.3af-2003. I looked at these standards and also at the most common non-standard implementations and found that they are all compatible with the Throwing Star LAN Tap.

Twisted pair Ethernet cables consist of eight wires arranged into four pairs. In some cases two of those pairs are unused. Each pair carries a differential signal with one wire carrying the inverse of the signal on the other wire; when one goes high, the other goes low. This is an alternating current (AC) signal.

What all of the PoE schemes have in common is that they introduce a DC bias between one pair and another. In the figure to the left, the purple and green lines represent the voltage on one pair and the blue and orange lines represent the voltage on a second pair. In each pair, the AC component (the rapidly changing difference in voltage between the two wires) is relatively small. This is the signal that carries network data. From one pair to the second pair there is a larger voltage difference, the PoE DC bias.

The Throwing Star LAN Tap provides a DC path for all eight conductors between the target ports, J1 and J2, but it only extends a subset of those conductors to the monitoring ports, J3 and J4. This is done in such a way that Power over Ethernet on the target network can pass through the tap but does not extend to the monitoring ports. It's almost like I meant to do that. :-)

Spread Spectrum Clock Generation, Emission Security, and You

The following is a transcript, more or less, of a short talk I gave at ToorCon Seattle 2011. There was no video made of the presentation, so I'm doing this instead. The talk was a preview of some research into how spread spectrum clock generation affects the risk of eavesdropping on unintentional Radio Frequency (RF) emanations from electronic devices.

Probably half of you are sick of hearing me talk about Project Ubertooth and the other half will be, so today I'm talking about something completely different: clocks. Not the kind of clocks you hang on a wall but periodic electrical signals that drive the timing of digital electronics and the circuits that produce those clock signals. Every digital electronic device has a clock. When you talk about your fancy, new, 3.0 GHz computer, you are referring to the clock frequency.

A traditional clock signal looks like this. The top graph shows how the voltage changes over time. The timing is fairly consistent. If you plot the signal in the frequency domain, the bottom graph, you get a sharp spike at the clock frequency. Note that I am ignoring harmonics here and have zoomed in on the region around the fundamental clock frequency.

About twenty years ago, some guys in Kentucky had this idea to modulate the frequency of a clock over time. They called the technique Spread Spectrum Clock Generation (SSCG). A spread spectrum clock signal looks something like this. The frequency of the signal varies over time. If you look at the signal in the frequency domain, the bottom graph, you see a plateau over a range of frequencies instead of a narrow spike. (If you are familiar with spread spectrum communication systems, note that I'm talking about something only vaguely related.)

SSCG became popular, first with PC manufacturers and more recently for other electronic devices. The technique is used for one and (as far as I know) only one reason: to make it easier to pass electromagnetic compatibility (EMC) testing required by the FCC and other regulatory bodies around the world. EMC regulations are intended to limit RF emissions of electronic devices in order to avoid harmful interference to radio systems and other neighboring electronics. SSCG doesn't do anything to reduce the radiated power of such emissions; it simply shifts their frequencies around so the EMC test equipment doesn't register too high a power level at any one frequency. The electronics manufacturers are playing a shell game with their clock frequencies in order to evade detection.

A few of you may have seen a recent blog post of mine, If it isn't open, it didn't happen. In it I proposed a citation boycott: scientific works not open to the public shouldn't be considered to have been published at all and should not be cited. Well, I'm about to break my own boycott. Actually I am declaring an exception, an exception for ridicule: It is okay to cite a non-open scientific work if the citation is made for the purpose of ridiculing said work.

About ten years ago, there was growing concern that SSCG might be bad for electromagnetic compatibility. It was clear that the practice resulted in electronic devices that produced higher overall radiated emissions. Plus people were starting to get the idea that wideband interference from devices with spread spectrum clocks could be worse for radio signals than narrowband interference from traditional clocks, even when comparing the two at the same radiated power level. In response, Harry G. Skinner and Kevin P. Slattery of Intel published a short paper called Why Spread Spectrum Clocking of Computing Devices is Not Cheating. It is a truly awful paper. The authors, Intel, and the IEEE should all be embarrassed to have their names on it. It features bad theory, bad analysis, bad experimentation - just about everything that could be wrong with scientific literature is evident in this biased piece of garbage. I will limit myself to pointing out just one fallacy in detail.

The authors claim that concern over the wide bandwidth of SSCG emissions is misplaced because the emissions aren't actually wide at all. If you configure your test equipment the way the FCC requires, then the emissions appear to cover a wide range of frequencies. This doesn't tell the whole story, they say.

They propose looking at the emissions over shorter windows of time. A quick snapshot would show a signal that is actually narrowband, similar to the frequency spike produced by a traditional clock. Subsequent snapshots show that the signal is still narrow but shifted to different frequencies. (Click the graph for sophisticated and professional-looking animation.)

To some extent, the authors are correct, but they conveniently leave out a rather important detail. If you look at the signal the way the FCC requires, you see a wideband emission consisting of power at various frequencies under the regulatory limit.

If, however, you look at the signal the way the authors propose, you see a narrowband emission that exceeds the regulatory limit. You can't have it both ways, guys. You either show that the signal is wide, averaged over a range of frequencies, or you reveal that the radiated power exceeds the legal limit and that your spread spectrum clock is exploiting a loophole in the peculiarities of the FCC test specification.

Amazingly enough, this unscientific trash seems to be pretty much the last word on the subject. I think it is time for fresh eyes to look at spread spectrum clock generation. I've been looking at it for a little while and have developed two hypotheses.

Hypothesis #1: The increasing prevalence of spread spectrum clock generation is detrimental to the operation of a wide variety of radio systems. SSCG is becoming popular not just in PCs but in smartphones, LCD panels, and other high speed electronic devices. It is required by interface standards such as SATA and SuperSpeed USB. As more and more of these devices are deployed (probably billions per year), the noise floor is raised for everyone trying to use the radio spectrum. This hypothesis is hard to test, so I'm skipping it.

Hypothesis #2: Devices with spread spectrum clock generation are more susceptible to eavesdropping than those without. I'm talking about emission security, the problem that electronic devices tend to unintentionally emit radio signals that can reveal otherwise secret information. Someone might be able to discover the password for your bank account, for example, by monitoring radio signals produced by your computer.

There are two reasons I think SSCG results in an increased susceptibility to eavesdropping. The first is that SSCG devices produce stronger emissions. This is almost by definition: the reason SSCG is deployed in the first place is to get away with emissions stronger than those that would be permitted from a device without SSCG. The second is that SSCG emissions feature spread spectrum signatures that make it easier for an eavesdropper to pick the signals out of the noise. This will be a little more difficult to demonstrate, but techniques from the field of digital radio communication could be applied to the problem.

In the coming months I will attempt to test hypothesis #2. I'll start by analyzing the waveforms produced by popular spread spectrum clock generator integrated circuits, and then I will apply the knowledge gained to the problem of eavesdropping on consumer electronic devices. If you are interested in helping with this research, I would love to hear from you!

Discoverability is Not a Mitigating Factor

Four years after BlueSniff: Eve Meets Alice and Bluetooth by Dominic Spill and Andrea Bittau, people are still saying that Bluetooth vulnerabilities can be mitigated by turning off discoverability. If there is one thing that should have been learned from all of the Bluetooth security research done over the last few years, it is that a non-discoverable device is no safer than a discoverable one, but perhaps this message has been buried too deeply in technical presentations. Let me try to make this point clearer.

A discoverable Bluetooth device is one that is willing to respond to an inquiry, a single packet transmitted by any device looking for others. When you tell a device to "find new Bluetooth devices" it transmits a large number of inquiry packets and waits for responses. A discoverable device's inquiry response contains information including the device's address (BD_ADDR). This address can then be used by the inquirer to initiate a connection between the two devices.

Since most Bluetooth vulnerabilities can only be exploited once a connection is established, people used to recommend turning off discoverability. The reasoning was that, without a way to learn the target's address, an attacker would be unable to connect to the target and exploit any vulnerability. This idea that it is possible to keep a Bluetooth device address secret is completely wrong.

Turning off discoverability is like hiding the SSID of an 802.11 network. It prevents people from casually or accidentally connecting to your Bluetooth device. It might be worth doing for this reason alone, but I no longer recommend it as a security practice. Turning off discoverability does nothing to thwart skilled attackers. Worse, it creates a false sense of security and makes it harder for the good guys to notice that Bluetooth devices are in use.

A BD_ADDR is a 48 bit number (it's a MAC address) that is unique to a particular Bluetooth device. It consists of three sections, the 16 bit Non-Significant Address Part (NAP), the 8 bit Upper Address Part (UAP), and the 24 bit Lower Address Part (LAP). In order to connect to a target, an attacker needs only the UAP and LAP.

LAP sniffing is easy. Every Bluetooth packet contains the LAP in cleartext. Spill and Bittau showed how to sniff LAPs with a USRP for about $1000. Now it can be done with an Ubertooth One for about a tenth of that price. It can even be done using Travis Goodspeed's method for promiscuous sniffing with lower cost platforms. LAP sniffing has always been easy, but now the tools and methods are more well known.

The UAP is only slightly more difficult for an attacker to learn. Project Ubertooth and gr-bluetooth include software that implements automatic UAP determination based on passive observation of just a few packets. The function is integrated into the Ubertooth Kismet plugin. Even without this method, it isn't hard to figure out the 8 bit UAP. In Hacking Exposed Wireless, Second Edition, Joshua Wright showed how to determine the UAP with a simple brute force attack.

Turning off discoverable mode doesn't make your Bluetooth device any more secure. If your security model depends on secrecy of the BD_ADDR, you are doing it wrong.

And, by the way, frequency hopping doesn't help you either.

If it isn't open, it didn't happen.

A few weeks ago I watched The Architecture of Access to Scientific Knowledge, a thought-provoking lecture given by Lawrence Lessig at CERN in April. In it, Lessig argues that the application of copyright by publishers in the scientific community is harmful to science itself. If you have any interest at all in the progress of human knowledge, you should watch it.

The talk reminded me of Shaking Down Science, a blog post by Matt Blaze some months back. Blaze pointed out the very specific wrongs committed by two major publishers in the computer science field, the ACM and the IEEE. Demonstrating the very kind of leadership encouraged weeks later by Lessig, he announced that he would stop participating in these two organizations as a response to their policies that prevent open access to scientific knowledge.

I applaud this decision, but I don't think it goes far enough. I propose a specific boycott that anyone who publishes scientific research or who writes or talks about research can participate in: a citation boycott. If a paper is "published" only in a manner that prohibits open access by the public, it shouldn't be considered to have been published at all, and it shouldn't be cited in other works. If it isn't open, it didn't happen.

Easy for me to say, I know. I'm not in the habit of publishing scientific papers of my own; I just present the occasional result at a hacker con. Academic rigor demands that certain prior work central to the subject of a new paper be cited appropriately, of course, but I read enough scientific literature to know that plenty of citations are little more than filler. It should be possible to leave out a large percentage of non-open references from most bibliographies without undermining academic integrity.

We are in an age of democratization of science, when people like me, outside of the academic community, are able to participate in the advance of knowledge to an unprecedented degree. When those of us without access to scientific literature contribute, we often participate in this boycott without meaning to. We simply don't know that the prior work exists or can't afford to pay to read it. Maybe this citation boycott will gain some supporters in academia; maybe it won't. Either way, I believe that amateur scientists are central to the future of science and that researchers today who don't insist on open access for their own works will soon be forgotten.

Perhaps a strict boycott isn't possible in the academic world, but the trend is growing regardless. Even in fields far flung from science, reusable, reproducible works are gradually supplanting those that are more restricted. Maybe instead of calling it a boycott I should call it a bias, an attitude, a mantra: If it isn't open, it didn't happen.

Ubertooth spectrum analyzer

I took a break from hardware and manufacturing concerns tonight and sat down to write some code. I probably should have worked on the USB bootloader, but instead I wrote a simple spectrum analysis function for the Ubertooth platform. Similar to other transceiver IC spectrum analyzers (like my IM-Me implementation), it tunes its receiver to one frequency at a time and records the received signal strength before hopping to the next frequency.

For now I'm just dumping a table of values to a file and plotting it with gnuplot. In the future perhaps a more sophisticated user interface could be built, maybe integrating with Mike Kershaw's Spectrum Tools or something like that. In this plot, you can see a busy 802.11g network on channel 1 (centered at 2412 MHz) and some Bluetooth traffic (a device performing an inquiry scan) throughout the band.

While testing this, I tried pushing the limits of the CC2400's tuning range for the first time. The device I tested functioned with its receiver tuned from 2268 to 2794 MHz. (The supported range is 2400 to 2483.) I didn't actually generate test signals to validate that it could see stuff throughout the entire range, but my guess is that it is usable across the whole tunable range but with degraded performance at the extremes.

The spectrum analysis code is available in the Ubertooth repository and will be included in the next release. Let me know if you do anything interesting with it. There are just a few days left to pick up one of the first batch of boards by making a pledge on Kickstarter.

a year without ice

For the first time in several years, Lars and I are sitting out of the World Ice Art Championships. I'm rather busy with other things this year, and Lars would have had even more difficulty than usual taking time off work. I'm pretty sure we'll be back at it next year, but this time I'm enjoying watching the Single Block Classic web cams from far away in Colorado.

Of course, this winter hasn't been entirely without ice. I haven't picked up a chisel yet, but Lars made a few sculptures (with help from Celso) for his school's winter ball, and both of us have started experimenting with new methods of producing our own ice for carving.

For sculpting, it is almost always desirable to have very clear ice, not white ice, but making a sizable chunk of clear ice is tricky. The problem is that liquid water contains quite a bit of air and often some sediment or other impurities that become more obvious when frozen. As the ice forms, the crystal structure forces the air into pockets that become large enough to see, and all those little bubbles make the ice white. White ice is often unappealing visually, and it is structurally weaker.

The most common technique used to produce commercial carving blocks is to continuously circulate the liquid water as it cools, keeping the top surface in particular from freezing before the rest of the block does. Without this recirculation, ice naturally forms on the top surface first, forming a barrier that prevents air from escaping the rest of the block. Lars had the idea that, instead of recirculating the water, we could keep the top surface from freezing first by simply heating it directly. Here you can see him extracting a large block from the giant "Ice Cube Tray" in his yard. I believe he used a small aquarium heater to do the job, and he was pleased with the result.

I want to try the same thing in Colorado, but I don't have weather so cold as Lars does in Fairbanks. I am afraid that a simple aquarium heater might produce too much heat, but I will give it a try. I figure the worst case scenario is that I have to build my own temperature control device. Not wanting to handle ice cubes as big as Lars's, I picked up a 20 gallon trash can for my experiment. I didn't even have a simple heater when some particularly cold weather came to town recently, so I just filled the bin 3/4 full of well water and set it outside to freeze. This is so I'll be able to compare subsequent results with heating to the result without heating.

As you can see from the block of ice split in twain, the result was terrible. Not only was the entire block full of tiny air bubbles, but a large air pocket formed in the center. When mostly clear ice has a central region with lots of little bubbles, that region is called the "feather." This is far worse. Interestingly, I didn't even have to split the ice myself. I pulled it out of the trash can on a relatively warm day and only looked at the surface. A day or two of above-freezing temperatures later I found that it had split apart on its own!

Throwing Star LAN Tap

Not long after I designed the 5-in-1 Network Admin's Cable several years ago, I built the first Throwing Star LAN Tap. It is a simple cross of CAT5 cable spliced together to permit in-line monitoring of Ethernet connections. As a passive (unpowered) device, it is limited to sniffing 10BASE-T and 100BASE-TX, and each sniffing connector monitors only the network traffic going in one direction. You just insert it in-line on a target Ethernet connection (between a computer and a switch, for example), and then you can use monitoring tools like tcpdump or Wireshark on a computer attached to one or both of the sniffing connectors. The sniffing ports are receive-only, so there is no danger of your monitoring station accidentally transmitting packets onto the wire.

Despite its limitations, the device has come in handy countless times over the years. It is small enough that I can keep it in my backpack all the time. To sniff traffic in both directions, you have to monitor on two ports, but you'd be surprised how often sniffing just one direction at a time is sufficient for monitoring and troubleshooting tasks.

In 2007, Jason MacPherson wrote to me describing his extension of the Throwing Star LAN Tap design. (Alas, the link he sent is now broken.) He didn't bother with the throwing star form factor, instead opting to build his device in a box. The cool thing he did was to use the complete pinout of the 5-in-1 cable (all eight conductors) such that his tap could be used for monitoring either Ethernet or RS-232 serial connections. Why didn't I think of that?

Ever since then I've thought about building a new throwing star using Jason's approach. Another improvement I've had in mind is to switch from male RJ-45 plugs to female sockets. Although the male version is nifty and tiny, it invariably must be used with two or three couplers. Plus the tabs eventually break off the plugs, which is particularly annoying when they are attached to a very carefully spliced device.

Within the past year I've learned how to design printed circuit boards, so I decided to try building a female throwing star. There was one new problem I had to solve: how to handle 1000BASE-T (Gigabit Ethernet). Because 1000BASE-T signals travel in both directions simultaneously on each individual wire, it is impossible to build a passive tap for the technology. To properly tap 1000BASE-T, you need an active device such as a powered LAN tap or a switch with a monitor port. In a pinch, though, it is nice to be able to pull something out of your bag to get the job done, so I opted to make my throwing star compatible with 1000BASE-T in the only way I could, by breaking 1000BASE-T:

Since 1000BASE-T uses two more pairs of conductors than 10 or 100 Mbit Ethernet, I bypassed each of those extra pairs with a 220 pF capacitor. (Disregard the erroneous 22 pF marking in the photos.) This filters out the high frequency signals of 1000BASE-T, forcing the target devices to revert to 100BASE-TX which can then be monitored. The capacitors don't adversely affect lower frequency RS-232 signals, so all eight conductors function when monitoring serial connections. Sure, it's an ugly hack, but it's an ugly hack that fits in your pocket.

I figure that most folks who are interested in Bluetooth monitoring have occasion to sniff Ethernet from time to time, so I'm getting a bunch of kits produced, and I'll drop one into each reward package sent to backers of Ubertooth One on Kickstarter at the $100 level or higher. I'll also include a bare PCB with the $15 and $30 reward packages. I'm thinking about handing out PCBs as business cards at hacker cons, but I can't decide if it is a really good idea or a really bad idea. What do you think?

Open source design files are here.

Update: Throwing Star LAN Tap Kits are now available.

Project Ubertooth: Building a Better Bluetooth Adapter

Video of my presentation, Project Ubertooth: Building a Better Bluetooth Adapter, at ShmooCon 2011 is now online. You can download the entire video in high quality from shmoocon.org or watch it in your web browser. In the presentation, I demonstrated Ubertooth One, the world's first open source, widely available, low cost Bluetooth test tool, and I described my two year design journey starting as an electronics novice. This was one of the most fun talks I've ever given, and I want to thank ShmooCon for making it happen and everyone who attended for participating. I'm making the slides available, but, as is typical of my presentation slides, they really don't stand alone.

Shortly before the presentation, I was interviewed by Hak5. The interview covered a lot of ground and included quite a bit of discussion beyond the content of the presentation.

At ShmooCon I announced the start of a pledge period on Kickstarter to fund an initial production run of Ubertooth One boards, and the pledge goal was met in just four days! There is still time remaining in the pledge period for anyone who would like a board. Thank you to everyone who has pledged support!

first Bluetooth Low Energy packets

A package arrived today containing my first Bluetooth Low Energy equipment. Bluetooth Low Energy is a new wireless technology within the Bluetooth specification suite. It provides capabilities similar to Basic Rate Bluetooth, which has been around for ten years, but consumes less power while doing so. Consumer Bluetooth Low Energy products likely won't hit the market for a few months, but engineering development tools have recently become available.

This kit from Texas instruments contains a two small CC2540 development boards, one in the form of a keyfob and the other in a USB dongle form factor. For now I'm not interested in developing firmware for the CC2540. Frankly I'm annoyed that TI has chosen not to document the internal radio properly. Despite its limitations, however, this kit provides a quick and easy way to generate Bluetooth Low Energy wireless packets over the air, and I'm using it (so far just the keyfob) to help me develop Low Energy sniffing capability on the Ubertooth platform.

It only took a few minutes to tweak the Ubertooth code such that it would demodulate Bluetooth Low Energy packets properly, but I don't have much in the way of automated packet detection or decoding. Using a fairly crude method, I've searched through the demodulated bits to find the advertising packets transmitted by the keyfob. These are packets transmitted on one of only three advertising channels in an effort to locate another device to communicate with.

One of the key differences between Basic Rate and Low Energy is that Low Energy devices are able to locate each other and initiate communications using this advertising method much faster than Basic Rate devices ever could. Basic Rate devices waste a lot of power keeping connections alive; Low Energy devices will just tear down connections entirely and go to sleep knowing that they can wake up and find each other again very quickly. One of the reasons the method is fast is that advertising is only done on three channels, and that makes it easier for a passive observer to capture the process.

I've also captured the packets using a USRP. Glancing at the waveform and spectrogram, it is difficult to distinguish this packet from Basic Rate Bluetooth. I haven't written any GNU Radio code to demodulate the raw waveform, but I am replaying the recorded file through the USRP as a simple way to produce a repeatable test vector.

Ubertooth One on Kickstarter

At ShmooCon over the weekend, I gave the first public demonstration of Ubertooth One, a smaller and more powerful Ubertooth hardware platform. I also announced the beginning of a pledge period on Kickstarter that allows anyone to take part in the first production run of commercially available Ubertooth Ones. If you would like an Ubertooth One of your own, I encourage you to consider building one or making a pledge on Kickstarter. Thank you for your support and for helping to spread the word!

Ubertooth video and news

Video of Ubertooth Zero, a preview, my talk at ToorCon 12, is now online (part 1, part 2). This includes the first public demonstration of Bluetooth sniffing with the platform. Since ToorCon, I've been working hard on Ubertooth One hardware and software. I've had to work through some production delays and errors with Ubertooth One circuit boards, but I have a good feeling about the next revision which is in production now.

I am excited to announce that my talk, Project Ubertooth: Building a Better Bluetooth Adapter has been accepted for ShmooCon 2011. This will be a longer presentation telling the complete story of the development of Project Ubertooth and demonstrating new capabilities of the platform (hopefully with working Ubertooth One prototypes). ToorCon was a preview, but ShmooCon will be the big debut.

I posted a new file release of the Ubertooth project repository tonight. This includes the new bluetooth_rxtx firmware that is starting to resemble my vision for the USB interface. The host code doesn't do much more than the ToorCon demo at this point, but quite a bit has been done to enable future enhancements.