Hello.  I am Grant Bugher I'm giving my talk on detecting Bluetooth surveillance systems.  First, start off a bit about myself.  I do work in security.  But I don't work in anything that has anything to do with blue tooth surveillance system or traffic control or anything of the sort.  So, this is my own research and has nothing to do with my employer or their opinions.
 
     This is really a little project that came about from reading a news story, it was -- I saw something mentioned little white boxes by the sides of the highway and people wondering what they were.  Someone pointed out, they're Bluetooth sensors.  Well, that's an interesting idea, why would there be Bluetooth sensors on the highway?
 
     I think why this is in why in DC101 this is a story of how do you go from I read something interesting in the news to, well let's just build something and find out what it's doing.  Just put something together and see what happens.  So what I did at first was just start, look around, look at the literature see what is out there about why would there be Bluetooth sensors on the highways?
 
     And well, here are a couple of slides from the federal highway administration, this is from the Wisconsin DOT, showing a Department of Transportation Bluetooth sensor.  You got a field device with a Bluetooth scanner, it's a standard commodity Bluetooth, not anything special. 
 
     It's hooked up -- hooked up to a database server then it detects the Bluetooth enabled devices in your car, whether that's your cell phone, the hands-free function of your car, Bluetooth headset you're carrying with you, whatever else.  And it relays that back to the database server. 
 
     As you see in that second slide over there, the purpose of this is you detect Bluetooth at one known location you detect the same hack again at another location now you know the speed of traffic between those locations because you know how far apart they are you know the time delay between the mac addresses.  That's why the DOT started putting these out there.  And they're everywhere. 
 
     Here we have example of a little white box being installed alongside the interstate, you'll see a lot of -- the white box with the solar panel on top is probably the most common one you'll see but it's far from the only one you'll see.  These are all commercially available highway Bluetooth scanners.  And some of them are remarkably commercial. 
 
     If you go to like traffic casts sites there are pamphlets, buy our Bluetooth scanners and put them on your highway and they're advertising to government departments of transportation.  I looked around for some of the research on this and as research note from the Washington state Department of Transportation. 
 
     And couple of choice clips from that is, the key advantages are the cost of the Bluetooth reader and the Mac address collection device scans multiple lanes, over license plate riders in addition Bluetooth based data time are easy to install, goes on to also talk about users not wishing to disclose their location can simply turn off the broadcast function on their Mac devices. 
 
     We also have the state installing down at the joint base, Lewis-McChord, which is an Army base, a military base south of Seattle installing these sensors in place. So, why would they use Bluetooth of all things?
 
     It turns out there are variety of reasons.  There are a lot of things they can use to monitor traffic, the most basic is the loop, you see them in front of every traffic light. There's a little circle on the ground, and it detects from impedance when your car goes over it, the engine block changes the magnetic field.
 
     We also saw in a presentation by Cesar Cerudo a few days ago, they also use magnetometers.  It's the same idea.  but they only tell you traffic volume. 
 
     They also use radar, which can tell you traffic volume and speed.  But Bluetooth is one better because it provides route choice.  I can be for an intersection, put a Bluetooth scanner there, and when someone drives by it I gather their mac.  I know which way they went since by having other sensors in the intersection.  That is why the DOT likes Bluetooth scanners. 
 
     The only other thing that will give them that are automated license plate readers, which are comparatively more expensive and honestly have even more privacy implications than the Bluetooth scanner does. 
 
     The Bluetooth scanners are less expensive, two to five thousand dollars each at and honestly the manufacturers are making a fortune at those prices.  They are commodity hardware.  They have a cellular modem, solar power with a battery backup, or some of them get power over Ethernet. 
 
     They only get a 3-6% sample rate.  Which on one hand, obviously, not everyone has Bluetooth.  But that honestly seems a little low and we'll get in to why they're not getting most of the sample, is that go by.  Another thing the vendors point out that trucks are going to be over sampled because trucks have lot more -- much higher percentage of trucks have Bluetooth devices in them than the percentage of cars does.  
 
     You have to adjust for that if you're a DOT and tracking people, need to know that if I see X number of cars and my road gets a lot of trucks, I don't really have as many cars as I do if I'm on a road that isn't a trucking route.  They do that adjustment.
 
     Another advantage they point out a lot is fewer privacy concerns. 
 
     So, Bluetooth is a weird protocol.  And it's a weird protocol because as a frequency-hopping spread-spectrum pattern based on the Mac address of devices communicating -- so it's actually pretty hard to sniff traditional Bluetooth one and two.  VTLE is very different and really easy to sniff it. 
 
     You need to know the addresses so the devices communicating.  Bluetooth address is 48 bits like normal Mac address but divided in to parts.  There's a non-significant address part which is manufacturer I.D., the upper address part which is eight bits.  And the lower address part is 24 bits.   You get LA in every single bit of traffic it's easy to get that.  If you want UAP you have to capture a lot of packets and calculate it.   
 
     It's not hard.  But it takes a lot of packets.  And any device can also send an inquiry, a special packet that always comes from a Mac address called the generic inquire access code.  That is 98B3316 no idea why they picked that, that is Mac address that says this isn't really my address but I'm asking, is anyone willing to beacon with me? 
 
     Once you get a response to a beacon you can make a connection attempt.  The connection attempt will give you the device name, the device class, the service list, the clock offset, the rest of the stuff you need to actually form a connection and negotiate encryption and pair with the device.
 
     Turns out the highway scanners don't really care about much of any of that stuff.  All they really want is LAP:  they want an address, a unique I.D. think don't care what data is being sent -- they completely ignore the data.  As a result they can sniff data in a few different ways.  One is inquiry-based tracking.  Which is . . . they set up a scanner to just spam inquiries all the time.
 
     They tell every device, hey, I want to pair with you.  Any device that is in discoverable mode will respond that will give them their -- their LAP. 
 
     Another method connection-based tracking.  This is the scanner, it keeps paging for asynchronous connection link and logical link and adaptation protocol connections. 
 
     This is really good if you already know somebody's Mac, this is the scanner would you use if you want to track company cars around or track individuals through your building that are your employees.  But it's not very useful for general surveillance.   
 
     Finally there is passive sniffing where you just sweep the Bluetooth frequency range, you suck up packets and you don't ever try to respond to any of them.  The problem with passive sniffing it requires non-standard hardware, you can't do it with commodity Bluetooth dongle or your laptop.  That may be a disadvantage for the DOTs.
 
     Here we have couple more slides, this is from University of Washington Star lab.  They are a traffic research area.  And they installed on highway 520's bridge in Seattle, an automated license plate reader as well as couple of Bluetooth scanners to compare the efficacy of the systems. 
 
     We have over here a graph, they monitored the Bluetooth devices and they got certain percentage, Nokia, SG, but we also have Tom-Tom and those are not phones, they are equipment in people's cars.  It's their hands free headsets and that sort of thing.
 
     So, what about those privacy concerns that came up a little earlier that they said are minimized?  Here is an article from "Traffic Technology International", yes, that is actually a magazine. 
 
     I imagine it's not very interesting to most of us but somebody subscribes to "Traffic Technology International" and they talk about -- they have seen -- gains and matches 50% over other methods with patent pending methods which allow for far more robust analysis capability including potentially differentiating transit vehicles. 
 
     They say, we have the capability to make the Mac address data collected anonymous before transmitting from the field which we can do without any reduction in the fidelity of the data.  But isn't it anonymity a major feature of Bluetooth?  Mac addresses are not linked to a user, why the extra process? 
 
     They sound really good here.  If there is even a very small chance that a hacker could sniff the communications pathway from field to host, there should be procedures and protocols in place to minimize the threat.  Okay, so they kind of care about privacy. 
 
     Here we have from a Star Lab paper, and they have an illustration there gathering couple of Macs from sensors, calculating travel time, strip the macs, filter the results.  What they talk about up here is the Macs are kept for unspecified period, typically 60 minutes, that's what they say in their document.  Now this was from the experiment on 520 affordable license reader, that sort of thing.
 
     Most of the commercial sensors I've looked at actually say they only keep the data 20 minutes.  Although it is user serviceable -- because once again they're going after route choice.   If you really wanted to put the sensors 50 miles apart, you could do that then you would need to keep your Mac addresses for a longer period of time to be able to get the route choice down. 
 
     So, it's configurable.  But the Macs are anonymous they throw them away after a short time -- clearly there are no privacy concerns.  [Laughter.]  Or so, that's what they say. 
 
     For instance, we shouldn't care that they're putting these on the Canadian border at all of the border crossings to monitor things.  I bet they have them  on other borders, too.   Canada just happens to be heck of a lot closer to where I live.  This is what I was able to find out.  Again, these are from UW Star Lab.  
 
     There are the three privacy mitigations.  One is they're capturing LAP only, they are not getting your entire Bluetooth address, not cracking your code, they are not pulling your data.   They don't compare that, they  don't make any is attempt to sense that.  
 
     With Bluetooth being frequency hopping spread spectrum, with only passive sniffing they are only getting one packet in 64 anyway without cracking your UAP -- not really cracking, guessing the UAP and pairing with you or making connection attempts they can't follow your communication. 
 
     They can't get most of the packets without doing a lot of stuff that the DOT has no reason to do.  LAP is 24 bits, it is not globally unique.  There are many Bluetooth devices with the same LAP, there are only 16.7 million possible LAPs. 
 
     Next thing, they anonymize it.  Remember that little article in Traffic Technology International, they say that LAP is anonymized while preserving the fidelity of the data.  So, the anonymous LAP matches one to one with a non-anonymous LAP.  They hash it before storing, and if they wanted to they could use salt hash 256.  They can use good hashing practices. 
 
     Then finally their last mitigation is limited retention.  And star lab said, 60 minutes commercial reader, say 20 minutes default time -- that's usually plenty because they will put it before an intersection, after an intersection, so be it.  That is all they need. 
 
     Let's take a look at each of those privacy mitigations.  Remember this?  That little illustration of the manufacturers?  Well, the manufacturers comes from NAP not from LAP so LAP does not permit manufacturer identification.  So clearly at least in their experimental reader deployment they might have a little more than LAP captioned.  
 
     And -- not globally unique, one in 16.7 million is pretty unique for me in Seattle.  There's one of me, there's maybe 2.5 million in the Seattle metro area.  There is only a 1 in 8 chance I match anybody.  I have more than one Bluetooth device.  At that point you've got a pretty unique signature of yourself. 
 
     Now once again they're right that there is no -- there is no central registry of Bluetooth Mac addresses, at least not that we know of.  And you can't necessarily get at somebody's Bluetooth Mac look at DMV database see where they are.
 
     On the other hand what it does mean is the state would be useful for targeting tracking of a person if you know there was a person you can't to track around town you do some research in other ways, you get -- brought a shot of liquor --
 
     [Applause]
 
     Just a moment! 
 
     (Speaking off-mic).
 
     [ laughter ]
 
     All right.  (Speaking off-mic). 
 
     >> Some love for the new speaker!
 
     [Applause]
 
     All right.  Back to tracking people or not tracking them.  So.  All right!
 
     [laughter ]
 
     (Speaking off-mic).
 
     So, yes, one in 16.7 million pretty unique in most areas, there is no central registry.  But if you're already suspecting someone, say you are the FBI or something of that accord -- you can probably subpoena their cell phone provider, and get their INEI and the phone manufacturer knows the serial number that goes with that INEI.  
 
     The phone manufacturer knows the Bluetooth Mac that was put in by default on that phone.  So if you are really tracking one person as a targeted attack,  LAP is good enough.  If you are trying to do dragnet surveillance, LAP is kind of useless. 
 
     So anybody remember this?  This is an interesting story.  It's kind of unrelated but not really.  They talk about anonymizing your LAP.  This is from 2004.  This is the source code for the deck-shuffling algorithm on PartyPoker.com. 
 
     They put this out to show how secure their deck shuffling algorithm is.  On the surface, it looks very fair.  You are taking each card in the entire deck, and you are randomly swapping it with another card.  And you go through the entire deck this way. 
 
     That gives you 52 factorial possible combinations.  Full deck shuffle, 225 bits of entropy.  But wait they're using the random function in Pascal, and random generates a 32-bit number.  So, there is only 32 bits of entropy going in to their 225 bits of entropy.  
 
     They ceded it by calling it randomized.   Randomized, it's the number of milliseconds since midnight, but that is only a 26 bit number.  So really 26 bits of entropy.  So even though they're shuffling the deck perfectly there are  only 68 million possible decks this algorithm can output. 
 
     Somebody made a card shuffling rainbow table where they generated all 68 million possible decks.   They get dealt their own cards say this was the first and second card out of the deck, how many of those 68 million start with these two cards.  The plot comes out, how many have those halls cards 9, 10, 11, then they are down to one deck and predict the rest of the deck. 
 
     So, the moral of the story is, you cannot anonymize a 24-bit number.  You can't take a 24 bit number and turn it into 256 bit salted hash.  Someone can try all those 24 bit number numbers.  They'll hit it.  It's trivial to force a brute number that size on modern computing hardware. 
 
     So that leaves us with one last bit of protection.  That is, well, they throw the data away, they only keep it for 20 minutes.  The DOT collects it, they collect the data, to see route choice, speed, and traffic volume.  They don't care who you are, they're not trying to track you.  And then they get rid of the data.   They're not sharing it with intelligence agencies and public institutions and so on.  They really have no reason to, they don't want this other data.
 
     So anybody remember this?
 
     This is Edward Snowden's slide, you'll note the smiley face by SSL added in here of the muscular project where in the data is encrypted to Google's front end but then moving from datacenter to datacenter it's in clear text, and the NSA just tapped their lines. 
 
     And we have the same thing.  The DOT may be throwing your data away after twenty minutes.   is everybody throwing your data away after 20 minutes?
 
     We can't really know if this data is stored with or without the cooperation of the DOT.  Once again, it is mitigation, I'm glad they're throwing the data away after 20 minutes, it's nice of them.  But all of these are a bit limited in terms of how well they actually protect your privacy.  It is creating a nearly nationwide tracking system.
 
     Now I will give them one thing, the alternative to this is usually automated license plate readers, and those are much worse.  They get way better than three to six percent car identification.  And your license plate does map one to one to you and it clearly available database that any police agency can access.  So if the choice is Bluetooth scanners or putting ALPRs everywhere?
 
     Okay, yeah, they're right.  There's no privacy concerns at least relatively speaking.  On the other hand ALPRs cost five times as much.  Thus, they are less inclined to put them everywhere.  Bluetooth scanners are pretty cheap.  They're easy for them to deploy, so they're quite widely deployed.
 
     So this is what I could find out from reading literature but it turns out you can't just Google, "where are the Bluetooth scanners in my city?"  So that data is not really made public.  So I thought, well, why don't I make a Bluetooth detector detector?  
 
     And so I went on to making my own.  And with Bluetooth scanning, first you have to get some equipment.  Bluetooth transceivers, the typical dongle that you can buy anywhere can send and receive, but can only send beacons or send when they're paired.  They don't have basically packet like you call on Wi-Fi cards.  Class one 100 meter range don't see a lot of those. 
 
     Class two and three are ten and one meter.  Also commercial Bluetooth sniffers.  These things are $10,000 plus.  They will grab all channels, they will receive one, they don't transmit.  They are still single or dual or sweep, they won't grab all 64 channels they just swap between them.  Until you tell them, "I am interested in this Bluetooth device" -- then they will lock on and frequency hop with it.
 
    
     But I didn't want to spend $10,000 own commercial Bluetooth sniffer.  Luckily there is this lovely thing that you can buy these down in the vendor area.  This is the uber tooth one it's a non-commercial Bluetooth scanner. 
 
     It has all the capabilities I or Department of Transportation would need to sniff up at least Bluetooth Macs.  2.4 gigahertz, transmit and receive, transmit power and receive sensitivity comparable to class one Bluetooth, those things have a 100 meter range.  Comes with a nice 9DVI antenna on it.
 
     All I needed was a bit of hardware to attach it to.  I have to use Linux, there are no Windows ubertooth drivers.  You could use a Linux VM, the problem is Windows will not pass USB device with no driver to the VM, so you have to get a driver called WinUSB, which is just a generic Windows USB support.   You can associate that driver with the uber tooth then pass that in to your VM and it works. 
 
     So, my equipment for this at first was old ThinkPad in the garage.  Alternatively a copy of Ubuntu, an uber tooth one, a global sat USB-GPS dongle for $27 on Amazon, and an AZIO which is one of those Chinese brands that doesn't actually exist -- they just slap a random name on products, a USB micro Bluetooth adapter, also class one, for $16. 
 
     And so I set up my Linux PC, update it, install with Lib USB various USB drivers required, blue Z which is a really nice Linux Bluetooth sat.  Download the Pi-USB, the Bluetooth baseband, the uber tooth software, and finally Kismet although you could install binary Kismet.  You wouldn't necessarily build it all yourself but will have to build the Kismet plug in that associates with uber tooth, so you might as well download the source, you need it anyway. 
 
     Install all that.  This is older version of Kismet, it is 2013.  The latest released version of kismet is a year and half old.  There are newer ones available on get hub but for stability you're better off with an old one.  Kismet is meant as Wi-Fi scanner -- it will work as Bluetooth scanner but pushing it out of its element.  Anything that stabilizes it is helpful. 
 
     And, okay, now I have a computer that can sniff Bluetooth.  That was all right.  But I didn't really want to drive around with computer on my dashboard all over the city for hours until the battery ran out and have to go back and swap another one. 
 
     So I thought, you know what would cooler if I had this on an embedded system that I can just stick on the dashboard and plug in to the cigarette lighter and do it all that way.  So, I built an arm-based Bluetooth scanner.  Let's show you a bit of that. 
 
     It was an inexpensive open source hardware platform, raspberry pie, made for education purposes which basically shows you here, this is how you play with little embedded systems.  It's an arm processor, it's 35 bucks, probably buy them in the vendor room, too.  And got two USB, HDMI, audio, GPI with SDI capability all sorts of things I don't need for a Bluetooth scanner. 
 
     I also went ahead and bought a screen and enclosure for it I didn't want to drive all over town for five hours, get home, and found I captured no data.   I wanted to have a readout.  It's optional.  I wouldn't have needed it, it works just fine without it. 
 
     And then the equipment from the PC build and -- finally I needed something to power it off of.  It runs on a five volt, 500 milliamp USB power supply.  It is meant to plug in to any USB adapter, a car charger has USB adapter now I can plug it in to my cigarette lighter.
 
     Let me show you what I built here.  The problem I have is I cannot see my own screen.  So I am going to show you with my camera here what is built but you will have to tell me if I am not actually aiming at it.   Here is -- is that in focus?
 
     Okay.  Here is the raspberry pie with display on it, those are a bunch of Bluetooth Mac addresses and number of packets it is captured from.  I turned this on in speaker room about 45 minutes ago and as you can see there's a nice long list of Bluetooth Macs that I have captured from friendly DEF CON goers.  Over here is what it is plugged in to, we've got -- is that in focus there?
 
     We've got USB hub, which has on it my GPS dongle which is getting no reception here in the Rio but in theory it could -- and my uber tooth one.   Then finally we have what's powering all of this.  This is a $29 gorilla gadget 16,800 milliamp cell phone re-charger that also worked as USB counter source.  Those altogether give me a less than $200 embedded system for use as a Bluetooth scanner.
 
     All right.  Am I back to slides?
 
     Setting this up was pretty straight forward.  Update the firm ware, I used the standard raspbiean image.  There is a standard image there's actually available that already has support for the screen if you are using the screen then you can use that as well.  And it recompiles, a bunch of kernel packets are required for raspberry pie, because repurposes the general purpose IO pins as a high speed bus to transmit and receive from the screen. 
 
     Installed the same Bluetooth -- same packages as before, although a few others are necessary.  Actually I don't list it there you also need build essential, Raspian does not by default include some of the tool change packages you need to build this.  But Apt is pretty friendly about telling you what you're missing.  Download usual software, make an install.
 
     One thing is, the raspberry pie is not the fastest DEF platform out there.  Compiling kismet on the pie takes about four and half hours.   As a result, you're going to be doing a lot of experimenting with this, it's probably worth setting up a Linux box to cross compile going to be a hell of a lot faster.  But if you're only compiling kismet once on the device it's not that big a deal to just let it compile for four and a half hours. 
 
     Then I did a little more set up.  Putting my user in a plug DEF group setting up USB to automatically associate the uber tooth with that, so that I can run kismet in user mode instead of having to run it as a root.
 
     I added a new user called scanner, and that user is in the appropriate groups.  I modified a tab to instead of display log in prompt on TTI one, the console, to automatically log in the scanner user.  That way, when I boot up the pie, it  automatically displays the scanner user's console on the screen I don't have to have plug a keyboard in to it and do any kind of log in.  Then set GPSD speed to start up.
 
     This is actually necessary because GPSD on Raspian - there seems to a bug in install packages.  It will not auto start if you do a package re-configure to tell it to auto start, it writes a bad GPSD config that doesn't actually work. 
 
     So, I added a GPSD config to make it work and then finally start up kismet on a computer where you have a keyboard and a screen because you have to set up the kismet UI the way you like it to look then exit, that will save all your UI settings to display the uber tooth plug in, and not display the AI211, all the stuff we're not using, display GPS coordinates that sort of thing. 
 
     Then finally modify the scanner user's batch RC to start up kismet as soon as they log in.  The screen we saw on the little scanner a minute ago, that's what it boots to.  I just plug in power it immediately starts running. 
 
     It worked great to just take it in to my car with car charger drive around town with it and record logs.  When I got home the pie has Ethernet adapter, so I plug it in to a network and SSH in to it, pull off all the log files.  And I pulled off quite a lot of log files from it.
 
     So there were a few issues with raspberry pie.   I got that USB hub, even though I have two devices plugged into it and the pie has two USB ports.  Problem is the pie's USB source only supply 140 milliamps, and that's not really enough to drive uber tooth and Bluetooth transceiver and a GPS.  I needed external power.  I grabbed a powered USB hub. 
 
     Other problem I had with that is powered USB has to plug in to something.  And USB hub normally have a wall wart.  I took the wall wart, took cut that cord, soldered the power cords in the wall cord to the power pins on the USB cord and then just plug it in to the same car charger as the pie.  So I've got a custom made power cord for the thing. 
 
     Only other issue I ran into is I cannot solder worth a damn.  I found this out the hard way when putting this together and made plenty of mistakes with I think that was my second power cable and had to do a lot of desolderring to get the screen soldered on.  But as a result I can solder now.  That was an added benefit of this project.  [Laughter.]  Even if it took a few extra hours.
 
     Finally kismet on -- uber tooth and kismet on the pie sometimes crashes with this corrupted double link list error.  Usually happens right at start up if it does crash it's fine, you just run kismet again, usually doesn't crash the second time.  If it doesn't crash in the first two minutes it usually doesn't. 
 
     I actually wrote a script for that kismet's client and server are started separately and if the server goes down just cycles it and starts up again and the client reconnects to the server so that, once again, you don't have to have a keyboard, don't have to have SSHN,  The device just runs autonomously and it recovers from its own faults.
 
     I also have been working with people on Get Hub to try to figure out what exactly this plug is.  It doesn't just happen on Raspian it happens on Cali also, and that's a platform they would like uber tooth to work properly on.  Cali based on Ubuntu, and it works great on 1204 and 1404.  And it doesn't work on Cali, and we don't seem to have figured out why.  
 
     Thanks to Dominick for his help in debugging this, even if we have not quite figured how to get it 100% reliable yet.  But fault tolerance script works.  I was still able to gather data. 
 
     You scan with uber tooth scan which performs an inquiry scan, it sends out beacons.  That needs both an uber tooth one and a Bluetooth transceiver. 
 
     That will tell us the LAP only, nothing else, or we can use kismet which will passively monitor all frequencies, it takes only the uber tooth one and it logs GPS coordinates constantly as well as logging our data packets.  So, that's what I used for most of my data gathering because I need coordinates.  I need to know exactly where I observed all these Bluetooth addresses. 
 
     It's a continuous sweep, it will miss things because it is only getting one packet in 64 from each connection.  And, if it gets enough packets to guess UAP it will do so.  I have UAP on some of the addresses I captured not others.
 
     Um, the amount of time in inquiry scan it needs to be sure it got everybody is 10.24 seconds.  So if I'm going at highway speeds about 60 miles an hour, that means 268.2 meters of driving in order to be sure I caught everything around.  A class 1 transceiver, 300A, is 100 meters.  it should be mostly enough to get at least the vast majority of the devices.  But I have to accept that I'm not going to get everything unless I drive by over and over and over again.
 
     So, then we get to the results.  First of all, after I got all those logs I loaded them in to wire shark in order to parse the kismet logs, and basically dump everything but the Mac address.  I don't care about the data, I don't need the contents of the packets, all I really want is the Bluetooth addresses. 
 
     So dumped all that to a ridiculously massive CSV, was very happy to have excel 2013 because the 32-bit versions of excel would have choked on my 16 gigabyte spread sheet.  [Laughter.] 
 
     The 64 bit version was not delighted by it, either,  but it was able to work with it.  And here we have whole bunch of packets from, you will notice, 98B3316.  The generic inquiry access code.  These are beacons that were picked up. 
 
     Then I mapped them all out on Google maps.  These are areas on the Seattle highways that are showing recurrent inquiry activity.  These are -- I found an emitter of Bluetooth inquiries on every pass of these locations, implying that there is a stationary Bluetooth source. 
 
     Now, yes, it could be somebody semi pulled off the side of the road for five hours.  I can't rule out the possibility that, these are not scanners these are -- happens to be stationary Bluetooth sources that are trying to pair all the time.  It seems maybe a little unlikely, but it is circumstantial evidence. 
 
     The other thing is . . . These locations map expected stops for route source tracking.   If you look at where they are -- on a ramp to a highway over in Redmond, we've got place before the highways diverge on the north side of Seattle, likewise we've got a couple of places on south side of Seattle just before major intersections of high traffic.  Got couple downtown between I-5 20 and I-90 which are the main thoroughfares across the grid.  They are places I would expect the DOT to want to put scanners. 
 
     Combined with that, we got this.  That said, there are not as many as I would expect.  I probably missed a fair number of them.  I also did not spend all week driving around Seattle.  I can probably gather more if I spent more time gathering data.  Well, that tells me with inquiry scans, but what if they're not doing inquiry scans?   What if they're doing other types of Bluetooth scans? 
 
     I loaded in the data of all the Mac addresses not just the inquiries and looked for -- what's the first time I spotted this? What's the last time I spotted this?  How far apart are they in hours and if they were more than half hour apart, then -- in the same location, that is stationary source. 
 
     I looked all the ones I spotted more than an hour apart from themselves, then calculated the haversine distance between those locations.  Haversine distance is the distance across the surface of a sphere -- it is the way you calculate distance if you have GPS coordinates. 
 
     I found a variety of them that had very small haversine distance and very large time difference, once again  implying a stationary Bluetooth emitter.  They tended to look like this.  We had multiple areas where an address was found in less than a 200 meter area on multiple passes around the highways. 
 
     I'd show you a map of these but honestly it looks whole lot like the other map did.  They were for the most part a subset of the inquiry stand locations.  I saw them at the same places. 
 
     What this means, I am not sure.   They could be using multiple transceivers, they could be false positives.   It's a little difficult to know what to make of that data.  Notably absent, though, there weren't any on state road 520 bridge which surprises me.  
 
     We saw on the Star Labs experiments, that's where they were testing them originally -- in addition the 520 bridge has dynamic speed limit signs.  They are definitely calculating travel times for cars and calculating speed.  They got some sort of traffic monitoring on there.  And they've  got Bluetooth scanners so I would think those things would be connected.  But despite quite a few passes, I did not find evidence that that is the case.
 
     This said, unlike when they were doing the experiment, the 520 bridge is a toll bridge now.  That means people have toll passes, so they may have just switched to using electronic tolling sensors and abandoned using Bluetooth sensors on that bridge now that they have got a potentially more reliable and more uniquely identifiable way of tracking.
 
     On the other hand that won't give them route choice, tell them people are crossing the bridge, won't tell them where they're going afterwards, unless they have put hidden toll sensors elsewhere that don't charge you a toll.   That may get in to paranoia territory but that's what DEFCON is for.  [Laughter.] 
 
     So.  Counter measures.  so what do we do about this or do we need to do anything about it?
 
     Well first of all there is going back to recognizing that if they weren't doing this, they would probably put license plate readers everywhere and that would be worse.  Nevertheless, the main thing you can do is of course turn off your phone. 
 
     Unfortunately a little harder to turn off the Bluetooth transceivers that are built in your car.  Depending on the car, sometimes they don't have an off.  They may transmit to anything that transmits to them.  Some of them basically beacon continuously.
 
     They are pretty easy to detect.  If you want to know you just build one of these things and you sniff your own car see what you got.  You can check your own Bluetooth emanations.  I know I found that my car does not beacon continuously but if it's powered on or if it has been powered on in the last ten minutes it is sending Bluetooth packets.  
 
     Now I have -- I have devices its paired to relatively near it  -- I'm not making hands-free call, I'm not playing Bluetooth radio, the ignition is turned off, I'm not in the car and it's still exchanging Bluetooth data.  These devices are relatively leaky from an information perspective and there is not a whole lot you can do about that.  This said, this kind of leaking requires passive scanning, not the inquiry scans which are probably what most DOTs are using.
 
     If I look at commercial products that's mostly what they're doing.  You read between the lines of what the capabilities are they talk about only finding discoverable devices.  Inquiry scans only find discoverable devices, passive scans will find all devices.  Well, all devices that are not turned off.   
 
     The other thing that you can do, you can be someone else.  I can run my sniffer look at all those nice LAPs I got.  And if I know who one of them belongs to I can just -- this sniffer works just as well as a spoofer. 
 
     As a spoofer, I can plug in a couple of Bluetooth dongles and then with blue smash tools which are included in backtrack and Cali, open source security tools, just change my Bluetooth adapters to spoof other Bluetooth Macs of my choice.  Then I pair them off with each other so they will start leaking data everywhere and drive around and now I can be someone else.  If this is being used as a surveillance system, if they are tracking people this way, I can lay a false trail. 
 
     With my one device I can lay a false trail of as many devices as I want.  I know somebody has a car has five Bluetooth devices in it, that's fine, I've got a hub so I can plug in multiple transceivers and leak all the data I want.   You can duplicate multiple addresses with multiple transceivers. 
 
     So that's where my current state was.  I do have a little bit of follow-up ideas for what I'm going to do with it next.  One is now that I've got these stationary locations, I'm going to go to them and try to pair with them.  If I make a connection attempt and they are a commodity Bluetooth hardware they should give me their manufacturer and their service class and all the other data necessary. 
 
     I don't need to connect to them, but I'm curious.  Because once again if they all have the same manufacturer, that's another piece of evidence that, yes, these are probably scanners and not just some truck parked by the side of the highway.  So, that is my current state.  We have any questions?
 
     Yes.
 
     >> You talked about how -- 
 
     >> The question was, any way to know that they're actually only collecting 3-6% and not capturing the Dragnet?
 
     Truth is they're trying to capture a dragnet, but that's part of the evidence that they're doing inquiry scans.  If you're doing inquiry scans you only get discoverable devices and most are not discoverable.  Also because of the frequency hopping spectrum you're only getting one packet in 64.  That's where that 3-6% comes from.  Not that they're trying to do sampling or trying to protect privacy, it's that the scanning methodology they use loses a lot of packets. 
 
     And because the DOT just doing statistical analysis they don't care.  They don't have any incentive to capture more packets or to make the system better.   That's good enough for them.  So really the only evidence we have is the kind of - assume that DOT have fixed budgets not going to spend money on stuff that doesn't actually improve their mission.  Unless the NSA wants to pay for it, the NSA probably has to take what they can get from them.  Yes?
 
     The tool built into Cali and Backtrack?  Let's see.  There is uber tooth tools in kismet but you may be thinking of blue smash tools which include a command line.  Bluetooth Mac changer.  That said, you don't even necessarily need that.   The blue Z library that is the key Bluetooth library of Linux will allow you to specify Mac addresses to your devices.  I think may able to do with it HDI tool, I'm not certain about that. 
 
     On Linux Bluetooth Macs are user programmable.  You can set -- it's actually kind of nice because the blue Z stack was basically Linux's Bluetooth support was written open source from the start so a lot of the great stuff that we had to clone drivers and Wi-Fi world can manage to get to work was built in there from the ground up on Bluetooth.  It's been quite convenient for people like me.  Anything else?
 
     How the scanners communicate with each other?
 
     I've not looked in to that.  Like I said they said either Ethernet or cell modem is the way all of the manufacturers I looked at advertise communication.  If it's cell modem, you can use software radio and try to interpret that -- probably two G cell modem, they don't need much bandwidth at all.  If it's Ethernet it's obviously a little harder.  Question over there?
 
     The question was, is there some mechanism like acknowledgment frames in Bluetooth where you can stimulate a response on somebody else.  Yes, there is.  In fact the uber tooth scan tool does basically that.  It spews out a bunch of packets to get responses from things. 
 
     The main thing, though, is beaconing.  If the device is discoverable that's what the GISD address packets do. You send them out and they're basically screaming, does anybody want to pair with me and any device that's discoverable will respond, yes, this is my address.  And they can allow initiate a connection.  All right.  One more?
 
     Question was classic Bluetooth not BLE?
 
     Yes, it is.  Because those devices in cars all headsets those are Bluetooth 1.0 and 2.0, they aren't BLE devices, they're not Bluetooth smart.  Bluetooth smart is hell of a lot easier to sniff than classic Bluetooth is.  But in this case that is not what they're using because the particular devices they want to track, that's not what they're using. 
 
     All right.  I've got the link to where I've got copy of my slides up on my blog.  I will update those to the current copy of the slides today.  And I will also within next week be posting this talk in more white paper oriented format on permitergrid.com.  All right.  Thanks.
 
     [Applause]