00:00:00.067-->00:00:05.506 >>So uh we're here today to talk about a mechanism that identifies the type of device 00:00:05.506-->00:00:09.376 connecting to a wifi network. Uh, it can be quite specific. You can tell the difference 00:00:09.376-->00:00:16.216 between an iPhone 5S and an iPhone 5, between a Samsung Galaxy S7 and an S8, uh between 00:00:16.216-->00:00:22.189 a withings scale and a nest thermostat. Classically this kind of client detection would 00:00:22.189-->00:00:27.427 be called fingerprinting, like the OS fingerprinting mechanisms and end map. Uh, however in it's 00:00:27.427-->00:00:32.399 current usage the term fingerprinting has evolved to mean identification of specific 00:00:32.399-->00:00:37.437 users, like browser fingerprinting. Um, and well the word fingerprint kind of refers 00:00:37.437-->00:00:42.976 to an individual's fingers, as the mechanism discussed here identifies the species of the 00:00:42.976-->00:00:49.283 device and not the individual user, we refer to it as wifi taxonomy, it identifies the 00:00:49.283-->00:00:54.087 species. We'll get a chance to try it in the last few minutes um during time for questions. 00:01:11.204-->00:01:13.507 [sound cuts out as speaker continues] TCP IP packets, they're not routable they don't 00:01:13.507-->00:01:19.947 leave the wifi network. We'll focus on 2 specific types of frames, the probe request is 00:01:19.947-->00:01:24.952 where the wifi client can ask for all nearby AP's or one specific AP to respond. The 00:01:27.020-->00:01:30.791 client includes information about itself and it's capabilities in the request and 00:01:30.791-->00:01:35.128 the AP can respond with it's one capabilities in the response. We'll also look at the 00:01:35.128-->00:01:40.033 association request which is where a a client joins a wifi network. The client includes 00:01:40.033-->00:01:45.706 many of the same capabilities as were in its probe request plus a few more. There were a bunch 00:01:45.706-->00:01:51.545 more MLME frames like authentication or action frames to modify various parameters 00:01:51.545-->00:01:56.116 but, for the taxonomy mechanism were talking about today we'll just rely on these 2. 00:01:56.116-->00:01:58.185 Information elements are type length value tuples packed one after another in the management 00:01:58.185-->00:02:00.120 frame. They're all optional though in practice, a few are universal because wifi can't 00:02:00.120-->00:02:02.122 work without them. Each wifi standard has added more types of information elements. Um, in the 00:02:02.122-->00:02:07.127 date 802.11 B days there were very few. .11 G added a few more. .11N and L, AC added a 00:02:21.475-->00:02:26.480 bunch more and so on. And in addition to the standard elements there's a mechanism for 00:02:30.651-->00:02:37.557 vendors to define their own. Vendor extensions are type 221 uh, with the uh an IED for the 00:02:37.557-->00:02:41.995 vendor called the organizationally unique identifier or OUI and then 00:02:41.995-->00:02:46.767 followed by a sub type so that the vendor can define multiple of their own types. Because the 00:02:46.767-->00:02:52.439 length field provides enough information to skip over the IE any wifi client device can 00:02:52.439-->00:02:56.143 interoperate whether it understands that vendor extension or not, it just skips 00:02:56.143-->00:03:01.782 over the ones that it doesn't implement. This is the association frame from an iPhone 00:03:01.782-->00:03:07.320 7 Plus as broken out by Wireshark. The association request includes the SSID that 00:03:07.320-->00:03:11.925 the client wants to join, information about it, supported rates and channels, uh about 00:03:11.925-->00:03:16.763 it's power levels and it's radio management capabilities, plus three vendor extensions from 00:03:16.763-->00:03:22.669 Microsoft, Broadcom, and Apple. A few of the vendor extensions are very widespread. Uh, the the 00:03:22.669-->00:03:26.673 Microsoft extension shown here is for prioritization and it's widely implemented even on 00:03:26.673-->00:03:31.812 devices that are not running any kind of Windows OS. The Broadcom extension is also quite uh 00:03:31.812-->00:03:37.084 widespread owing to the how calm and broadcom chipsets are. The Apple extension shown here was 00:03:37.084-->00:03:42.923 added in IOS 10.2. We don't really know what it is, but it was added on all devices running 00:03:42.923-->00:03:47.928 that version or later. The signature lists the tag numbers of the IE"s that are present in 00:03:50.897-->00:03:57.237 the frame in the order that they appear as a text string of decimal numbers. For vendor 00:03:57.237-->00:04:02.542 extensions it additionally includes the OUI of the vendor and that vendors sub type. Uh 00:04:02.542-->00:04:09.116 for the this part of the signature we ended up with the text shown in red on this slide. 00:04:09.116-->00:04:13.186 This part of the signature is most strongly influenced by the OS of the client device where 00:04:13.186-->00:04:17.424 the client wifi stack is implemented. It's next most strongly uh influenced by the 00:04:17.424-->00:04:22.496 wifi chip set. Both in terms of the standards it supports and on any vendor extensions that that 00:04:22.496-->00:04:28.702 vendor implements in their driver. In addition to the tag numbers, a few of the 00:04:28.702-->00:04:34.608 information elements contain capability bit masks or other information which is useful in 00:04:34.608-->00:04:39.613 identifying the device. Uh, for example 802.11 uh uh 11N define 16 bits of optional capabilities 00:04:41.915-->00:04:48.155 and .11AC defines 32 bits more. This is most strongly influenced by the chip set and the subset 00:04:48.155-->00:04:53.226 of the standard that's implemented by that A sick. The transmit power information 00:04:53.226-->00:04:59.065 element depends strongly on the board design and how the antennas are laid out. Uh 2 00:04:59.065-->00:05:03.303 devices built by the same manufacturer using the same software, or even using the same 00:05:03.303-->00:05:08.308 wifi chip set will often have different TX power values because their board layouts are 00:05:08.308-->00:05:13.547 different. The number of antennas that are present is encoded in both the .11N and the 00:05:13.547-->00:05:19.319 .11AC capabilities and it's also indicative of the board design and there's an extended 00:05:19.319-->00:05:23.256 capabilities bit mask which contains even more optional elements. It's most strongly 00:05:23.256-->00:05:28.461 influenced by the driver and the WPA supplicants software. A number of the capability bit 00:05:28.461-->00:05:32.299 masks are pended in the signature to further differentiate it also shown in 00:05:32.299-->00:05:37.304 red on this slide. Looking at the signature as we've discussed it so far, it has become more 00:05:41.007-->00:05:46.746 complex over time. Uh, this shows the association request portion of the signature for 3 00:05:46.746-->00:05:53.119 devices. The first is from an original iPhone which is a .11G device. The this taxonomy 00:05:53.119-->00:05:55.956 mechanism wouldn't have worked very well in that time frame. There was very little 00:05:55.956-->00:06:00.894 differentiation between devices. iPhone 4S is a .11N device introduced about 4 years later 00:06:03.630-->00:06:09.703 and it added a number of options to its management frames. iPhone 7 is from about 5 years after 00:06:09.703-->00:06:14.708 that and it's a .11AC device and it added even more. The full signature contains the list of 00:06:19.646-->00:06:24.818 IE's and the various bit masks from each of the probe request and the association request 00:06:24.818-->00:06:30.190 separated by a pipe. The whole thing is prefaced by wifi 4 because this is the 4th 00:06:30.190-->00:06:35.061 iteration of the signature format. Uh, prepending that string allowed the wifi 1, 2, 00:06:35.061-->00:06:39.866 and 3 signatures to remain in the database while we were working on updating everything. 00:06:39.866-->00:06:45.572 We shall speak no more of the earlier formats. Uh when you include all of this into the 00:06:45.572-->00:06:50.577 signature, it ends up being quite distinctive and it allows us to identify what the device 00:06:52.579-->00:06:57.584 is. The taxonomy signature is influenced by the client OS, by it's wifi chip set, by its board 00:07:02.022-->00:07:06.893 layout. Uh the current database of signatures identifies the most common wifi devices which 00:07:06.893-->00:07:12.465 are overwhelmingly phones nowadays. We have signatures from most widely sold phones of 00:07:12.465-->00:07:16.636 and tablet devices over the last few years and a selection of other types of devices. uh like 00:07:16.636-->00:07:22.676 media streaming devices from Google, Apple, Roku, Amazon and so forth. Uh and internet of 00:07:22.676-->00:07:29.282 things devices from Nest, and Honeywell, and We things and and so on. For larger devices like 00:07:29.282-->00:07:34.287 laptops and desktops which use a separate wifi card, this mechanism identifies there card. 00:07:36.389-->00:07:42.896 Um we had signatures for some laptops and desktop devices in the database but it was kind of 00:07:42.896-->00:07:49.202 ridiculous. Uh, there was one model of Apple's Airport Extreme Card which could be a Macbook or 00:07:49.202-->00:07:55.709 an iMac or a Mac Pro basically any machine of that generation uh we couldn't tell em apart 00:07:55.709-->00:08:00.814 using this mechanism. Uh Intel Centrino chips as it's used in Windows lap laptops are even 00:08:00.814-->00:08:05.985 less distinctive, it could be basically anything. So at this point we don't even try. Uh We 00:08:05.985-->00:08:10.523 don't add signatures from laptops or desktops into the database it just tends to uh 00:08:10.523-->00:08:15.862 result in confusion and isn't very useful. Additionally there are a few classes of device 00:08:15.862-->00:08:21.167 which we choose not to gather signatures for. Um, first we only want to focus on common 00:08:21.167-->00:08:26.172 devices. Devices that uh lots of people are likely to have and we used lists of top selling 00:08:26.172-->00:08:30.410 consumer electronics over the last few years to target devices that we want to gather 00:08:30.410-->00:08:36.316 signatures for. Um if it's something that isn't very common or is is unique we don't wanna 00:08:36.316-->00:08:42.322 really want to put it in the database. Uh The other set of things we don't add to the 00:08:42.322-->00:08:47.560 debate database is things that would make people uncomfortable if they saw it in the list of 00:08:47.560-->00:08:52.866 devices on their router. Uh That includes uh various medical devices, devices of an adult 00:08:52.866-->00:08:54.868 nature, uh home incarceration monitoring devices and so forth. Many devices have been seen to 00:08:54.868-->00:08:59.873 emit more than one signature and so there's more than one entry for them in the database. For 00:09:13.353-->00:09:18.758 devices which support both 2.4 and 5 gigahertz operation, the signatures are almost always 00:09:18.758-->00:09:22.562 distinct. Uh there are information elements that are only defined for one band or the 00:09:22.562-->00:09:27.667 other, and the whole of .11AC is only defined for 5 gigahertz operation. So if the device 00:09:27.667-->00:09:33.306 supports both bands, we gather signatures from each of the 2 bands. Uh however, even in the 00:09:33.306-->00:09:39.345 same band devices often have multiple signatures. They vary what they advertise based on the 00:09:39.345-->00:09:45.318 local conditions like noise. Uh this example shows 2 signatures from a Google Pixel phone. It 00:09:45.318-->00:09:50.323 varies it's handling of beam forming presumably based on the noise environment that it sees. 00:09:54.060-->00:09:59.032 Clients can also behave differently depending on what they see from the AP in response 00:09:59.032-->00:10:03.803 to their probe request. For example, uh if the AP says that it supports radio resource 00:10:03.803-->00:10:08.808 management, most Apple and and some Android devices will include some spectrum management 00:10:08.808-->00:10:15.315 IE in their association request. That's IE number 70 highlighted in red in that list. Another 00:10:15.315-->00:10:20.487 example is that although .11AC is only really defined for 5 gigahertz operation, many 00:10:20.487-->00:10:24.657 vendors have a proprietary extension to it which makes it operate on 2.4 gigahertz and we 00:10:24.657-->00:10:30.763 will see the .11AC fields in their probe request. They typically only then include it 00:10:30.763-->00:10:36.336 in the association if they see the magic proprietary handshake back from the AP and so it won't 00:10:36.336-->00:10:41.608 be in the associate. So when capturing signatures for the database we use 3 different AP's 00:10:41.608-->00:10:46.613 to maximize the chance of capturing different signatures. Sometimes we see the same 00:10:49.249-->00:10:54.954 signature from multiple devices. Um, these examples are all devices using the Broadcom 43, 00:10:54.954-->00:11:01.594 362 chipset running linux using the same driver, same wifi uh supplicant, same WPA supplicant 00:11:01.594-->00:11:07.400 and they're all old enough that they don't have a transmit power information element. Uh, the 00:11:07.400-->00:11:11.938 signatures are identical. They're an Amazon Dash button, a First Alert Thermostat, a nexus 00:11:11.938-->00:11:16.943 7 from 2012, Roku HD and a Withings scale. In most cases like this we distinguish them 00:11:19.646-->00:11:24.017 using the upper 24 bits of the Mac Address which is uh an organizationally unique 00:11:24.017-->00:11:29.289 identifier. OUI's are assigned to the manufacturer and adding the OUI as a qualifier can 00:11:29.289-->00:11:34.928 distinguish similar devices from different manufacturers which have the same signature. We 00:11:34.928-->00:11:41.000 sometimes also use information from DHCP. The options present in a DHCP request can identify 00:11:41.000-->00:11:46.172 the OS. This was originally developed by the finger bank project and that whole mechanism 00:11:46.172-->00:11:51.744 inspired this mechanism for wifi. However using DHCP gets us further and further from the 00:11:51.744-->00:11:57.317 wifi layer and so we try to be more sparing in using it. In particular only the access point 00:11:57.317-->00:12:03.423 will be able to see the DHCP request unencrypted. uh other devices like Sniffer devices 00:12:03.423-->00:12:10.096 that might want to use this mechanism would not be able to rely on DHCP. However there 00:12:10.096-->00:12:14.567 remain a few cases which are still troublesome. Uh mainly made by the same vendor using 00:12:14.567-->00:12:19.606 the same software, the same chipset, and at about the same time. Often the transmit power 00:12:19.606-->00:12:23.243 information will distinguish them due to the different board designs but not always. Uh for 00:12:23.243-->00:12:28.248 example iPad Air second generation and iPhone 6S have the same signature. Uh, we can 00:12:30.617-->00:12:36.789 try to use heuristics like if the DHCP hostname contains the string iPad, it's probably an 00:12:36.789-->00:12:41.761 iPad, um but if nothing else we we return to all of the possibilities that it's one of 00:12:41.761-->00:12:46.766 these. This mechanism was originally developed as part of a wifi EP project. Uh We 00:12:49.469-->00:12:54.641 intended to focus on identifying the wifi chip set the client was using. We thought that if we 00:12:54.641-->00:13:00.580 could just know what that chip set is, then we'd be able to implement all kinds of very 00:13:00.580-->00:13:05.585 clever bug work rounds and we would make wifi perfect. Um, as it turns out if bugs can be 00:13:09.188-->00:13:13.192 worked around easily, they mostly work around them in the client software. Who knew? Um, 00:13:13.192-->00:13:19.432 instead where thee, this kind of information is currently used is in the UI of the router. Uh 00:13:19.432-->00:13:23.269 where there's a list of connected clients. If the client it it we can get an indication 00:13:23.269-->00:13:28.941 of what the client is. If the client included a useful host name in its DHCP request then 00:13:28.941-->00:13:35.114 that's great. If it didn't or if it includes something like it's serial number as it's name, then 00:13:35.114-->00:13:41.487 it's much more helpful to say what we think it is uh to help the the user identify it. We 00:13:41.487-->00:13:45.625 also use it to correlate with other performance information to break it out by the kind of 00:13:45.625-->00:13:51.497 client device. My colleague Avery Pennarun gave a talk at Net Dev 1.1 um, on this this 00:13:51.497-->00:13:57.170 topic. The graph on this page is from that talk and it shows wifi throughput getting better and 00:13:57.170-->00:14:03.876 better and the client get's closer to the AP until it gets really close and then it starts 00:14:03.876-->00:14:10.850 dropping again. That's unusual. Most devices don't do that and you only can see that this is 00:14:10.850-->00:14:14.620 happening if you break it out by the type of device and see that some of them do some weird 00:14:14.620-->00:14:19.625 things. In the future we may use the mechanism for more. Um, we might use it for optimizations 00:14:21.994-->00:14:27.767 based on the type of client device. In particular, if we can know how well it handles packet 00:14:27.767-->00:14:34.407 reordering, we could use that to get lower latency on average by allowing the occasional packet 00:14:34.407-->00:14:39.645 to arrive out of order rather than buffer all of them to keep them all in order. Um, also 00:14:39.645-->00:14:43.716 wireless intrusion detection systems might be able to use in information like this if they 00:14:43.716-->00:14:47.386 think they know what kind of device this is then they know what sorts of network activities 00:14:47.386-->00:14:52.391 would be reasonable from that device. Uh other resources. So we published a paper about the 00:14:58.297-->00:15:04.237 the mechanism which goes one level of detail deeper into uh how it works. And the Net Dev 00:15:04.237-->00:15:08.141 talk that I mentioned earlier is linked uh from the slides which you'll be able to get at after 00:15:08.141-->00:15:12.845 the talk. That talk described the overall environment where this mechanism was use used and 00:15:12.845-->00:15:17.850 and how it was used in that environment. So the current status. The implementation to 00:15:19.919-->00:15:24.924 extract signatures for clients went into host APD in August of 2016 and it's present in hostAPD 00:15:27.426-->00:15:33.699 2.6 and later. The database of known signatures is released as open source code with an Apache 00:15:33.699-->00:15:39.906 license on GitHub and the link is also in the slides. It currently identifies about 60 00:15:39.906-->00:15:45.545 percent of wifi clients across a a broad swath of the market. The remaining 40 percent of devices 00:15:45.545-->00:15:51.717 are mostly laptops and desktops but with a very long tail of just other stuff that we don't' 00:15:51.717-->00:15:56.722 know what it is. So what come next? There's this thing which can identify an interesting 00:16:03.129-->00:16:08.534 subset of wi wifi client devices. Uh this signature mechanism is in hostAPD, the 00:16:08.534-->00:16:14.273 database has been released as open source but it's only useful if it's integrated into other 00:16:14.273-->00:16:20.012 products and systems. Uh, wifi AP's, wireless intrusion detection systems and anything 00:16:20.012-->00:16:24.150 else interesting that people think of and so one of the points, one of the main reasons 00:16:24.150-->00:16:29.722 for this talk is to build awareness that this thing exists and it's available for use. Uh 00:16:29.722-->00:16:36.362 we other things that we need to do are develop better tools for gathering signatures. It's a 00:16:36.362-->00:16:43.069 pretty manually intensive process right now which which means me. Um, so also the longer 00:16:43.069-->00:16:49.141 we've been at it uh, the more we realize that the client responds to things that it sees from the 00:16:49.141-->00:16:54.213 AP. We've been using 3 AP's for a long time. WE need to start using even more and more 00:16:54.213-->00:16:59.452 different types of AP's to make sure that we're getting the different signatures devices can 00:16:59.452-->00:17:05.391 emit. Uh, other things that might happen in the future. so this talk has been all all about 00:17:05.391-->00:17:10.663 how AP's can identify client devices but running it in reverse would probably work as 00:17:10.663-->00:17:15.735 well. A client device could list off the information elements that are present in the beacon 00:17:15.735-->00:17:20.806 that it sees from an AP and maybe in the probe response that it sees from the AP and use it 00:17:20.806-->00:17:26.546 to identify what type of AP that it's talking to and then the client for any kind of 00:17:26.546-->00:17:31.851 performance or quality measurements that it does, can also associate it with the brand 00:17:31.851-->00:17:36.856 and model of AP. So, uh I surveyed uh coworkers about whether to run a devo demo, uh 00:17:41.627-->00:17:46.632 as you can see the results were quite incorrigible. [laughter] So, you can try it and you might 00:17:50.269-->00:17:55.274 be able to try it. Let me move it back. You might be able to try it, okay. You can [laughter] 00:18:04.717-->00:18:09.722 you can join the SSID is Smell Of Wifi Talk and the password is all lowercase, smell of wifi 00:18:12.325-->00:18:17.330 talk and the system will try to identify what can of device uh it is. I, to make sure that the 00:18:20.566-->00:18:25.571 demo worked, used a nexus 4. [laughter] there ya go [laughter] Nexus 6P [laughter] 00:18:29.742-->00:18:34.747 any questions? >>Yes um, concerning that poll uh it seems impossible to uh train 100-->000 00:18:41.721-->00:18:46.726 dollar or I mean 100-->00 fully emplaced captains to use wifi [inaudible questions] [laughter] 00:18:51.564-->00:18:56.635 >>Can, so the question is about voting and polling systems? >>yes voting and wifi intrusion 00:18:56.635-->00:19:02.441 um. >>Um >>That seems like an impossible problem. >>Yes, I would not use this mechanism for 00:19:02.441-->00:19:07.446 voting, for protecting voting polling places. Other questions? Okay. Thank you. [applause]